According to its description, it is supposed to be the LCM of all the
frame durations. The usability of such a thing is vanishingly small,
especially since we cannot determine it with any amount of reliability.
Therefore get rid of it after the next bump.
Replace it with the average framerate where it makes sense.
FATE results for the wtv and xmv demux tests change. In the wtv case
this is caused by the file being corrupted (or possibly badly cut) and
containing invalid timestamps. This results in lavf estimating the
framerate wrong and making up wrong frame durations.
In the xmv case the file contains pts jumps, so again the estimated
framerate is far from anything sane and lavf again makes up different
frame durations.
In some other tests lavf starts making up frame durations from different
frame.
currently a overflow there should be impossible but future changes to
the code could easily introduce a bug that no longer limits the 2
values sufficiently so better protect it via av_assert.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The new incremental parser doesn't always clear prev_pkt,
however the packet queue is cleared when seeking. Which leads
to a use-after-free.
Verified using Valgrind.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
Reduces the amount of upfront data required for cluster parsing
thus decreasing latency on seek and startup.
The change in the seek-lavf_mkv FATE test is due to incremental
parsing no longer reading as much data as the old parser and
thus not having that additional data to generate index entries
based on keyframes. Index entries are added correctly as the
file is parsed.
All FATE tests pass and Chrome has been using this patch for ~6
months without issue.
Currently incremental parsing is not supported for files with
SSA tracks since they require merging packets between clusters.
In this case the code falls back to non-incremental parsing.
Signed-off-by: Aaron Colwell <acolwell@chromium.org>
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
If a video track specifies a zero frame rate (invalid but occurs),
this results in a division by zero and subsequent undefined conversion
to integer. Setting the default duration from the frame rate only
if the latter is greater than zero avoids such problems.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This replaces the matroskadec one with the same name.
The advantage is not only easier reuse in other demuxers
but also that we can make the decisions after the parser.
This fixes seeking in files that mark the keyframes incorrectly,
for example the file in track ticket #1003.
The matroska variable is still kept to be able to complain
about such broken files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
During error conditions matroska_parse_block may exit without
freeing the memory allocated for laces.
Found via valgrind: http://pastebin.com/E54k8QFU
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
During error conditions matroska_parse_block may exit without
freeing the memory allocated for laces.
Found via valgrind: http://pastebin.com/E54k8QFU
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This prevents certain tags with a default value assigned to them (as per
the EBML syntax elements) from ever being assigned a NULL value. Other
parts of the code rely on these being non-NULL (i.e. they don't check for
NULL before e.g. using the string in strcmp() or similar), and thus in
effect this prevents crashes when reading of such specific tags fails,
either because of low memory or because of targeted file corruption.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
The parser was fixed so this workaround should no longer
be necessary.
This allows using stream-copy to fix files with keyframes
incorrectly marked.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This allows handling matroska files with errors.
Fixes test4.mkv and test7.mkv from the official Matroska test suite.
These are also trac issues #544 and #545.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Prefix the functions/tables brktimegm, pcm_read_seek,
dv_offset_reset, voc_get_packet, codec_movaudio_tags,
codec_movvideo_tags.
After this, lavf has no global symbols without the proper prefix.
Signed-off-by: Martin Storsjö <martin@martin.st>
In particular, detect when the index is obviously broken.
This fixes the worst symptoms of trac issue #958 and makes
sense to allow seeking in files without index.
However it is possible that there still is an index parsing bug
with that file.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Otherwise when we run into levels beyond the max. allowed
playback will be permanently broken.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
a realloc()
BUG=100492
Review URL: http://codereview.chromium.org/8366004
Fixes: 1 of 2 for CVE-2011-3893
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The existing functions defined in intfloat_readwrite.[ch] are
both slow and incorrect (infinities are not handled).
This introduces a new header with fast, inline conversion
functions using direct union punning assuming an IEEE-754
system, an assumption already made throughout the code.
The one use of Intel/Motorola extended 80-bit format is
replaced by simpler code sufficient under the present
constraints (positive normal values).
The old functions are marked deprecated and retained for
compatibility.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Michael Niedermayer
Anton Khirnov
Moritz Bunkus
Diego Biurrun
Dale Curtis
Luca Barbato
Mans Rullgard
Nicolas George
Reimar Döffinger
Aaron Colwell
Ronald S. Bultje
Alex Converse
Martin Storsjö
Chris Evans