iec61883_parse_queue_hdv() is only called when the mpegts-demuxer
is available and can be optimized away when not. Yet this
optimization is not a given and it fails with e.g. GCC 11 when
using -O0 in which case one will get a compilation error
because the call to the unavailable avpriv_mpegts_parse_packet()
is not optimized away. Therefore #if the offending code away
in this case.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes build errors if libzvbi is enabled while libzvbi_teletextdec
is disabled.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
parse_rtsp_message() is only called if the rtsp demuxer is enabled
and so it is normally compiled away if said demuxer is disabled.
Yet this does not happen when compiling with -O0 and this leads
to a linking failure because parse_rtsp_message() calls functions
that may not be available if the rtsp demuxer is disabled.
Fix this by properly #if'ing the unused functions away.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All the AMRWB samples are in a mov container.
Also use FATE_SAMPLES_FFMPEG instead of FATE_SAMPLES_AVCONV.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AMR muxer doesn't have a private context, so it's priv_data
will be NULL. If it weren't, simply setting it to NULL would lead
to a memleak.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 1f447fd95463bbf39a78d886359a3006d82f6a94.
Also only enable amr_probe() and amr_read_header() in case
the AMR demuxer is enabled; this avoids having to add
a rawdec.o dependency to the muxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: John-Paul Stewart <jpstewart@personalprojects.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Peter Ross <pross@xvid.org>
Only allocate an audio stream if there is one in the data. Silicon
Graphics movie format will contain default values (16 bit samples, 2
audio channels, 22050 Hz sample rate) even when no audio is present in
the file. This confuses FFmpeg into thinking such an audio stream is
present with 0 samples in it.
There is a flag value in the format to indicate whether or not audio is
present. This patch checks that and behaves accordingly.
Signed-off-by: John-Paul Stewart <jpstewart@personalprojects.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Peter Ross <pross@xvid.org>
While this function on its own passes all of fate-hevc, there's
indications that the function might need to handle widths that
aren't a multiple of 8 (noted in commit
f63f9be37c799ddc835af358034630d31fb7db02, which later was
reverted).
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: signed integer overflow: 1074134419 - -1075212485 cannot be represented in type 'int'
Fixes: 43273/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-4706880883130368
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In this case ff_isom_put_dvcc_dvvc() might not be available, leading
to linking failures. Given that WebM currently doesn't support DOVI,
this is fixed by #if'ing the offending code away if the Matroska
muxer is not enabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Split packed data in case of its contains multiple show frame in some
non-standard bitstream. This can benefit decoder which can decode
continuously instead of interrupt with unexpected error.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Most users only want to either read or write golomb codes, not both.
By splitting these headers one avoids having unnecesssary
(get|put)_hits.h inclusions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 555f5c1fc5ae0c4e7b0431dc3166c3fcf3f4e979.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes compilation errors in case nvenc is enabled
(e.g. autodected) with both nvenc-based encoders disabled
because nvenc uses ff_alloc_a53_sei(), yet only the nvenc-based
encoders require atsc_a53.
(This error does not manifest itself in case of static linking
(nothing pulls in nvenc.o), but it exists with shared builds.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds a blend_vulkan filter and a normal blend mode, and
reserves support for introducing the blend modes in the future.
Use the commands below to test: (href: https://trac.ffmpeg.org/wiki/Blend)
I. make an image for test
ffmpeg -f lavfi -i color=s=256x256,geq=r='H-1-Y':g='H-1-Y':b='H-1-Y' -frames 1 \
-y -pix_fmt yuv420p test.jpg
II. blend in sw
ffmpeg -i test.jpg -vf "split[a][b];[b]transpose[b];[a][b]blend=all_mode=normal,\
pseudocolor=preset=turbo" -y normal_sw.jpg
III. blend in vulkan
ffmpeg -init_hw_device vulkan -i test.jpg -vf "split[a][b];[b]transpose[b];\
[a]hwupload[a];[b]hwupload[b];[a][b]blend_vulkan=all_mode=normal,hwdownload,\
format=yuv420p,pseudocolor=preset=turbo" -y normal_vulkan.jpg
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
mpegaudiodec_template.c uses stuff from mpegaudiodata directly,
yet this dependency was only indirectly fulfilled via mpegaudio-headers
before 33e6d57f01dd4742a2e25ac5fa072b487d9d02ce. Since this commit,
the latter only needs (and therefore provides) mpegaudiotabs,
leading to compilation failures.
This commit adds this missing direct dependency directly.
(Sorry for not having checked indirect dependencies.)
Found-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The string for AV_OPT_TYPE_STRING AVOption gets freed by av_opt_free()
when closing the AVCodecContext
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The SDK checks Data.V when using system memory for VP9 encoding. This
fixed the error below:
$ ffmpeg -qsv_device /dev/dri/renderD129 -f lavfi -i yuvtestsrc -c:v
vp9_qsv -f null -
[vp9_qsv @ 0x55b8387cbe90] Error during encoding: NULL pointer (-2)
Video encoding failed
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The test /libavutil/tests/hwdevice checks that when deriving a device
from a source device and then deriving back to the type of the source
device, the result is matching the original source device, i.e. the
derivation mechanism doesn't create a new device in this case.
Previously, this test was usually passed, but only due to two different
kind of flaws:
1. The test covers only a single level of derivation (and back)
It derives device Y from device X and then Y back to the type of X and
checks whether the result matches X.
What it doesn't check for, are longer chains of derivation like:
CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4
In that case, the second derivation returns the first device (CUDA3 ==
CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new
OpenCL4 context instead of returning OpenCL2, because there was no link
from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1)
If the test would check for two levels of derivation, it would have
failed.
This patch fixes those (yet untested) cases by introducing forward
references (derived_device) in addition to the existing back references
(source_device).
2. hwcontext_qsv didn't properly set the source_device
In case of QSV, hwcontext_qsv creates a source context internally
(vaapi, dxva2 or d3d11va) without calling av_hwdevice_ctx_create_derived
and without setting source_device.
This way, the hwcontext test ran successful, but what practically
happened, was that - for example - deriving vaapi from qsv didn't return
the original underlying vaapi device and a new one was created instead:
Exactly what the test is intended to detect and prevent. It just
couldn't do so, because the original device was hidden (= not set as the
source_device of the QSV device).
This patch properly makes these setting and fixes all derivation
scenarios.
(at a later stage, /libavutil/tests/hwdevice should be extended to check
longer derivation chains as well)
Reviewed-by: Lynne <dev@lynne.ee>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Tested-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
libplacebo supports automatic dolby vision application, but it requires
us to switch to a new API. Also add some logic to strip the dolby vision
metadata from the output frames in any case where we end up changing the
colorimetry.
The libplacebo dependency bump is justified because neither 184 nor 192
are part of any stable libplacebo release, so users have to build from
git anyways for this filter to exist.
Signed-off-by: Niklas Haas <git@haasn.dev>
