These tests create reference files used for psnr calculation in
the other codec tests. Treating them as (mostly) regular tests
simplifies the makefile and makes them visible in the fate reports.
The latter makes errors in these runs easier to identify.
Signed-off-by: Mans Rullgard <mans@mansr.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.
Also remove code that overwrites the C versions of functions in
sws_init_swScale_altivec(), so that it uses the C functions of files
if no altivec-optimized version exists.
Fix handling of input if not in native endianness, and add support for
9/10-bit output. This allows us to force endianness of YUV420P 9/10bit
in the H264/10bit fate tests, which should fix them on big-endian
systems.
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>
Looks better for some cases, worse for others, overall not much difference.
Its more correct though.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This should fix behavior introduced by commit
96573c0d7605672d69b42ae1dcf18764ce47c71a. Av_rescale_rnd() is not
lossless so if two timestamps are equal after being rescaled they are
not always actually identical. This patch use av_compare_ts() to get
always a correct result.
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>
(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 makes the AC3 encoder use the shared fixed-point MDCT rather
than its own implementation. The checksum changes are due to
different rounding in the MDCT.
Signed-off-by: Mans Rullgard <mans@mansr.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>
Ronald Bultje
Michael Niedermayer
Etienne Buira
Alexander Strange
Mans Rullgard
Stefano Sabatini
Baptiste Coudurier
Vitor Sessak
Reimar Döffinger
Anssi Hannula
Anton Khirnov
Peter Ross
Justin Ruggles
Diego Biurrun