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
On EOF, get_bits() will continuously return 0, causing an infinite
loop.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
According to 14496-12, the duration should be all 1s if
the duration is unknown. This is the case if writing a moov
atom without any samples described in it (e.g. as in ismv files).
Signed-off-by: Martin Storsjö <martin@martin.st>
The unused code being removed is for encoding only and therefore is not needed
by the decoder.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
Disadvantage is that it no longer allows modifying brightness through
adjustment of the RGB lookup table. Advantage is that now monowhite/black
no longer need to be identified as a RGB format.
WMApro actually support 13-bits block sizes (potentially even up to 14),
and thus we should support that also. If we get block sizes beyond what
the decoder can handle (14 is possible depending on s->decode_flags),
error out instead of crashing.
Fixes invalid free() if any of the buffers are not allocated due to either
not decoding a header or an error prior to allocating all buffers.
Fixes CVE-2012-0858
CC: libav-stable@libav.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
Add a check to avoid writing past the end of the channel_unit.components[]
array.
Bug Found by: cosminamironesei
Fixes CVE-2012-0853
CC: libav-stable@libav.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
This makes the check that avoids overwrite of the samples array actually
work properly.
fixes CVE-2012-0848
CC: libav-stable@libav.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
According to unofficial documentation, the video rate is locked to the audio
sample rate. This results in proper synchronization of audio and video
timestamps from the demuxer. This only works if the first audio packet occurs
before the first video packet or the audio sample rate is the default rate of
11111 Hz, both of which are true for all samples in our archive.
This avoids initializing a stream with dummy values or when the file does not
contain audio.
Also set duration for audio packets, using the sample rate as the time base.
Update FATE reference to account for now non-existent palette packet.
This also fixes the FATE test if frame data is not initialized in
get_buffer(), so update comment in avconv accordingly.
The rtp demuxer which listens for RTP packets and detects the
RTP payload type will currently get confused if the first packet
received is an RTCP packet. Thus ignore such packets.
Signed-off-by: Martin Storsjö <martin@martin.st>
By replacing memcpy with an unrolled loop using the alignment knowledge
it has, some speedup can be obtained.
Before (gcc 4.6.1): ~400 cycles
After: ~370 cycles
Overall, around 2% speed increase when decoding a 2400s mp3 to f32le.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Ronald S. Bultje
Alex Converse
Martin Storsjö
Anton Khirnov
Justin Ruggles
Aneesh Dogra
Paul B Mahol
Kostya Shishkov
Michael Niedermayer
Christophe GISQUET