Increase the tolerance from 10 ulp to 11 ulp. This fixes occasional
errors for some inputs; the errors could be reproduced on
aarch64/neon builds, with "checkasm --test=ac3dsp 3446175925".
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This test confirms that we can write mDCv and cLLi chunks and read them
back via the png decoder. It uses an HEVC conformance sample with this
metadata as the base source for the side data in the frames.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Jan Ekström <jeebjp@gmail.com>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Stop trying to invent some "framerate-based" timebase when there is no
reason to think the stream is CFR at all.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This lets us detect when a container has flagged a stream as multilayer.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Do not pass an options dictionary to the avcodec_open2() in enc_open().
This is cleaner and more robust, as previously various bits of code
would try to interpret the contents of the options dictionary, with
varying degrees of correctness. Now they can just access the encoder
AVCodecContext directly.
Cf. 372c78dd42f2b1ca743473b9c32fad71c65919e0 - analogous change for
decoding.
A non-progressive field order is now written on the container level in
interlaced ProRes encoding tests.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Rajiv Harlalka <rajivharlalka009@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Perform av_clip_int16(val) _after_ copying the value to last_dc.
This change ensures that clipping is applied only within the context of
the current block, preventing the propagation of clipped values to
subsequent DC components.
Related commits: c28f648b19 and dffae122d0
Related ticket: 4683
Signed-off-by: Paul B Mahol <onemda@gmail.com>
A picture's virtual boundaries will split a CTU into 4 ALF blocks.
The ALF virtual boundary may cross or not cross a ALF block.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.
This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.
The API was committed a few days ago, so changing this field now
is within the realms of acceptable.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
p0_10.j2k is one of the reference codestreams included in Rec. ITU-T T.803 | ISO/IEC 15444-4.
Adding this test was made possible by commit 6f4a95cfb8e6ed97fdd1027251181caded44860f.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)
This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Prevent potential divisions by 0 when using them immediately after allocation.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
ffprobe is meant to generate parseable output, and if a field is present, it
should be printed even if it has a default value.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
These tables are supposed to contain the number of bits needed
to encode a given (run, level) pair. Yet the number of bits
for pairs needing the escape code was wrong (it only contained
the escape code and not the bits needed for run and level).
Furthermore, H.261 (a format with explicit end-of-block codes)
does not work well together with the RLTable API from rl.c:
The EOB code is the first one in ff_h261_rl_tcoeff's VLC table
and has a run value of zero. Therefore the result of get_rl_index()
is off by one for run == 0 and level values with explicit
(run, level) pair.
Fixing this necessitated changing the ref files of the
vsynth*-h261-trellis tests. Both filesizes as well as PSNR
decreased. If one used a qscale value of 11 for this test,
one would have received files with about the same size as
before this patch (with qscale 12), but with better PSNR.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Not every function will be set, so zero the context
to initialize everything.
This also allows to remove an initialization in dvenc.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
MECmpContext.ildct_cmp is an array of function pointers that
are not set by ff_me_cmp_init(), but that are set by users
to one of the other arrays via ff_set_cmp().
Remove these pointers from MECmpContext and add pointers
for the actually used functions to its users. (The DV encoder
already did so.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
MECmpContext has several arrays of function pointers that
are not set by ff_me_cmp_init(), but that are set by users
to one of the other arrays via ff_set_cmp().
One of these other users is mpegvideo_enc; it is the only user
of MECmpContext.frame_skip_cmp and it only uses one of these
function pointers at all.
This commit therefore moves this function pointer to MpegEncContext;
and removes the array from MECmpContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
MECmpContext has several arrays of function pointers that
are not set by ff_me_cmp_init(), but that are set by users
to one of the other arrays via ff_set_cmp().
One of these other users is the motion estimation API.
It uses MECmpContext.(me_pre|me|me_sub|mb)_cmp. It is
basically the only user of these arrays.
This commit therefore moves these arrays to MotionEstContext;
this has the additional advantage of making motion_est.c
more independent from MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Before After
-------------------------------------------------
make fate-vvc CPU Time (No ASM) 131.52s 134.83s
libavcodec/vvc/* Line Coverage 95.3% 96.9%
inter_template.c Line Coverage 74.3% 88.2%
inter.c Line Coverage 85.3% 99.2%
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Otherwise a bunch of SEI units that should not be in hvcC will be included,
and generate different output with builds where extract_extradata_bsf is not
present.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The check should be >= 0, not > 0. The check itself is redundant
since uninit only being called after init is success.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes valgrind warnings after 18adaf9fe558587cb1b707c647af83015b69da48.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Also make the iso_channel_position table consistent with what the AAC decoder
uses in avcodec/aac/aacdec_usac.c.
Fate changes are caused by the change of how 7.1 layout is mapped, previously
it included Side Surround channels, now it includes the Surround channels.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Besides being write only it had the wrong type:
An uint8_t is definitely not enough to store the size
of these buffers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Due to hysterical raisins, most RISC-V Linux distributions target a
RV64GC baseline excluding the Bit-manipulation ISA extensions, most
notably:
- Zba: address generation extension and
- Zbb: basic bit manipulation extension.
Most CPUs that would make sense to run FFmpeg on support Zba and Zbb
(including the current FATE runner), so it makes sense to optimise for
them. In fact a large chunk of existing assembler optimisations relies
on Zba and/or Zbb.
Since we cannot patch shared library code, the next best thing is to
carry a flag initialised at load-time and check it on need basis.
This results in 3 instructions overhead on isolated use, e.g.:
1: AUIPC rd, %pcrel_hi(ff_rv_zbb_supported)
LBU rd, %pcrel_lo(1b)(rd)
BEQZ rd, non_Zbb_fallback_code
// Zbb code here
The C compiler will typically load the flag ahead of time to reducing
latency, and can also keep it around if Zbb is used multiple times in a
single optimisation scope. For this to work, the flag symbol must be
hidden; otherwise the optimisation degrades with a GOT look-up to
support interposition:
1: AUIPC rd, GOT_OFFSET_HI
LD rd, GOT_OFFSET_LO(rd)
LBU rd, (rd)
BEQZ rd, non_Zbb_fallback_code
// Zbb code here
This patch adds code to provision the flag in libraries using bit
manipulation functions from libavutil: byte-swap, bit-weight and
counting leading or trailing zeroes.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Instead of an ad-hoc scheme. Also, combine skipping RASL frames with
skip_frame handling - current code seems flawed as it only executes for
the first slice of a RASL frame and unnecessarily unsets is_decoded,
which should not be set at this point anyway..
Some RASL frames in fate-hevc-afd-tc-sei that were previously discarded
are now output.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
B0 is defined by system header, see f0f596dbc6 for ref.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
src is apparently not guaranteed to be >8 byte aligned, but align to 16
nonetheless as the x86 asm will do unaligned loads anyway.
dst is guaranteed to be 32 byte aligned for the Y plane, but 16 byte for UV.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Test all four pixel formats, but only bench the two native endian ones for a
given target.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The MMXEXT versions of the rgb2rgb functions tested here
always emit emms on their own. Therefore one can use
a stricter test to ensure that it stays that way.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
There is no benefit in using it: The fast path of copying
is not taken because of misalignment; furthermore we are
only dealing with a few byte here anyway, so simply copy
the bytes manually, avoiding the dependency on bitstream.c
in lavf (which also contains a function that is completely
unused in lavf).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
A 360 video specific tool
see https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9503377
passed files:
DMVR_A_Huawei_3.bit
WRAP_D_InterDigital_4.bit
WRAP_A_InterDigital_4.bit
WRAP_B_InterDigital_4.bit
WRAP_C_InterDigital_4.bit
ERP_A_MediaTek_3.bit
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The OS may silently fix (emulate) unaligned hardware access exceptions.
This is extremely slow and code should be fixed not to rely on unaligned
access on affected hardware. Accordingly this requests that the OS
disable emulation and instead throw Bus error, which will be caught by
checkasm's signal handler.
This has no effects if the hardware supports unaligned access in
hardware, since no exceptions are generated. prctl() will fail safe in
that case.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The line width 8 is supposed to test corner case, while the
performance doesn't matter. Width 1080 is also a case of
unaligned to 16.
Width 1920 meant for benchmark (together with --runs options).
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Starting off small with a few features.
Samples and reference decoded files copied from the official ISO
reference suite.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
From Benjamin Bross:
> for ALF where functions are in increments of 4 while 8 should be sufficient according to the spec.
Signed-off-by: Wu Jianhua <toqsxw@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
According to the VVC specification (section 8.5.1), the maximum width/height of a subblock passed for DMVR SAD is 16. This along with previous constraint requiring width * height >= 128 means that 8x16, 16x8, and 16x16 are the only allowed sizes.
This changes check_vvc_sad() to only test and benchmark those sizes.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Several files already had standard license header (namely
2-clause BSD files), yet due to the 80 char line length limit,
they were not treated as such by source-check.sh (which
fate-source uses). Therefore relax the BSD check.
Reviewed-by: Rémi Denis-Courmont <remi@remlab.net>
Reviewed-by: Pierre-Anthony Lemieux <pal@sandflow.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
VVC does not have MMX code at all, so one can use the stricter
declare_func to also check that the MMX state has not been clobbered
with (which would be an ABI violation).
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The loop filters can write before the pointer given to them;
the actual test invocations correctly used an offset, while
the benchmark calls were lacking an offset. Therefore, when
running with benchmarking, these tests could have spurious
failures.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Some timers on certain device and test combinations can produce noisy
results, affecting the reliability of performance measurements. One
notable example of this is the Canaan K230 RISC-V development board.
An option to adjust the number of samples by an exponent (--runs) has
been added, allowing developers to increase the sample count for more
reliable results.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Don't benchmark every single combination of widths and heights;
only benchmark cases which are squares (like in vvc_mc.c).
Contrary to vvc_mc, which increases sizes by doubling dimensions,
vvc_alf tests all sizes in increments of 4. Limit benchmarking to
the cases which are powers of two.
This reduces the number of benchmarked cases from 3072 down to 18.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes fate-source.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This commit is the analog of 3f11eac757
for decoding: It sets the AV_FRAME_FLAG_KEY and (for video decoders)
also pict_type to AV_PICTURE_TYPE_I. It furthermore stops setting
audio frames as always being key frames -- it is wrong for e.g.
TrueHD/MLP. The latter also affects TAK and DFPWM.
The change already improves output for several decoders where
it has been forgotten to set e.g. pict_type like speedhq, wnv1
or tiff. The latter is the reason for the change to the exif-image-tiff
FATE test reference file.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
It reuses the previous frame and does not code unchanged blocks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes "signed integer overflow: [varies] * 104858 cannot be represented in type 'int'" errors
under ubsan.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
E.g. f2de911818 forgot to
add the unused void* here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Forgotten in 5b8faaad6c,
a69a0b689c3c4e1e0bbf4c17716a25e14332a250.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The only multiplicators used in scalarproduct_and_madd_*
are -1, 0 and +1. Yet it is of type int and the checkasm
test uses the complete range of int for it, leading to overflows
that don't happen for actual users.
Fix this by using a more reasonable range for mul: Given
that it is used in v1[i] += v3[i] * mul with v1 being
a 16bit integer, it makes no sense to use values for mul
that don't fit into 16bit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes "runtime error: index 4 out of bounds for type 'uint32_t [3]'" errors
after commit 4ced36744ee0bea5fb7a20d1b2926c588f89ea0b.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
In direct_search() and ff_estimate_b_frame_motion(), penalty_factor
would be used before being initialized in estimate_motion_b(). Also,
the initialization would happen more than once unnecessarily.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
ssd_int8_vs_int16 is only called from encode_block()
in svq1enc.c; it calls it in stages: At stage 0,
the int16_t array contains the difference of two
uint16_t. At each of the following stages, the
int16_t array is filled by subtracting an int8_t from
the current stage's int16_t array. The maximum stage
is five, so the int16_t are in the range
(-255 - 5 * 127)..(255 + 5 * 128).
This commit modifies the checkasm test to only use
values from this range, fixing (undefined) integer overflow
in the test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The requirement is either 8 or 16 bytes alignment, not 32.
This should help finding bugs in asm implementations.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
It ignores and overwrites the previous values.
Fixes running the test under ubsan.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
xHE-AAC relies on the same postfilter mechanism
that Opus uses to improve clarity (albeit with a steeper
deemphasis filter).
The code to apply it is identical, it's still just a
simple IIR low-pass filter. This commit makes it possible
to use alternative constants.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
They contain side data whose size is arch dependent.
This fixes fate failures on 32bit targets.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Using the same input sample as iamf-5_1-copy, in order to compare both test's output
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Enable it only for side data types that don't allow more than one entry.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
We have test to make sure that certain configurations do print
warnings. However, the normal operation of the muxer within this
test always printed a warning, so those tests to check for
extra warnings didn't essentially guard anything.
The warning that always was printed, "track 1: codec frame size is
not set" was not present in the libav fork where this testcase
originated, it was removed in f234e8a32e.
Set the frame size for the audio stream to silence the warning,
and use this frame size in a couple later calculations, and check
that one test configuration doesn't print warnings.
Setting the frame size apparently changes the rounding of a timestamp
in the ismv muxing testcase.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The exclude_guest option only has an effect on x86. Omitting
'exclude_guest' defaults to zero which implies that you can count guest
events should you run one. Some non-x86 kernels just ignore it, while
others (e.g. the Asahi Linux kernels) require the user to explicitly set
the option to 1, i.e. the only behaviour that makes sense when counting
guest events isn't supported.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This is based on a spec at https://aomediacodec.github.io/id3-emsg/,
further based on ISO/IEC 23009-1:2019.
Within libavformat, timed ID3 metadata (already supported by the
mpegts demuxer and muxer) is handled as a separate data AVStream
with codec type AV_CODEC_ID_TIMED_ID3. However, it doesn't
have a corresponding track in the mov file - instead, these events
are written as separate toplevel 'emsg' boxes.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Previously we always assumed that the channels are in native order, even if
they were not. The new channel layout API allows us to signal the proper
channel order, so let's do so.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Note that the config.sh file is left without a shebang, this file is
supposed to be sourced into the current environment.
This commit is purely cosmetic.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Unlike what the old comment suggested, standard ASS has no character
escape mechanism, but a closing curly bracket doesn't even need one.
For manual authored sub files using a full-width variant of an
appropriate font and with scaling and spacing modifiers is a common
workaround.
This is not an option here, but we can still make things much less bad.
Now the desired opening bracket still shows up in libass, and
standard renders will merely display a backslash in its place
instead of stripping the following text like before.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Creating vsynth_lena.yuv needs the FATE suite,
yet several tests in ffmpeg.mak without a dependency
on samples used it as input file. Fix this by using
vsynth1.yuv (which does not have such a dependency)
instead.
Also use vsynth1.yuv in fate-shortest to avoid
the samples dependency in this test, too.
Fixes ticket #10947.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
A namespace is unnecessary here given that all these files
are already in the vvc subfolder.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The ffprobe-test file is generated via ffmpeg and several filters;
the requirements for them were missing.
Also deduplicate this while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Several other tests (e.g. concatdec) examine FATE_LAVF_CONTAINER
in order to enable or disable tests that depend on samples
created by the lavf-container tests; right now this procedure
did not account for CONFIG_FFMPEG.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Both samples rely on a feature our decoder doesn't currently support.
Should fix fate failures on some systems where not even the one single frame
could be generated.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The fits decoder decodes to native pixel formats; so
the fitsdec-gbrap16be fate test failed on BE despite
its name because the reference file is LE.
This patch fixes this by forcing a pixel format;
the forced pixel format is BE, causing a change
in the reference file.
The fitsdec-gbrp16be test was not affected, because
its source file (lena-rgb48.png from tne FATE suite)
is actually biendian (as if someone had multiplied
8bit content by 257...).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The format and the first scale filter ensures that the filter
processing actually happens in high bit depth; the second
scale filter is only necessary for big endian arches.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes filter-metadata-signalstats-yuv420p10 on BE arches.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Precludes the usage of the altivec IDCT which fixes
the avid-meridian FATE test on ppc64be here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
These tests need a scale filter to convert to the prescribed
pixel format (the native format is endian-dependent).
Reviewed-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The reference file uses BGRA pixel format, so request it here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
lavfi does not require aligned buffers, so we can safely apply top/left
cropping by any amount, without passing any special flags to lavc.
Longer term, an even better solution would probably be auto-inserting
the crop filter (or its hwaccel versions) as needed.
Multiple FATE tests no longer need -flags unaligned.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The test depends on the compile option of x265. It failed when
HIGH_BIT_DEPTH isn't enabled. It also failed when asan is enabled
because of memory issue inside of x265, which I don't think can
be fixed within FFmpeg.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
By calling the av_ts_make_time_string2() from the function we can fix the
precision issue.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Forgotten in ecdc94b97f809d5f2b88640842fd0541951ad295.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
In this case in_channel_idx was never set and the default 0 was used.
Suprisingly no one noticed that the respective fate test output was wrong.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This test muxes two streams into a single pcm file, although
the two streams are of course not recoverable from the output
(unless one has extra information). So use the streamhash muxer
instead (which also provides coverage for it; it was surprisingly
unused in FATE so far). This is in preparation for actually
enforcing a limit of one stream for the PCM muxers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The newer of these two are the separate integers for content light
level, introduced in 3952bf3e98c76c31594529a3fe34e056d3e3e2ea ,
with X265_BUILD 75. As we already require X265_BUILD of at least
89, no further conditions are required.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Both of these two structures were first available with X264_BUILD
163, so make relevant functionality conditional on the version
being at least such.
Keep handle_side_data available in all cases as this way X264_init
does not require additional version based conditions within it.
Finally, add a FATE test which verifies that pass-through of the
MDCV/CLL side data is working during encoding.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
These two were added in 28e23d7f348c78d49a726c7469f9d4e38edec341
and 3558c1f2e97455e0b89edef31b9a72ab7fa30550 for version 0.9.0 of
SVT-AV1, which is also our minimum requirement right now.
In other words, no additional version limiting conditions seem
to be required.
Additionally, add a FATE test which verifies that pass-through of
the MDCV/CLL side data is working during encoding.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Additionally, add an API test to check that the no-duplicates
addition works after duplicates have been inserted.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Unbreaks the lavf-fate-hevc.flv FATE test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
In particular, test writing tags with odd strlen.
(These tags are zero-padded to even size.)
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Also make use of the av_channel_from_string() function to determine the channel
id. This fixes some parse issues in av_channel_layout_from_string().
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
We lacked tests which supposed to fail, and there are some which should fail
but right now it does not. This will be fixed in a later commit.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Deduplicates a lot of code.
Some minor differences (mostly white space and inconsistent use of quotes) are
expected in the fate tests, there was no point aiming for exactly the same
formatting.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This makes the wav and pcm demuxer demux bigger packets, which is more
efficient.
As a side effect of the bigger packets, audio durations can become less exact
for command lines such as "ffmpeg -i $INPUT -c:a copy -t 1.0 $OUTPUT".
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
- Remove the 1024 cap on the number of samples, for high sample rate audio it
was suboptimal, calculate the low neighbour power of two for the number of
samples (audio blocks) instead.
- Make the function work correctly also for non-pcm codecs by using the stream
bitrate to estimate the target packet size. A previous version of this patch
used av_get_audio_frame_duration2() the estimate the desired packet size, but
for some codecs that returns the duration of a single audio frame regardless
of frame_bytes.
- Fallback to 4096/block_align*block_align if bitrate is not available.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
