Initialize the bit buffer with the correct size (amount of bits that will
be read) instead of relying on the bitstream reader overreading the
correct values.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Almost all the places from which this function is called already check
the header manually and in the two that don't (the mp3 muxer) the check
should not cause any problems.
14496-3 suggests packing main_data of MP3 that is usually scattered
into multiple frames due to bit reservoir.
However, after packing main_data into a access unit, bitrate index
in the MPEG audio frame header doesn't match with actual frame size.
In order to accept this, this patch removes unnecessary frame size
checking on mp3 decoder.
Also, mov demuxer was changed to use MP3 parser only on special cases
(QT MOV with specific sample description) to avoid re-packetizing.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes decoding, broken since 7e35037.
This is similar to what was done for the normal mp3 decoder in
f4a86bc9.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is similar to the fix in 35cbc98b.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The value should be always 3, as it follows from the specification.
Fix a stack buffer overflow in exponents_from_scale_factors as reported
by asan. Thanks to Dale Curtis for the sample vector.
In hybrid frames long window part ends at 36 samples for most of the cases
but at 72 for 8kHz case. For some reason decoder assumed it's 48 or even 36
samples, which caused wrong bitstream decoding for such blocks.
l3_25207.mpg from conformance suite demonstrates it the best.
Looks like some LAME versions produce dual stereo mode MP3s with
flags for intensity and middle stereo set. In this mode those flags
should be ignored like the reference decoder and derived ones do.
In most places where it's used, it's as a pointless write-only field.
Only rv10 decoder actually reads from it, but it stores some internal
version info in it. There is no reason for it to be in a public field.
Instead of clipping extrasize based on EXTRABYTES, clip based on the
amount of buffer actually left. Without this fix, there are warbles
and other distortions in the test case below.
http://kevincennis.com/mix/assets/sounds/1901_voxfx.mp3
If bufsize < headersize, init_get_bits() will be called with a negative
number, causing it to fail and any subsequent call to get_bits() will
crash because it reads from a NULL pointer.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
In some cases, what is left to read from ptr is smaller than EXTRABYTES.
Based on a patch by Thierry Foucu <tfoucu@gmail.com>.
Signed-off-by: Alex Converse <alex.converse@gmail.com>
The safe bitstream reader does not allow using skip_bits_long() to seek to a
point before the start of the buffer, which was needed by the mp3 decoder.
This change instead calculates the start point of the first valid granule and
skips to that position.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
The buffer splicing relies on the bitstream reader over-reading
the end of the buffer as declared in init_get_bits(), although
more data is actually present. Manually moving the bitstream
boundary after init_get_bits() allows this to work as expected.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Pass the correct size in bits to mpeg4audio_get_config and add a flag
to disable parsing of the sync extension when the size is not known.
Latm with AudioMuxVersion 0 does not specify the size of the audio
specific config. Data after the audio specific config can be
misinterpreted as sync extension resulting in random and wrong configs.
Luca Barbato
Vittorio Giovara
Andreas Cadhalpun
Anton Khirnov
nu774
Gabriel Dume
Martin Storsjö
Diego Biurrun
Justin Ruggles
Ronald S. Bultje
Michael Niedermayer
Kostya Shishkov
Vitor Sessak
Dale Curtis
Alex Converse
Dustin Brody
Mans Rullgard
Janne Grunau