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.
Unlike other variants, for YUY2 we need to use different prediction:
* on line 0 for luma we should left predict starting from the second pixel
* on line 1 we should left predict first 4 pixels for luma and 2 for chroma
* median prediction employed here is taken directly from HuffYUV
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.
ProRes codes chroma blocks in 444 mode in different order than luma blocks,
so make both decoder and encoder read/write chroma blocks in right order.
Reported by Phil Barrett
Apple ProRes Format Specifications mentions target data size for every frame,
so make sure frame meets it. This also allows encoder to demand much smaller
packet sizes for output.
Since quantisation matrices are stored in context, decoding slices with
different quantisers in parallel leads to unpredictable content of
aforementioned matrices and wrong output picture thereof.
Reference decoder clips data before shifting it to final range and also
forces 32-bit lossy mode to be actually 24-bit lossy mode in order to be
able to perform proper clipping.
Interlaced videos can contain progressive frames too and now wrong scantable
is selected for them.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
If the frame is filled with the same colour, encoder may produce no data
and the fill value is indicated by zero code length (the rest of symbols
will have 0xFF for code length, meaning invalid). So such Huffman trees
should be treated specially.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Luma slices in YUV420 colourspace should have height in multiple of two since
they have the same line of chrominance data corresponding to pair of them.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Both v->fcm and v->field_mode are used in common code, now they won't be
reset for progressive frame after interlaced one causing writing past the
frame end for example.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This prevents some crashes when corrupted bitstream reports e.g. P-type
slice in I-frame. Official RealVideo decoder demands all slices to be
of the same type too.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This function should return number of samples decoded, not number of bytes
decoded.
Spotted by Uoti Urpala.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes improper flushing in the cases when the same frame is decoded in
several iterations (for being too large to fit into output buffer) and flush is
called mid-decoding and it also resets context in case of decoding errors.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Since RV40 is based on H.264, it uses the same interpolation filters and
functions for halfpel interpolation in one direction can be reused.
Unfortunately other cases are implemented differently and produce slightly
different output because of rounding.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Unlike other containers RealMedia stores its audio packets in scrambled form,
with interleaver ID preceeding audio codec ID. Currently deinterleaving
decision is tied to the codec while it's possible to have non-default
deinterleaver with audio codec (like Int0 deinterleaver instead of specific
one for Sipro).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This fixes the situation when there are not enough entries in the index
(e.g. on initial seek there's only one index entry in the index) and index
search returns just the last known entry. That causes seeking function just to
seek there instead of trying harder to get at the requested position.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Currently for multichannel audio position for the last block position is
stored in index (and used for seeking), which is obviously not correct.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
First, container stores only DTS and not PTS as it was believed.
Second, multiple frames in a packet store timestamp instead of position
after the frame length.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Old version was based on lots of guesswork which had different hacks based on
32-bit version field instead of splitting it into major/minor/micro version.
RV2 picture header parser also had a few places where it deviated from binary
decoder.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Old version divided it wrong, which resulted in chroma drift (visible on FATE
sample too as dirty trails left by clouds).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
When converting RGB format to RGB format with the same bits per sample,
unscaled path performs conversion on the whole buffer at once. For
non-multiple-of-16 BGR24 to RGB24 conversion it means that padding at the
end of line will be converted too. Since it may be of arbitrary length
(e.g. 8 bytes), operating on the whole buffer produces obviously wrong
results.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Since IDCT transforming 32-bit input to 8-bit output is unusual and unpractical
for most codecs, move Bink IDCT into separate context. Get rid of an additional
permutation table while at it since SIMD support for Bink IDCT is unlikely to
be implemented in foreseeable future.
Quantisation tables also have to change type to signed for proper
dequantisation of DCT coefficients.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This is needed because not all players (e.g. MPlayer) are able to distinguish
two different Bink audio decoders when codec_tag is set.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Official AVI specification says that stream header in case of video contains
BITMAPINFO, which is equal to BITMAPINFOHEADER and optional palette. Currently
lavf AVI demuxer thinks otherwise which produces garbage on codecs that have
both palette and extradata (luckily, there are not so many such codecs).
An example of such file is:
http://samples.multimedia.cx/V-codecs/KMVC/baseball1.avi
(IIRC, MSS1 or MSS2 also had such situation but they are still not supported
by lavc).
As a side note, passing palette in extradata as it's been done previously is
not quite correct since proper _extra_ data is surplus bytes in
BITMAPINFOHEADER, not including palette.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
