Previously, it would not be read if refdist_flag was not set, however
according to the spec and the reference decoder, it should always be read.
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
The MDCT buffers in the decoder are only sized for up to 11 bits. The
reverse engineered documentation for WMA1/2 headers say that that for
all samplerates above 32kHz 11 bits are used. 12 and 13 bit support
were added for WMAPro. I was unable to make any Microsoft tools generate
a test file at a samplerate above 48kHz.
Discovered by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
This fixes a double release of the current frame on deinit.
Fixes CVE-2011-3934
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The index of the motion vector has to be checked before being
multiplied by 2 for the array index.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Although it has been deprecated for a long time, its intended
replacement (request_channel_layout) is not actually used anywhere, so
request_channels is currently the only way to access that functionality.
Previously this was just checked in case of slice threads,
but frame threads do not support this either currently.
Making them support this is of course the long term goal
Fixes bug155
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The previous implementation assumed that a new picture would always
supersede the previous picture. Similarly, presentation segments
were assumed to pertain to the most-recently-read picture.
However, each presentation segment may refer to 0 or more pictures
by their ID. Picture IDs may repeat, and a repeated picture ID
indicates that the old picture for that ID is no longer needed
and may be discarded.
The new implementation allocates a buffer with one slot for each
possible picture ID (the picture ID is a 16-bit field) and
properly decodes presentation segments so that all relevant
pictures are output upon encountering a display segment.
Given that most PGS streams are unlikely to use more than a small
fraction of the available picture IDs, it would probably be better
to use a more memory-efficient data structure. I'm lazy though, so
I leave this to a more motivated individual.
I've tested the code with MKV files in VLC (a recent revision from
their git repo) and with HandBrake (a version that I hacked up to
use ffmpeg's PGS subtitle decoder).
Review-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes memory corruption when seeking in broken streams.
a random mpeg4 in nut file was used to debug.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This matches the spec as well as the reference decoder, and fixes a bug
with interlaced frame decoding.
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
This was a regression that came in when I switched to using the
h.264 annex b filter all the time. As the filter modifies extradata,
its use violates the statelessness assumption that exists in the
'ffmpeg' command line tool, and maybe elsewhere. It assumes that
a docoder can be reinitalised and pointed to an existing stream and
get the same results.
For now, the only way to meet this requirement is to backup the
extradata.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Michael Niedermayer
Hendrik Leppkes
Thierry Foucu
Paul B Mahol
Alex Converse
Janne Grunau
Diego Biurrun
Ronald S. Bultje
Carl Eugen Hoyos
Justin Ruggles
Anton Khirnov
Nathan Caldwell
David Mitchell
Philip Langdale
Philip Langdale