Signed-off-by: Steven Robertson <steven@strobe.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For the 10-show-existing-frame, the source file indeed has a timestamp
of 3 (or 100/33) for the second visible frame, so the fix appears to
work correctly. For the other, only the timebase is fixed, but again
appears to be correct now.
It was useful to (accidentally?) spot an overflow in the column pass
of the x86 simple_idct10 implementation.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
omse goes from 0.03060703 (which fails for dct-test) to 0.01663750.
This also actually improve the error of decoding the sample generated
by fate-vsynth3-dnxhd1080i-10bit using simple_idct10 to FAANI, which
goes (when resampled to yuv422p) from:
stddev: 0.06 PSNR: 72.28 MAXDIFF: 1
to identical.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Includes escapes that should now be supported and a few features not yet
fully supported, like comments, regions, classes, ruby, and lang.
All were tested with https://quuz.org/webvtt/ for validation, except
regions because the validator doesn't support them yet, and I couldn't
find any other way to validate WebVTT.
Signed-off-by: Ricardo Constantino <wiiaboo@gmail.com>
Currently only 2 profiles are evaluated because they are the only 2
with distributed test sequences.
- CID 1260: YUV 4:2:2 10 bits with block-adaptive interlace coding,
from ticket 4876;
- CID 1270: YUV 4:4:4 10 bits (HR), 1920x839, from ticket 4581.
They were generated from the ticket sequences by running the
following kind of command-line;
ffmpeg -i $INPUT -an -sn -vcodec copy -vframes 1 -y $OUTPUT.mov
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current one, while correct, does not yield the best possible
results. The specificiations suggest another formula, which results
in quality gains in the decoded output from fate tests. This
justifies changing said formula.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Convert them to zigzag order, as the rest of them are.
When I was adding support for 10-bit DNxHD, I just copy-pasted the
missing quant matrices from the spec. Now it turns out the existing
matrices in dnxhddata.c were in zigzag order. This resulted in wrong
quantization for 10-bit DNxHD. The attached patch fixes the problem by
converting 10-bit quant matrices to zigzag order.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The sample position is made weird and non-nominal to force catching
such issues as default values or specialized operations hiding
issues in corner cases.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This introduces a slight timebase computation difference in zmbv-8bit
fate test. This is expected since the new options are double instead
of ints, and the additional precision skews the results in a non
meaningful way.
FATE refs changed to accomodate for the new default behavior of the function.
Numbers are now interpreted as a channel layout, instead of a number of channels.
* commit '58c3720a3cc71142b5d48d8ccdc9213f9a66cd33':
fate: Make sure a corner-case for ASF is covered
Adjusted fate ref to match the different timebase of the ffasf demuxer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
As suggested, posting the combined patch with the fate changes.
The patch sets the default style in ASS from the default style
information present in the movtext header.
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
Compute individual stream durations in matroska muxer.
Write them as string tags in the same format as mkvmerge tool does.
Signed-off-by: Sasi Inguva <isasi@google.com>
Also replace custom tests for MD5 with those published in RFC 2202
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
