Note, 1.3 is not finalized and the bitstream will still change
do not use it yet. This option is just to make playing with it
easier, otherwise one would have to edit the source
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This partially reverts acb1730218
which would only have needed to change the checksums if channel mixing had
been properly avoided. This changes the output file size reference and the
seek test reference back to the previous values.
This should fix the FATE test on ARM (not tested),
but it should also detect alpha values like 2^128
reliably as invalid which would be another out-of-range
case with implementation-dependant behaviour.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The old code had two bugs:
For audio filters, the format was not set.
For video filters, if several links reference the same format list,
the same format must be selected in the end. This is done by
setting formats->format_count to 1: the other links sharing
the reference will therefore have only one choice.
If the heuristic does not pick the first format, the selected format
must also be moved to the first position.
* qatar/master:
matroska: Clear prev_pkt between seeks.
avutil: change default buffer size alignment for sample buffer functions
audemux: Add a sanity check for the number of channels
Remove libdirac decoder.
matroska: Add incremental parsing of clusters.
avconv: fix off by one check in complex_filter
mpegts: Try seeking back even for nonseekable protocols
swscale: K&R formatting cosmetics (part III)
Conflicts:
configure
doc/general.texi
doc/platform.texi
ffmpeg.c
libavcodec/Makefile
libavcodec/allcodecs.c
libavcodec/libdirac.h
libavcodec/libdiracdec.c
libavformat/au.c
libavformat/mpegts.c
libswscale/input.c
tests/ref/seek/lavf_mkv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This also avoids an issue with parallel make in some
cases never building asynth-16000-1.sw.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
quant_mats valid range depends on the block size.
This fixes a global array overread.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
One rule can be used to generate all asynth files.
Requires renaming the mapchan files though.
Also switch to using the .wav variants for mapchan
while changing the name anyway, this allows getting rid
of the explicitly specified format.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
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>
The mpegts demuxer reads 5 KB at startup just for discovering
the packet size. Since the default avio buffer size is 32 KB,
the seek back to the start will in most cases be within the
avio buffer, and will in most cases succeed even if the actual
protocol isn't seekable.
This makes the demuxer startup faster/with less data when
reading data from a non-seekable input, by not skipping
the first few KB.
If it fails, don't warn if the protocol isn't seekable, making
it behave as before in the failure case.
Signed-off-by: Martin Storsjö <martin@martin.st>
The new lowres support is limited to decoders where lowres decoding
is possible in high quality.
I was not able to measure any speed difference, but if one is found
the 2-3 lines that might affect speed can be made compile time conditional
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
ARM: allow runtime masking of CPU features
dsputil: remove unused functions
mov: Treat keyframe indexes as 1-origin if starting at non-zero.
mov: Take stps entries into consideration also about key_off.
Remove lowres video decoding
Conflicts:
ffmpeg.c
ffplay.c
libavcodec/arm/vp8dsp_init_arm.c
libavcodec/libopenjpegdec.c
libavcodec/mjpegdec.c
libavcodec/mpegvideo.c
libavcodec/utils.c
libavformat/mov.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This ended up corrupting data structures and may possibly
lead to a double free.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Michael Niedermayer
Justin Ruggles
Reimar Döffinger
Carl Eugen Hoyos
Nicolas George
Anton Khirnov
Yusuke Nakamura
Dale Curtis
Diego Biurrun
Luca Barbato
Martin Storsjö