Signed-off-by: Martin Storsjö <martin@martin.st>

Some changes in the border pixels, visually indistinguishable.

Do not rely on get_buffer initializing them.

Changes yadif tests (off by one in one border pixel), because yadif
reads from those uninitialized lines.

The FATE sample contains some pixels with value 0, but the palette
stored in the file contains only values from 16 up. Because the default
and cmdutils get_buffer() initialize the data to 0x80, they appear as
gray dots.
After this commit they change to black dots, which is probably still
incorrect but less visible and doesn't rely on get_buffer() initializing
the data.

Signed-off-by: Anton Khirnov <anton@khirnov.net>
CC:libav-stable@libav.org

Duplicate the last one or two chroma lines.

Signed-off-by: Anton Khirnov <anton@khirnov.net>
CC:libav-stable@libav.org

CC:libav-stable@libav.org

The bottom line was invalid before.

CC:libav-stable@libav.org

Setting it to zero (instead of 128, as the default get_buffer() does)
also produces more correctly-looking output.

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Also rename the test to reflect that the video track is Theora, not VP3.

Add some additional checks for EOF and print error messages on an incomplete
header or packet.

FATE reference updated for id-cin-video due to the demuxer no longer
returning a partial video packet at EOF.

The background changes from 128 (used by the default/cmdutils
get_buffer()) to 0. This looks more correct.

Do not overwrite linesize set by get_buffer().

The last frame in the FATE test is not decoded anymore, since the file
is cut and a part of it is missing.

The initial testing of the VFW binary codec was flawed,
likely due to an AviSynth bug.

Re-testing using VirtualDub and various professional editing
applications has revealed it should have been flipped.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

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

The error codes differ between systems so printing the value makes
the fate test fail on some systems.

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

Signed-off-by: Martin Storsjö <martin@martin.st>

Previously, the value given to put_bits was 10 bits long for positive
predictors, even though 9 bits were to be written. The extra bit could
in some cases overwrite existing bits in the bitstream writer cache.

This fixes a failed assert in put_bits.h, when running a version
built with -DDEBUG.

The fate test result gets slightly improved, thanks to getting rid
of the overwritten bits in the bitstream writer cache.

Signed-off-by: Martin Storsjö <martin@martin.st>

Avoid code duplication and provide faster and better compression.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

The failures on various architectures and compilers on the RGB(A)
tests seem to have been because of one-off YCbCr->RGB conversion
results. This should make the conversion results match on most if
not all code paths.

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

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

This addition must be done as 64-bit to avoid overflow and for
the subsequent clipping to be meaningful.

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

Renames the old test to allow using fate-nuv as group for all
nuv tests.

Based on patch by Oana Stratulat <oanaandreeastratulat@gmail.com>.

According to its description, it is supposed to be the LCM of all the
frame durations. The usability of such a thing is vanishingly small,
especially since we cannot determine it with any amount of reliability.
Therefore get rid of it after the next bump.

Replace it with the average framerate where it makes sense.

FATE results for the wtv and xmv demux tests change. In the wtv case
this is caused by the file being corrupted (or possibly badly cut) and
containing invalid timestamps. This results in lavf estimating the
framerate wrong and making up wrong frame durations.
In the xmv case the file contains pts jumps, so again the estimated
framerate is far from anything sane and lavf again makes up different
frame durations.

In some other tests lavf starts making up frame durations from different
frame.

MMX-enabled systems by default use some dsputil functions differing
from the C versions.  Adding these flags ensures accurate ones are
used everywhere.

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

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>