Fix reference after f7ab23b0.
+10l to me, this time aliens are not involved.

+10l to me, I blame the aliens.

Warning note suggested by Reimar.

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

This allows us to test the slice threading code.

Also rename overlay test to overlay_yuv420 accordingly.

When parsing the Xing/Info tag, don't set the bit rate if it's an Info tag.

When parsing the stream, don't override the bit rate if it's already set,
otherwise calculate the mean bit rate from parsed frames. This way, the bit
rate will be set correctly both for CBR and VBR streams.
Signed-off-by: Alexander Kojevnikov <alexander@kojevnikov.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

"12:34" is now valid syntax.

The new code is also faster and more robust.

As for the performance:

old decoder + conversion to rgb:         fps = 2618
old decoder, without converting to rgb:  fps = 4012

new decoder, producing rgb:              fps = 4502
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes Assertion failure

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

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

Some changes in the border pixels, visually indistinguishable.

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Other software does not store it in this case, and the information
is provided by the codec stream
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The QuickTime specification does not contain any hint that the atom
must not be written in some cases and both the QuickTime and the
AVID decoders do not fail if the atom is present.

This change allows to signal (visually) interlaced streams with
a codec different from uncompressed video.

As a side-effect, this fixes ticket #2202

Matroska specification lists support for BlockAdditional element
which is not supported by ffmpeg's matroska parser. This patch
adds grammar definitions for parsing that element (and few other
related elements) and then puts the data in AVPacket.side_data
with new AVPacketSideDataType AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This reverts parts of d6d5ef55, that didn't work right. (The
tests that were added failed on big endian, and the output looked
garbled on little endian as well.)

This is due to the fact that the intermediate scaling values (from
e.g. hScale8To19_c or hScale16To19_c) are stored as int32_t and
thus requires a separate output function, while yuv2gbrp_full_X_c
only interprets it as int16_t.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This replaces a large number of checks for the second field by
fixing the pointers when they are setup

This should also fix I/BI field pictures

Changes checksums for vc1_sa10143, the file becomes slightly closer
to what the reference decoder outputs

Based on "vc1dec: the second field is written wrong to the picture"
         by Sebastian Sandberg <sebastiand.sandberg@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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.

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.

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: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

We have to make some symetric changes elsewhere as this increases
the precission with which samples are stored.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>