| Message ID | DM6PR14MB26335FE7CDA8E262AED1EDD79AE30@DM6PR14MB2633.namprd14.prod.outlook.com |
|---|---|
| State | Accepted |
| Commit | 9051092e73666e95986eb2d596cc0867aea05c3d |
| Headers | show |
On Tue, Jun 25, 2019 at 06:47:30AM +0000, Jacob Siddall wrote: > The previous calculation code did not account for the fact that the > copy_offset for the start of the frame array is at index 0, yet the > scan line number from the rfc4175 RTP header starts at 1. > This caused 2 issues to appear: > - The first scan line was being copied into the array where the second > scan line should be. This caused the resulting video to have a green > line at the top of it. > - Since the packet containing the last scan line would fail the > calculation, the packet with the RTP marker would not be processed > which caused a log message saying "Missed previous RTP marker" to be > outputted for each frame. > > Signed-off-by: Jacob Siddall <kobe@live.com.au> > --- > Changes in v2: > - Don't handle packet if the line number is less than 1 > > Section 12 in the VSF technical recommendation TR-03 specifies that the > video scan line numbers should start at 1. > http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf > > libavformat/rtpdec_rfc4175.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) git seems to not like the patch: Applying: avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation Using index info to reconstruct a base tree... error: patch failed: libavformat/rtpdec_rfc4175.c:205 error: libavformat/rtpdec_rfc4175.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. Patch failed at 0001 avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation [...]
> git seems to not like the patch: > > Applying: avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation > Using index info to reconstruct a base tree... > error: patch failed: libavformat/rtpdec_rfc4175.c:205 > error: libavformat/rtpdec_rfc4175.c: patch does not apply > error: Did you hand edit your patch? > It does not apply to blobs recorded in its index. > Patch failed at 0001 avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation I think I figured out what is causing my patches to not apply with git. When I initially cloned the ffmpeg git repository, I cloned it with "--depth 1". When the patch file was generated, the commit hash abbreviation is 7 characters long. I cloned a fresh copy of ffmpeg without the depth argument and the patch file that was generated has a hash abbreviation length of 10 characters. index e9c62c1..490db87 100644 vs index e9c62c1389..490db87520 100644 I'll send an updated patch file with this change in it and hopefully it works.
diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c index e9c62c1..490db87 100644 --- a/libavformat/rtpdec_rfc4175.c +++ b/libavformat/rtpdec_rfc4175.c @@ -205,8 +205,11 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data, if (length > payload_len) length = payload_len; + if (line < 1) + return AVERROR_INVALIDDATA; + /* prevent ill-formed packets to write after buffer's end */ - copy_offset = (line * data->width + offset) * data->pgroup / data->xinc; + copy_offset = ((line - 1) * data->width + offset) * data->pgroup / data->xinc; if (copy_offset + length > data->frame_size) return AVERROR_INVALIDDATA;
The previous calculation code did not account for the fact that the copy_offset for the start of the frame array is at index 0, yet the scan line number from the rfc4175 RTP header starts at 1. This caused 2 issues to appear: - The first scan line was being copied into the array where the second scan line should be. This caused the resulting video to have a green line at the top of it. - Since the packet containing the last scan line would fail the calculation, the packet with the RTP marker would not be processed which caused a log message saying "Missed previous RTP marker" to be outputted for each frame. Signed-off-by: Jacob Siddall <kobe@live.com.au> --- Changes in v2: - Don't handle packet if the line number is less than 1 Section 12 in the VSF technical recommendation TR-03 specifies that the video scan line numbers should start at 1. http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf libavformat/rtpdec_rfc4175.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.20.1