For 9/10bit, it means we don't have to upscale to 16bit before
actual scaling or pixel format conversion, and thus a performance
gain.

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

This means that precision is retained when scaling between sample
formats with >8 bits per component (48bit RGB, 16bit grayscale,
9/10/16bit YUV).

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

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

This works through some non-obvious hacks in utils.c.

Without, the predictor isn't actually used.

YUV planes were marked as uint16_t, but they contained signed data.
Fixes issue 1108 and 675.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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

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

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>

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.

ipod shuffle doesn't support anything else.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

yuv range: full 1 / normal 2
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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.

This should fix behavior introduced by commit
96573c0d. 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 78431098)

Tested with mplayer based on this report
http://thread.gmane.org/gmane.comp.video.mplayer.user/66043/focus=66063Signed-off-by: Reinhard Tartler <siretart@tauware.de>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

The string "FFmpeg" was replaced by "Libav" in metadata that
got encoded in file headers.

This allows for more reproducible results when using multi-threading.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

full-bandwidth channels.

This reduces high-frequency artifacts and improves the quality of the lower
frequency audio at low bit rates.

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>

in the ac3_fixed encoder.

This updates the wmv8-drm reference after c47d3835.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This updates the seek test reference to match de11ee90.  Before this
change, most of the seeks requested positions before the supposed
start of the file (the preroll time), resulting in the first packet
being returned.  With the preroll subtracted, some of these seeks
will land within the file and some beyond the end, thus returning
a different set of packets.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This increases the accuracy of coefficients, leading to improved quality.
Rescaling of the coefficients to full 25-bit accuracy is done rather than
offsetting the exponent values. This requires coefficient scaling to be done
before determining the rematrixing strategy. Also, the rematrixing strategy
calculation must use 64-bit math to prevent overflow due to the higher
precision coefficients.

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>