Currently the Windows CC_IDENT is ended with '\r\n'. "head -n1" will not
remove the '\r' and this is causing building error in Chromium.
This CL adds "tr -d '\r'" to remove '\r' in the CC_IDENT string. Since in
most cases '\r' only appears at the end of a string/line, this should
work in most cases.
See example:
printf "hello\r\nworld\r\n" | head -n1 | hd
00000000 68 65 6c 6c 6f 0d 0a |hello..|
printf "hello\r\nworld\r\n" | head -n1 | tr -d '\r' | hd
00000000 68 65 6c 6c 6f 0a |hello.|
Also note a similar previous change at:
https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2013-October/069950.html
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 2052929346 + 204817098 cannot be represented in type 'int'
Fixes: 5275/clusterfuzz-testcase-minimized-5367635958038528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
comment about the looks like a duplicate line.
but that is used to reason x is expressed from y
Suggested-by: Paul B Mahol
Suggested-by: Michael Niedermayer
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The rounding caused by the size scaler wasn't compensated for and the
slice sizes grew beyond what is allowed per frame.
Signed-off-by: Rostislav Pehlivanov <rpehlivanov@obe.tv>
Fixes: runtime error: signed integer overflow: -2146071175 + -268479557 cannot be represented in type 'int'
Fixes: 5237/clusterfuzz-testcase-minimized-4569895275593728
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
Fixes: runtime error: shift exponent 126 is too large for 32-bit type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise the decoder will throw "Missing header" errors when the
packets are sent for decoding.
This is similar to 89a420b71b.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There's at least one known file with a TrueHD stream that hasn't
been correctly muxed, and requires full frame parsing and repack.
Signed-off-by: James Almer <jamrial@gmail.com>
The spec implies that 0 is invalid in addition to the existing checks
Found-by: <kierank>
Reviewed-by: Kieran Kunhya <kieran618@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If first_seq_no is not within the bounds of timelines then a segfault
will occur.
This patch removes the use of first_seq_no within the timelines array
It also adds first_seq_no to the value returned by calc_next_seg_no_from_timelines
(which allows for different values of 'startNumber')
Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
This will replace the 1024 character limited filename field. Compatiblity for
output contexts are provided by copying filename field to URL if URL is unset
and by providing an internal function for muxers to set both url and filename
at once.
Signed-off-by: Marton Balint <cus@passwd.hu>
This is done mainly in preparation for the SIMD patches.
- for the 8-bit input, decrease the blend factor precision to 7-bit.
- for the 16-bit input, increase the blend factor precision to 15-bit.
- make sure the blend functions are not called with 0 or maximum blending
factors, because we don't want the signed factor integers to overflow.
Fate test changes are due to different rounding.
Signed-off-by: Marton Balint <cus@passwd.hu>
Regression since: c6939f65a1
Found-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently the resource is only ever unregistered when the
registered_frames array is fully in use and an unmapped entry is re-used
and cleaned up.
I'm pretty sure the frame will have been cleaned up before that happens,
so I'm kinda surprised this never blew up.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
If some logic like vsync in ffmpeg.c duplicates frames, it might pass
the same frame twice, which will result in a crash due it being
effectively mapped and unmapped twice.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
I suspect that this can be limited tighter, but i failed to find anything
in the spec that would confirm that.
Fixes: 4833/clusterfuzz-testcase-minimized-5302840101699584
Fixes: runtime error: left shift of 134217730 by 4 places cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: -65535 * 65312 cannot be represented in type 'int'
Fixes: 4900/clusterfuzz-testcase-minimized-5769019744321536
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AVERROR_EXIT happens when the user's interrupt callback signals that
playback should be aborted. In this case, the demuxer shouldn't print a
warning, as it's expected that all network accesses are stopped.
The seek function can just return an error if seeking is unavailable,
but often this is too late. Add a flag that signals that the stream is
unseekable, and use it in HLS.
This makes little sense due to how HLS works, and only causes some
additional annoyances if the HLS read_seek function fails (for example
if it's a live stream). It was most likely unintended.
