As described in section F.6.1 from ETSI TS 102 366.
Found-by: nyanmisaka
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 17729aa80c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 1b643e3f65)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
(cherry picked from commit 7b7b7819bd)
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>
(cherry picked from commit e9778d20a4)
Actual frame durations are, in general, not computable without buffering
a frame.
FIxes#10886
(cherry picked from commit fa110c32b5)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This filter produces VFR output in general.
Avoids dropping frames in the setpts test.
(cherry picked from commit f121d954ac)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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>
(cherry picked from commit edb1f1bc09)
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>
James Almer
Michael Niedermayer
Felicia Lim
Andreas Rheinhardt
Anton Khirnov
Zhao Zhili
Marton Balint
Jan Ekström
Gyan Doshi
Zhu Pengfei