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>
Put filenames and configuration options in code for clarity, and fix some list formatting.
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since commit 934f2d2f5c,
cmdutils_read_file() prints a confusing message on success:
IO error: Success
This is because the error message is printed on the success path as
well. Add the missing condition so that it is only printed on error.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array accesses
Fixes: ffmpeg_mjpeg_crash.avi
Found-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1509c018bd5b054a2354e20021ccbac9c934d213':
mpegts: relax restrictions on matching the packet start in read_header
Conflicts:
libavformat/mpegts.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* cus/stable:
ffplay: factorize thread starting and stopping code into decoder
ffplay: make eof part of videostate and signal it when opening a stream
ffplay: update frame timer based on last updated clock time when toggling pause
Merged-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>
Doing this check in avutil_version() is not appropriate. Also, this code
is by default disabled (--assert-level is by default 0). A FATE run with
defaults will never execute the checks.
Move it to the pixelutils test program. Whatever reason there was in
avutil_version() not to run this test by default, it should be fine in
this test program. This means FATE will run the test by default. (Yes,
pixelutils is not strictly the best place for it either, but it's
better.)
(pixdesc.c also has a small test program, but it's never run by FATE.)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is necessary, because avcodec_decode_video2 can change
width, height and/or pixel format of the AVCodecContext. Since
video_dst_data and video_dst_linesize are not updated by calling
av_image_alloc again, av_image_copy[_plane] asserts, because the
destination buffer is too small.
In this case, creating a useable rawvideo is not possible anyway, since
it has fixed width/height/pix_fmt.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Before the changes :
lavu CAMELLIA size: 1048576 runs: 1024 time: 32.541 +- 0.044
After the changes:
lavu CAMELLIA size: 1048576 runs: 1024 time: 24.589 +- 0.066
Tested with crypto_bench on a Linux x86_64 OS with Intel Core i5-3210M CPU.
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>
