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.
sunyuechi
Timo Rothenpieler
Lynne
James Almer
Martin Storsjö
J. Dekker
Marton Balint
Geoff Hill
Oneric
Andreas Rheinhardt
Sean McGovern
Anton Khirnov
Tobias Rapp
Zhao Zhili
Jan Ekström