Ensure those bits are copied, which will result in the output being the same as
the input, where swscale set them to the equivalent of fully opaque.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
And add a few more tests to ensure all the pixfmts affected by this change
are tested.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Forgotten in 601a3479466f4f03d27487dfc6fcb9430efb8fc6.
Found-by: ramiro
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Mistakenly written in native endianness in 42098f92662c47659df85173d8076b62a23269aa.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
As with other pixel formats, set the undefined alpha bits to opaque.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
As with other pixel formats, set the undefined alpha bits to opaque.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Should fix fate-checkasm-sw_rgb under gcc-ubsan.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The demuxer's 'missing_streams' private option is used to communicate
information from the demuxer to avformat_find_stream_info(). However,
that is not only unnecessarily complicated, it also leaks internal
information to users, e.g. this option appears in the results of the
fate-flv-demux test.
Use a new field in FFFormatContext to communicate this information
instead.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
stddev and PSNR values change by the removal of format conversion and because
of the added sws_flags. Either or will have the same effect even on their own.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This format is useful for doing certain lossless transforms on images,
RCT in particular, which require you to escalate the size from 16 to
32 bits to avoid overflows.
APIchanges will be done alongside when comitting.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
md5 values change because the nut container now reports rawvideo as encoder
and Y410 as codec type instead of the bogus RGB[15].
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@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>
Signed-off-by: Paul B Mahol <onemda@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>
Signed-off-by: Paul B Mahol <onemda@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>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@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>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This maps to the 444YpCbCr10 pixel format as defined by Apple.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This maps to the 444YpCbCr8 pixel format as defined by Apple, which is ordered
Cr Y' Cb.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This maps to the 4444YpCbCrA8 pixel format as defined by Apple, which is ordered
Cb Y' Cr A.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This maps to the 4444AYpCbCr8 pixel format as defined by Apple, which is ordered
A Y’ Cb Cr.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Also, add sws_flags matching other similar tests while at it.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Add code for detecting the feature on Linux and Windows.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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).
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
