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 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>
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>
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>
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>
