This made the output non binary reproducible across different versions of
zlib.
This reverts commit bce5855afb25d318e090c2e6c16117f065458356.
Signed-off-by: James Almer <jamrial@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.
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>
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.
FATE results differ when using the original zlib and zlib-ng.
Since we don't need to test the result from zlib itself, this commit
disables compression on tests for zlib-based codecs, which ends up
giving the same results with both libraries.
Signed-off-by: James Almer <jamrial@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>
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>
Fix "ost->st->avg_frame_rate = ost->frame_rate" in streamcopy_init()
being reset to input's frame rate a few lines below.
Note that in current code, there are some discrepancies amongst the
muxers. For example, avienc relies on time_base, so it is not affected
by this patch, whereas mxfenc and matroskaenc do use avg_frame_rate,
so this patch fixes -r being honored.
In the updated fate test, the input is (wrongly) probed as 50fps. With
this patch, the correct value (25fps) is successfully forced with -r.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The time_base was a bad guess.
Currently, fate-time_base test data assumed that overriding the input
time_base would affect the frame_rate, but this behaviour is not
documented, so just fix the fate data now that this is fixed.
Fix regression since 10185e2d4c:
previously, when streamcopying, the time_base was guessed from the
frame_rate considering it is often constant, so guessing the frame_rate
back from the time_base was often not a problem.
To reproduce:
ffmpeg -i fate-suite/mpeg2/dvd_still_frame.vob -an -c copy out.mxf
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When collecting performance information from checkasm it is common
to parse the output for use in graphs to compare vs different
architectures.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Replace the manually specified chroma location by one using standard
notation, arbitrarily "bottomleft" as it is a less common path.
Required if we want to phase out the use of manual chroma locations.
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references the SPS, the SPS/PPS
needs to come first.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
F and D extensions are included in all RISC-V application profiles ever
made (so starting from RV64GC a.k.a. RVA20). Realistically they need to be
selected at compilation time.
Currently, there are no consumers for these two flags. If there is ever a
need to reintroduce F- or D-specific optimisations, we can always use
__riscv_f or __riscv_d compiler predefined macros respectively.
This preserves T1 whilst calling the instrumented function. In a Sci-Fi
setting where type-based Control Flow Integrity (CFI) is supported, the
calling code (i.e., the `checkasm` test case) will set T1 to the expected
value of the landing pad label (LPL) of the instrumented function.
The call wrapper will always use LPL zero which is a wild card. We should
preserve the value of T1 at least until the indirect call to the
instrumented function. Of course this is Sci-Fi, because:
1) there is no hardware (or even QEMU) support yet,
2) all our assembler functions currently use LPL zero anyway.
This uses T3 rather than T2 because indirect branches with T2 is reserved
for notionally direct calls made with an indirect call instruction (e.g.
due to GOT indirection), and are exempted from forward-edge CFI checks.
The B extension was finally ratified in May 2024, encompassing:
- Zba (addresses),
- Zbb (basics) and
- Zbs (single bits).
It does not include Zbc (base-2 polynomials).
