The previous code assumed if an atom was marked with a 64-bit
size extension, it actually had that data available. The new
code verfies there's enough data in the atom for this to be
done.
Failure to verify causes total_size > atom.size which will
result in negative size calculations later on.
Found-by: Paul Mehta <paul@paulmehta.com>
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Under abnormal conditions the item_count may exceed the max
allocation size on 32-bit systems, this causes the allocated
size to overflow and become too small for the given count.
Additionally, if av_reallocp() fails its allocation, the
fragment_index_count is not correctly decremented.
Ensuring further havoc may be wrought, the error code for
read_tfra() is not checked upon return.
Found-by: Paul Mehta <paul@paulmehta.com>
positive return code and use of _array functions by commiter
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since 3cec81f4d4, a zero-length metadata value would try to
allocate 2*0 bytes, where av_malloc() returns NULL.
Always add one to the allocated length, to allow space for
a null terminator in the zero-length case.
Incidentally, this fixes fate-alac on RVCT 4.0, where a compiler
bug seems to mess up the mov muxer to the point that it writes
the wrong sort of metadata. Previously this bug was undetected,
but since 3cec81f4d4 such mov files started returning
AVERROR(ENOMEM) in the mov demuxer.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was suggested by cbsrobot, ubitux and koda
There are files with huge amounts of XMP data, which would otherwise
be displayed in the terminal output of FFmpeg
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The Extensible Metadata Platform tag can contain various kind of data
which are not strictly related to the video file, such as history of edits
and saves from the project file. So display XMP metadata only when the
user explicitly requires it.
Based on a patch by Marek Fort <marek.fort@chyronhego.com>.
These tags describe the product and quicktime library version respectively.
They originate from Adobe Premiere, but also some other programs use them.
Contrary to other tags, they contain 'raw' data which is not to be
interpreted as iso639 or mac strings.
Based on a patch by Peter Ross <pross@xvid.org>.
Fixes decting channel layout for files with uncommon audio, such as
FL and FR in two separate streams. Introduced in 3bab7cd.
CC: libav-devel@libav.org
Sample-Id: ticket1474.mov
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This allows to load metadata entries longer than 1024 bytes.
Displaying them is still limited to 1024 characters, but applications
can load them fully now.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Also see [FFmpeg-devel] [PATCH] avformat/mov: strengthen some table allocations
which contains more fixes but is unfinished
Fixes: signal_sigabrt_7ffff6ac7bb9_3484_cov_1830000177_starfox2.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
gmtime isn't thread safe in general. In msvcrt (which lacks gmtime_r),
the buffer used by gmtime is thread specific though.
One call to localtime is left in avconv_opt.c, where thread safety
shouldn't matter (instead of making avconv depend on the libavutil
internal header).
Signed-off-by: Martin Storsjö <martin@martin.st>
If the buffer provided to strftime is too small, the buffer contents
are indeterminate - it does not guarantee actually null terminating
the buffer.
Signed-off-by: Martin Storsjö <martin@martin.st>
If using MFRA for timestamps, the stream may start from a large offset
and/or have gaps. With this change we calculate the bitrate based on
frames we've seen.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This introduces a new option to the mov demuxer: -use_mfra_for
(pts|dts). When it's given and moofs and a MFRA are present, the MFRA's
TFRAs are read for fragment start times.
Unfortunately some programs that produce fragmented mp4s use the TFRA
time field for dts and some for pts. There is no realistic way to detect
which is the case, hence the responsibility is punted onto the user.
This also means that no behavioural change is enabled by default - you
must pass either dts or pts for anything to happen.
Without this change, timestamps for some discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
syncframes in E-AC-3 can be combined to provide 6 audio blocks per
sample, thus requiring parsing for proper decoding.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes regression from Ticket3962
This basically favors the first global header while since 34751f8313
it was the last. If this heuristic turns out worse, do not hesitate to revert this and
reopen 3962 as a feature request for multiple STSD
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Michael Niedermayer
Dale Curtis
Clément Bœsch
Anton Khirnov
Thomas Volkert
Martin Storsjö
Dave Rice
Vittorio Giovara
Matthieu Bouron
Thilo Borgmann
Mika Raento
Benoit Fouet
Carl Eugen Hoyos
Diego Biurrun
Reimar Döffinger