The function currently writes directly into the input link, which
requires it to be called after the filter has been linked. However, the
documentation does not mention this restriction and the natural place to
call av_buffersink_set_frame_size() during the options-setting stage,
that is before filter init (and so before the input link exists).
This function creates AND initializes a filter, so setting any filter
options after it is wrong. It happens to work when the filter's init
function does not touch the options in question, but is forbidden by the
API and is not guaranteed to remain functional.
Instead, use avfilter_graph_alloc_filter(), followed by setting the
options, and avfilter_init_dict().
The AMF HEVC encoder takes a bool option for whether deblocking filter
should be _disabled_ instead of whether it should _enabled_ like the
AMF H.264 encoder does. The logic was accidentally copied from H.264 to
HEVC without negating the bool value, so the deblocking filter was
actually disabled when AV_CODEC_FLAG_LOOP_FILTER was set.
Before this patch:
------------------
no flags set => deblocking filter on
flags +loop => deblocking filter off
flags -loop => deblocking filter on
After this patch:
-----------------
no flags set => deblocking filter on
flags +loop => deblocking filter on
flags -loop => deblocking filter off
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Since Xcode 15, macOS developer tools use a new linker. The new
linker by default warns for duplicate -l options. As this is a
known and expected thing, not to be considered an issue, ask for
the warning to be silenced.
This silences linker warnings like this:
ld: warning: ignoring duplicate libraries: '-lc++', '-lcrypto', '-lm', '-logg', '-lpthread', '-lssl', '-lvorbis', '-lvpx', '-lz'
The linker can also warn about duplicate -rpath options, and there's
currently no option to silence those warnings.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds a condition that was missed in
b1ee2af843, fixing compilation on
toolchains that don't support SVE.
Signed-off-by: Martin Storsjö <martin@martin.st>
There's no direct processor feature constant for I8MM alone, but
there is a flag for SVE-I8MM (added in WinSDK 10.0.26100 and
recent versions of mingw-w64). If SVE-I8MM is available, we can
assume that I8MM is available.
While HW supporting these features isn't yet commonly running
Windows, this at least allows detecting and running the I8MM codepaths
in Windows builds in Wine (possibly running in QEMU).
Signed-off-by: Martin Storsjö <martin@martin.st>
With this, nothing in ffmpeg_filter acesses OutputStream anymore, thus
there are no more direct ties between filtering and muxing.
Rename init_simple_filtergraph() to fg_create_simple() for consistency.
It is no longer used for anything besides a sanity-checking assert.
Rename the function to ofilter_bind_enc(), as it no longer has any
assumptions about the target being an output stream.
Pass them to ofilter_bind_ost() via OutputFilterOptions, as is done for
most other data it needs. OutputStream.[max_]frame_rate/force_fps are no
longer used outside of ffmpeg_mux*, and so can be made private.
This is a step toward decoupling encoders from muxers.
