Just because the user requested the seek index to be ignored, we can't
just skip essential headers. At least tags are often located at the end
of the file, and the old code simply ignored the seekhead for all
elements, not just the cue index. Also, it looks like it used the index
even if IGNIDX was set if the cue index was located in the beginning of
the file.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In particular, this reads chained seekheads. This makes seeking faster
in files which have the index indirectly linked through 2 seekheads.
As a side-effect, this warns when reading level-1 (toplevel) elements
multiple times (other than seekheads, clusters, and void/crc). Such
elements are not valid and likely break everything.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
analyze() is currently called both when probing and from read_header().
It determines the packet start by looking for the sync byte, followed by
unset Transport Error Indicator and valid adaptation_field_control.
This makes sense to do when probing, but once we already know the format
is MPEG-TS, it is counterproductive to be so strict -- e.g. in some
files the TEI might be set and analyze() might get called with a smaller
buffer than the one used for probing, resulting in a failure.
Avid prefers mpeg range [16-235] by default this change brings
ffmpeg into line with that. To obtain the old behaviour use
'-color_range jpeg' on the command line prior to the ouput
filename.
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Matroska is an extensible format - unknown elements must be expected. It
shouldn't complain about such elements to the user either; it'll just
generate noise. The "error_recognition & AV_EF_EXPLODE" is completely,
wrong why would it explode on valid files?
It's still useful for debugging, so the message is left in place with a
higher log level.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Nothing uses it, and it provides no public API.
Archeological finds:
Commit 101036adb9 added the API.
Commit a8dd8dc6e9 made mpegts.c use it.
Commit af8aae3fa3 disabled it by default in mpegts.c.
Commit ae2bb52cd2 removed all uses of this from mpegts.c.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reviewed-by: Carl Eugen Hoyos <cehoyos@ag.or.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
ff_avc_write_annexb_extradata() allocates extradata, but don't add
FF_INPUT_BUFFER_PADDING_SIZE value
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
This could overflow and crash at least on 32 bit systems.
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This can lead to an endless loop by seeking back a few bytes after each
attempted chunk read. Assuming negative sizes are always invalid, this
is easy to fix. Other code in this demuxer treats negative sizes as
invalid as well.
Fixes ticket #4262.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
industrial cameras usually mark the trigger frame as frame number 0
all frames saved before trigger frame receive a negative sequence number
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This atom typically is used for a track title. The handler name is stored
as a Pascal string in the QT specs (first byte is the length of the string),
so do not export it.
A second length check based on the first character is added to avoid
overwriting an already specified handler_name (it happens with YouTube
videos for instance, the handler_name get masked), or specifying an
empty string metadata.
The Pascal string fix and the second length check are written
by Clément Bœsch <clement.boesch@smartjog.com>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
av_add_index_entry() can fail, for example because the parameters are
invalid, or because memory allocation fails. Check this; it can actually
happen with corrupted files.
The second hunk is just for robustness. Just in case functions like
ff_reduce_index() remove entries. (Not sure if this can actually
happen.)
Fixes ticket #4294.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Gilles Chanteperdrix
Michael Niedermayer
Thomas Volkert
wm4
Paul B Mahol
Anton Khirnov
Kevin Wheatley
Clément Bœsch
Carl Eugen Hoyos
Mark Reid
Luca Barbato
Timothy Gu
James Almer
Lukasz Marek
Stefano Sabatini
Liviu Oniciuc
Vittorio Giovara
Hendrik Leppkes
Diego Biurrun