9888ffb1ce added checks for EOF
in loops in the mov demuxer as a precaution against timeouts;
yet there is no I/O in the loop when parsing the STSZ atom
as the values are read from an already read buffer. So remove said
checks.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mov_read_stsz() did not ensure that every bit of a buffer is addressable
by an int as is required by the get_bits API, leading to a crash in
ticket #9344. Fix this by restricting the size more thoroughly.
The file from said ticket will then be considered invalid; in the
future, we might read and process the data in chunks to actually support
such files.
Fixes ticket #9344.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 9223372036854775807 + 1442840321 cannot be represented in type 'long'
Fixes: 33670/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6644379491106816
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 8511838621821575200 - -3954125146725285889 cannot be represented in type 'long'
Fixes: 33414/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6610119325515776
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
By default, a demuxer's read_close function is not called automatically
if an error happens when reading the header; instead it is up to the
demuxer to clean up after itself in this case. The mov demuxer did this
by calling its read_close function when it encountered some errors when
reading the header.
This commit changes this by setting the FF_FMT_INIT_CLEANUP flag so that
mov_read_close() is automatically called when an error happens when
reading the header.
(Btw: mov_read_close() is not idempotent: Calling it twice is
dangerouos, because MOVContext.frag_index.item will be av_freep'ed,
yet MOVContext.frag_index.nb_items won't be reset. So the calls to
mov_read_close() have to be removed before the switch to freeing
generically.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Libavcodec can now handle the AV1CodecConfigurationRecord structure
as-is when passed as extradata, so the standard behavior of
read-box-into-extradata should suffice, just like with AVC and HEVC.
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Deprecated in ddef3d902f.
(The reference file of the mov-zombie test needed to be updated, because
a rotate metadata tag is no longer exported; the side-data is of course
still present.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 9223372036846336888 + 4278255871 cannot be represented in type 'long'
Fixes: 32782/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6059216516284416
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
From the ISO/IEC specification for MP4:
The pixel aspect ratio and clean aperture of the video may be specified
using the ‘pasp’ and ‘clap’ sample entry boxes, respectively. These are
both optional; if present, they over-ride the declarations (if any) in
structures specific to the video codec, which structures should be
examined if these boxes are absent. For maximum compatibility, these
boxes should follow, not precede, any boxes defined in or required by
derived specifications.
Fixes trac/#7277.
All instances of adding attached pictures to a stream or adding
a stream and an attached packet to said stream have several things
in common like setting the index and flags of the packet, setting
the stream disposition etc. This commit therefore factors this out.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is important, for example, for connection timed out events,
when used over a network, returning AVERROR(ETIMEDOUT).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Fixes: signed integer overflow: 2 * 1914708000 cannot be represented in type 'int'
Fixes: 31639/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6303428239294464
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When extended atom size support was added to probing in
fec4a2d232, the buffer
size check was backwards, but probing continued to work
because there was no minimum size check yet, so despite
size being 1 on these atoms, and failing to read the 64-bit
size, the tag was still correctly read.
When 0b78016b2d introduced a
minimum size check, this exposed the bug, and broke probing
any files with extended atom sizes, such as entirely valid
large files that start whith mdat atoms.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Fixes: signed integer overflow: 9223372036854775807 + 536870912 cannot be represented in type 'long'
Fixes: 31678/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5614204619980800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use the tfra timestamp if it is available and sidx timestamp is not.
Fixes reading the entire file after seeking in a live-style DASH FMP4
with an MFRA.
This specifically fixes when use_mfra_for is set.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Fixes: signed integer overflow: -2147483634 - 16 cannot be represented in type 'int'
Fixes: 28322/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5711888402612224
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current behaviour ends up squaring the avg_frame_rate if the conter mode flag is set.
This messes up the timecode calculation, and looks to me as a regression that
seems to have been introduced 428b4aac.
Upon further testing is seems that no special case is need for having the counter flag set.
av_timecode_init appears to handles the timecode correctly, at least in the sample files
I have.
Here is a sample mov file with the counter flag set
https://www.dropbox.com/s/5l4fucb9lhq523s/timecode_counter_mode.mov
before the patch ffmpeg will report the timecode as:
00:37:11:97 and warns that the timecode framerate is 576000000/1002001
after patch:
14:50:55:02
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The choosen value is arbitrary. I am not sure if this is a good idea
but i dont immedeately see an alternative better way, it seems either
an arbitrary limit or OOM
Fixes: OOM
Fixes: 27492/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6194970578649088
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 538976288 * 538976288 cannot be represented in type 'int'
Fixes: 27473/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5758978289827840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 64 + 9223372036854775799 cannot be represented in type 'long'
Fixes: 27563/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6244650163372032
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently skip_samples is set to start_pad if sample_time is lesser or
equal to 0. This can cause issues if the stream starts with packets that
have negative pts. Calling avformat_seek_file() with ts set to 0 on such
streams makes the mov demuxer return the right corresponding packets
(near the 0 timestamp) but set skip_samples to start_pad which is
incorrect as the audio decoder will discard the returned samples
according to skip_samples from the first packet it receives (which has
its timestamp near 0).
For example, considering the following audio stream with start_pad=1344:
[PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]
Calling avformat_seek_file() with ts=0 makes the next call to
av_read_frame() return the packet with pts=-320 and a skip samples
side data set to 1344 (start_pad). This makes the audio decoder
incorrectly discard (1344 - 320) samples.
This commit makes the move demuxer adjust skip_samples according to the
stream start_pad, seek timestamp and first sample timestamp.
The above example will now result in av_read_frame() still returning the
packet with pts=-320 but with a skip samples side data set to 320
(src_pad - (seek_timestamp - first_timestamp)). This makes the audio
decoder only discard 320 samples (from pts=-320 to pts=0).
Signed-off-by: Marton Balint <cus@passwd.hu>
Soft Works
Andreas Rheinhardt
Michael Niedermayer
Martin Storsjö
Gyan Doshi
Jan Ekström
James Almer
Andreas Rheinhardt
Vittorio Giovara
Derek Buitenhuis
Mark Reid
Matthieu Bouron
Zhao Zhili
Thierry Foucu