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)
The rm demuxer has timestamp bugs, so this test is sensitive to changes in
timestamp correction. The previous commit did not make output any better or worse
on this test, just different.
See https://roundup.ffmpeg.org/issue2288 for details.
Originally committed as revision 25432 to svn://svn.ffmpeg.org/ffmpeg/trunk
and add a test for regular GSM as fate-gsm.
Fixes a 8kHz sample from issue 113.
Originally committed as revision 25313 to svn://svn.ffmpeg.org/ffmpeg/trunk