This uses the RIFF header stored size to figure out the expected AVI file size, instead
of the actual file. To work fully it requires handling failed avio_seek() instead
of assuming they always succeed.
Some fate file has been cut off and contains half a frame at the end which previously
was not output during demuxing. This frame is now output to encoder, thus fate
diff update.
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 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>
Make the iff demuxer send the whole audio chunk to the decoder as a
single packet, move stereo interleaving from the iff demuxer to the
decoder, and introduce an 8svx_raw decoder which performs
stereo interleaving.
This is required for handling stereo data correctly, indeed samples
are stored like:
LLLLLL....RRRRRR
that is all left samples are at the beginning of the chunk, all right
samples at the end, so it is necessary to store and process the whole
buffer in order to decode each frame. Thus the decoder needs all the
audio chunk before it can return interleaved data.
Fix decoding of files 8svx_exp.iff and 8svx_fib.iff, fix trac issue #169.
framecrc returns different values when one swiches endianness,
this apparently has been missed by "the fork" who added the 10bit fate
tests. Sorry for missing this during the merge.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
As per issue2629, most 23.976fps matroska H.264 files are incorrectly
detected as 24fps, as the matroska timestamps usually have only
millisecond precision.
Fix that by doubling the amount of timestamps inspected for frame rate
for streams that have coarse time base. This also fixes 29.970 detection
in matroska.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 78431098f9)
Tested with mplayer based on this report
http://thread.gmane.org/gmane.comp.video.mplayer.user/66043/focus=66063
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
As per issue2629, most 23.976fps matroska H.264 files are incorrectly
detected as 24fps, as the matroska timestamps usually have only
millisecond precision.
Fix that by doubling the amount of timestamps inspected for frame rate
for streams that have coarse time base. This also fixes 29.970 detection
in matroska.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There is no need to expand to 16-bits. Just use memcpy() to copy the raw data.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 1108f8998c)