Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The sample on rsync was corrupt, this one is now bitexact w.r.t. JM.

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>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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>

This allows for more reproducible results when using multi-threading.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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>

This updates the wmv8-drm reference after c47d383.

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit e211e255aa)

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)

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 9b73f78600)

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit e63dd5fb04)

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 76edf2c137)

Signed-off-by: Mans Rullgard <mans@mansr.com>

Originally committed as revision 26342 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26231 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26119 to svn://svn.ffmpeg.org/ffmpeg/trunk

due to VC-1 decoder overreads resulting in different output.

Originally committed as revision 26055 to svn://svn.ffmpeg.org/ffmpeg/trunk

to complement the existing video-only decode test.

Originally committed as revision 26054 to svn://svn.ffmpeg.org/ffmpeg/trunk

Whether the behaviour for streams using scrambling makes sense
is unclear.

Originally committed as revision 26053 to svn://svn.ffmpeg.org/ffmpeg/trunk

This includes a revert of r25840

Originally committed as revision 25842 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25840 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25736 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25735 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25677 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25664 to svn://svn.ffmpeg.org/ffmpeg/trunk

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

Originally committed as revision 25104 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25013 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25008 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25006 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25005 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 24957 to svn://svn.ffmpeg.org/ffmpeg/trunk

corrupting memory somehow and segfaulting in the BSDs.

Originally committed as revision 24956 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 24954 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 24928 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 24911 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 24874 to svn://svn.ffmpeg.org/ffmpeg/trunk