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>
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 d6d5ef5534, 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>
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>
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.
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>
Use a noise range of -0.707 to 0.707 instead of -0.5 to 0.5
Based on patch by: Mathias Rauen <madshi@gmail.com> and commit by Justin Ruggles (04ea5491)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This allows us to remove FF_IDCT_WMV2, which serves no practical purpose
other than to be able to select the WMV2 IDCT for MPEG (or vice versa)
and get corrupt output.
Fate tests for all wmv2-related tests change, because (for some obscure
reason) they forced use of the MPEG IDCT. You would get the same changes
previously by not using -idct simple in the fate test (or replacing it
with -idct auto).