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.
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>
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>
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>
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>
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>
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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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.
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>
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>
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>
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.
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.
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.
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>
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>
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>
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>
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>
- 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>
All versions of MSVC that support C11 (namely >= v19.27)
also support the restrict keyword, therefore av_restrict
is no longer necessary since 75697836b1.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This simplifies the code for checking the output, and can print
the failing output (including a map of matching/mismatching
elements) if checkasm is run with the -v/--verbose option.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Previously it only checked half the output in 8 bit per pixel mode,
as the output actually is 16 bit elements here.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Muxing multiple streams to raw files is allowed but the packets are
interleaved, so the output is dependant of packet size.
Signed-off-by: Marton Balint <cus@passwd.hu>
The samples I found all have 2000 sample packets, and by forcing the packet
size with a bsf we could automagically make muxing work for packets containing
more than 3640 samples.
Signed-off-by: Marton Balint <cus@passwd.hu>
Treat it analogously to stream parameters like format/dimensions/etc.
This is functionally different from previous code in 2 ways:
* for non-CFR video, the frame timebase (set by the decoder) is used
rather than the demuxer timebase
* for sub2video, AV_TIME_BASE_Q is used, which is hardcoded by the
subtitle decoding API
These changes should avoid unnecessary and potentially lossy timestamp
conversions from decoder timebase into the demuxer one.
Changes the timebases used in sub2video tests.
Some encoders, like flac, propagate updated extradata at the end of encoding
as packet side data. Use it to update the relevant codec_config.
Signed-off-by: James Almer <jamrial@gmail.com>
The wav demuxer by default tried to demux 4096-byte packets which caused
packets with very few number of samples for files with high channel count.
This caused a significant overhead especially since the latest ffmpeg.c
threading changes.
So let's use a similar approach for selecting audio frame size which is already
used in the PCM demuxer, which is to read 25 times per second but at most 1024
samples.
Signed-off-by: Marton Balint <cus@passwd.hu>
Since PTS is changed randomly for every audio frame, it matters. Also add some
forgotten filter dependencies.
Signed-off-by: Marton Balint <cus@passwd.hu>
Depending on input chunk size noticable corrpution was hearable, here is an
example command line:
ffplay -f lavfi -i "sine=440:r=8000:samples_per_frame=32,aresample=24000:filter_size=1:phase_shift=0"
Fix this by rounding the fixed point fractions up instead of down.
Signed-off-by: Marton Balint <cus@passwd.hu>
GEN=1 is used to generate reference files in the source tree, not
auto-generated reference samples.
Without this patch GEN=1 could overwrite the auto generated reference files
in each test where they are used causing failures.
Signed-off-by: Marton Balint <cus@passwd.hu>
There is no MMX DSP code for VVC, so one can use the stricter
declare_func which also tests that we are not in MMX mode
at the end of this function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise aacenc.o gets pulled in by the aacencdsp checkasm
test and it in turn pulls the rest of lavc in.
Besides being bad size-wise this also has the downside that
it pulls in avpriv_(cga|vga16)_font from libavutil which are
marked as being imported from another library when building
libavcodec as a DLL and this breaks checkasm because it links
both lavc and lavu statically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Jpeg2000 decoder is decoding in native endian, so let's use the same workaround
as in fate-mxf-probe-applehdr10.
Fixes ticket #10868.
Signed-off-by: Marton Balint <cus@passwd.hu>
Contrary to the existing "fate-checkasm", this always prints the
tool output, and runs all tests at once instead of splitting it up
per target group. This is more useful when the user expects to
look directly at the tool output, instead of being part of a full
fate run.
(On failure with the regular "make fate-checkasm" targets, none of
the tool output is printed, but stored in files. If run with reporting
set up to the FATE website, the individual failures are uploaded there,
but if it is run in some sort of other CI setup, the intermediate files
might not be available afterwards for inspection.)
Signed-off-by: Martin Storsjö <martin@martin.st>
