This misfeature is most likely completely useless and conflicts with
removing the mpegvideo-specific fields from AVFrame. In the improbable
case it is actually useful, it should be reimplemented in a better way.
When parsing the Xing/Info tag, don't set the bit rate if it's an Info tag.
When parsing the stream, don't override the bit rate if it's already set,
otherwise calculate the mean bit rate from parsed frames. This way, the bit
rate will be set correctly both for CBR and VBR streams.
CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This makes the decoder independent of mpegvideo.
This copy of the draw_horiz_band code is simplified compared to
the "generic" mpegvideo one which still has a number of special
cases for different codecs.
Signed-off-by: Martin Storsjö <martin@martin.st>
Make av_get_codec_tag_string() show codec tag string characters in a more
intelligible ways. For example the ascii char "@" is used as a number, so
should be displayed like "[64]" rather than as a printable character.
Apart alphanumeric chars, only the characters ' ' and '.' are used
literally in codec tags, all the other characters represent numbers.
This also avoids relying on locale-dependent character class functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
Not all hwaccels implement all codecs, so using one single list for
multiple such codecs means some codecs will be represented in the list,
even though they don't actually handle that codec. Copying specific
lists in each codec fixes that.
Signed-off-by: Martin Storsjö <martin@martin.st>
get_uint returns an unsigned value, use an unsigned to store
blocksize to make sure the comparison logic is correct and report
correctly the error for the channel count not supported.
Prevent the loop shorten_decode_close from writing and freeing out of
the array boundary.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The decoder assumes a single bit depth for all the planes
while the specification allows different bit depths for luma
and chroma.
Avoid the possible problems described in CVE-2013-2277
CC: libav-stable@libav.org
This reverts commit f90ff772e7.
The code should be put back in h264_qpel_8bit.asm, but unfortunately
it is unconditionally used from dsputil_mmx.c since 71155d7.
The external assembly function uses mmxext instructions and should not be
masqueraded as an mmx-only function. Instead, use the mmx-only inline
assembly function.
The specification does not prevent an encoder to write the amplitude 0
as 0 amplitude_bits.
Our get_bits() implementation might not support a zero sized read
properly, thus the additional branch.
The value is used to calculate output LSP curve and a division by zero
and out of array accesses would occur.
CVE-2013-0894
CC: libav-stable@libav.org
Reported-by: Dale Curtis <dalecurtis@chromium.org>
Found-by: inferno@chromium.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The init functions marked as av_cold have to be executed in any case,
so there is no gain from trying to mark paths leading to such functions
as unlikely.
This also allows libx264 to modify its i_qfactor value
when using the "-tune" setting. Previously it had a static
value of 1.25
Signed-off-by: Anton Khirnov <anton@khirnov.net>
