There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
Depending on the magnitude of the output values, the potential
errors can be larger.
This fixes errors in the lls tests on x86_32 for some seeds,
observed with GCC 11 (on Ubuntu 22.04, with the distro compiler,
with -m32).
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes an 11-year-old bug in the rgb2xyz functions, when used with a
negative stride. The current loop bounds turned it into a no-op.
Additionally, this increases performance on highly cropped images, whose
stride may be substantially higher than the effective width.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This code uses no encoder properties or state besides its name, and is
mostly muxer logic, and thus belongs more properly into the muxer.
The results of several test change due to different metadata tag order
(the "encoder" tag is now set first).
The unaligned width test cases fail on i386; we have an assembly
function of rgb24toyv12 which is enabled only within
"#if ARCH_X86_32 && HAVE_7REGS", which seems to fail these new
test cases for unaligned widths.
As that assembly function has existed for a long time in that form,
the issue probably isn't very recent, thus skip testing these cases
for now.
Once the assembly function has been fixed, these test cases can
be readded.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was broken in 2fb2cd5c79 and
74553f0026, making a simple make fate-mov fail
and most of the test not run with a simple make fate.
Signed-off-by: James Almer <jamrial@gmail.com>
Since c0666d8b, rgb24toyv12 is broken for width non-aligned to 16.
Add a simple wrapper to handle the non-aligned part.
Co-authored-by: johzzy <hellojinqiang@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Only those that can be decoded with our implementation, so excluding
* C and D - independent layers
* G, H, I - more than 2 layers
Frame hashes verified against the reference implementation from
https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/
fix error at fate-seek-* when
configure with --disable-everything --samples=fate-suite/ --enable-demuxer=mov
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
move fate-flcl1905 with depend on test case,
because there will get an error when disable-everything with fate-suite samples.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
fix make fate error when make fate with --disable-everything,
should check the mov build into ffmpeg status before test mov functions.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
fix make fate failed problem, because fate libavcodec-avcodec need mjpeg encoder
when fate-libavcodec-huffman
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The input file is MPEG range, so we should also encode to MPEG range
before comparing against it. This bug was avoided in the past because
YUVJ inputs were automatically converted back to limited range when converting
to a different pixfmt (in the absence of tagging). However, with proper YUV
negotiation in place, the default behavior is to preserve the YUV range
wherever possible. Since `rawvideo` does not signal or care about the YUV
range, we need to explicitly request the desired output range to force a
conversion.
Affects all rawvideo tests, in particular vsynth and owdenoise.
The test constructs 66 sine waves of different frequencies and joins
them into a 7th order ambisonic layout with extra non-diegetic
stereo. The channels are then shifted circularly with channelmap and
separated into individual streams for muxing with channelsplit.
Note that the last step is necessary because swr is not capable of
interleaving planar to packed for more than 64 channels, which would be
necessary to mux such a stream as PCM.
This reverts commit 110d8549d5.
I have been working through fixing bugs, particularly crashes I've
found using a fuzzer, in the VVC decoder for the past few months.
While I won't claim it is now bug-free, it is considerably more
resilient than it was and I think in a position to have the
experimental flag removed for release 7.1.
Additionally, most of the Main 10 features of VVC which were missing
version of the decoder released in 7.0 have now been implemented.
This includes the most major missing features: IBC, subpictures and RPR.
Signed-off-by: Frank Plowman <post@frankplowman.com>