Fixed codebook mode in 5300 rate may write up to SUBFRAME_LEN + 4 and
that is considered normal by the reference decoder. Without that additional
padding it might overwrite first elements of LPC history.
It turns out that the reference decoder subtracts 128 from DC during block
decode but adds it back during reordering block with zigzag pattern.
Transforming block with incorrect DC caused heavy visual artifacts for
many quantisers.
Unlike its predecessor, Indeo Audio codec generates tables depending on
sampling rate. Previously decoder used pre-generated tables for 22050 Hz
which obviously doesn't work with other frequencies.
Many thanks to Maxim Poliakovsky for providing all needed information
for this.
In Musepack SV8 codec property tell the maximum nonzero band, but every
frame codes maximum band as a limit (i.e. strictly less than given value).
Synthesis also expects maximum nonzero band, so there's a need to convert
frame maximum band limit value.
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>
Kostya Shishkov
