* commit '36a7df8cf1115aa37a1b0d42324ecde5ab6c2304':
arm: Only build the FFT init files if FFT is enabled
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9b9b2e9f3036abfd42916bcf734af14b4cb686aa':
build: arm: cosmetics: Place all OBJS declarations in alphabetical order
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '701966730ce10290fd49c5ccedd73f505680f764':
vmd: drop incomplete chunks and spurious samples
Conflicts:
libavcodec/vmdav.c
2 of the changes are replaced by assert0s, as they should
be impossible.
The actual bug is likely caused by a invalid block_align
which is checked for and thus impossible in ffmpeg.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is necessary since the switch to floating point
input means there is no longer sufficient input data
validation.
There is a good chance that other encoders are affected
by similar issues.
This problem can be triggered by trying to encode
extremely large values and probably also with Inf and
possibly also NaNs.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Odd chunk size makes no sense for stereo and incomplete chunks are
not supported.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Simplify a little, assume empty frames are acceptable and
do not pointlessly reinit the bytestream2 contexts using
possibly wrong size values.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
* commit '89806691b1c39181c63d95e0fddc30f11e2a7b04':
wavpack: check that all the channels were coded.
wavpack: check that there aren't too many blocks per packet
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7d039e70a5ff23a7deaa866684d2e8872acc5169':
wavpack: extract channel information from the bitstream
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '78f75b6fa421dd39a715588e9487579f1ce5bada':
wavpack: extract sample rate from the bitstream
configure: support gcc-4.8 instrumentation
Conflicts:
libavcodec/wavpack.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4a27a52a1f74016095b7aee1b4a422cf62217ade':
fate: Don't use files from SRC_PATH in the actual tests
indeo4: reuse context block VLC for band instead of defaulting
Conflicts:
tests/Makefile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '728214992e3698305550c1762f973d2ac567f016':
vc1dec: Remove interlaced warning
vc1dec: Fix mixed field/frame intensity compensation
vc1dec: Match addressing between compensation and MC in vc1_mc_4mv_chroma4
vc1dec: Handle top and bottom blocks in vc1_mc_4mv_chroma4() differently if needed
vc1dec: Fix doxy for vc1_mc_4mv_chroma4()
vc1dec: Drop old use_ic code from vc1_b_mc
vc1: Use shuffled use_ic instead of equally shuffled mv_mode
vc1dec: Implement intensity compensation for vc1_interp_mc()
Conflicts:
Changelog
libavcodec/vc1dec.c
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
the float conditions are largely changed to check the DWT
instead of the bitexact flag, which previously was wrong
(DWT53 is always int)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The decoder did not start predicted frames with missing references but
called the end of frame handling on them anyway. This caused an
assertion in the VA API HW accelorator since it tried to render a
picture with uninitialized buffers.
The quantization code needs more work, not so much work
merging but more work investigating what is correct.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Currently if no custom block VLC is specified for band, a default block VLC
will be used, while the global block VLC stored in the context should be used
instead.
This fixes decoding of one sample I have.
Now it can use different references for those blocks and even use
averaging.
This fixes several chroma artifacts in several videos.
Signed-off-by: Martin Storsjö <martin@martin.st>
