It was never reliable to detect if a filtergraph have sources, because a filter
can act as a source only after some time, for example the loop filter.
So it is better to remove the source detection entirely and always give the
scheduler an oppurtunity to stop processing.
Fixes ticket #11604.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Niklas Haas <git@haasn.dev>
This fix failure:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda \
-i The_Beauty_of_Earth-1.mp4 \
-vf scale_cuda=2880:1440 \
-c:v hevc_nvenc \
-pix_fmt cuda \
-b:v 8M -c:a copy \
-y test_scale.mp4
> Reconfiguring filter graph because hwaccel changed
> Impossible to convert between the formats supported by the filter
> 'Parsed_scale_cuda_0' and the filter 'auto_scale_0'.
> Error reinitializing filters!
Signed-off-by: Zhao Zhili <quinkblack@foxmail.com>
"Reconfiguring filter graph because video parameters changed to yuv420p10le(pc, bt709), 1920x1080, unspecified alph"
Fixup f07573f
Adding a missing space fixed this.
Firstly, mathops.h is a private header of libavcodec and should not be used
in fftools. It may reference libavcodec internal symbols, causing link
error with dynamic library, e.g.,
fftools/ffmpeg_filter.c:2687: undefined reference to `ff_rv_zbb_supported'
Secondly, mid_pred operates on int types, while current use case is
int64_t.
Currently, the thread loop of ffmpeg_filter essentially works like this:
while (1) {
frame, idx = get_from_decoder();
err = send_to_filter_graph(frame);
if (err) { // i.e. EOF
close_input(idx);
continue;
}
while (filtered_frame = get_filtered_frame())
send_to_encoder(filtered_frame);
}
The exact details are not 100% correct since the actual control flow is a bit
more complicated as a result of the scheduler, but this is the general flow.
Notably, this leaves the possibility of leaving a no-longer-needed input
permanently open if the filter graph starts producing infinite frames (during
the second loop) *after* it finishes reading from an input, e.g. in a filter
graph like -af atrim,apad.
This patch avoids this issue by always querying the status of all filter graph
inputs and explicitly closing any that were closed downstream; after each round
of reading output frames. As a result, information about the filtergraph being
closed can now propagate back upstream, even if the filter is no longer
requesting any input frames (i.e. input_idx == fg->nb_inputs).
Fixes: https://trac.ffmpeg.org/ticket/11061
See-Also: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20457#issuecomment-6208
The graph string is either freed or attached to the filtergraph, so it's best to
not leave a dangling pointer with the caller.
Signed-off-by: James Almer <jamrial@gmail.com>
This keeps global and per frame side data clearly separated, and actually
propagates the former as it comes out from the buffersink filter.
Signed-off-by: James Almer <jamrial@gmail.com>
Certain parameters, like calculated framerate, are unavailable when connecting
the output of a filtergraph to the input of another.
This fixes command lines like
ffmpeg -lavfi "testsrc=rate=1:duration=1[out0]" -filter_complex "[out0]null[out1]" -map [out1] -y out.png
Signed-off-by: James Almer <jamrial@gmail.com>
The function name 'file_read' is too generic and conflicts with a function
of the same name in the NuttX kernel. Since NuttX links kernel and userspace
into a single binary, this causes a symbol collision when building FFmpeg tools.
Signed-off-by: caifan3 <caifan3@xiaomi.com>
Currently, while the filter graph is being initially created, the scheduler
continues demuxing frames on the last input that happened to be active before
the filter graph was complete.
This can lead to an excess number of decoded frames "piling" up on this input,
regardless of whether or not it will actually be requested by the configured
filter graph. Suspending the filter graph during this initialization phase
reduces the amount of wasted memory.
alfilter_graph_request_oldest() might return EAGAIN and produce a frame on not
the oldest sink.
Fixes ticket #11597.
Fixes excessive frame buffering in #10959.
Fixes excessive frame buffering in #11366.
Signed-off-by: Marton Balint <cus@passwd.hu>
As the names imply, they are structs meant to be internal and private to the
filter handling code. If a field is required in other modules, then it can
be moved to the public facing structs, which is done in this commit.
Signed-off-by: James Almer <jamrial@gmail.com>
As the name implies, it's a struct meant to be internal and private to the
filter handling code. If a field is required in other modules, then it can
be moved to the public facing struct, which is done in this commit.
Signed-off-by: James Almer <jamrial@gmail.com>
The key benefits are:
- Different to other graph printing methods, this is outputting:
- all graphs with runtime state
(including auto-inserted filters)
- each graph with its inputs and outputs
- all filters with their in- and output pads
- all connections between all input- and output pads
- for each connection:
- the runtime-negotiated format and media type
- the hw context
- if video hw context, both: hw pixfmt + sw pixfmt
- Output can either be printed to stdout or written to specified file
- Output is machine-readable
- Use the same output implementation as ffprobe, supporting multiple
formats
Signed-off-by: softworkz <softworkz@hotmail.com>
This is a replacement in ffmpeg for the deprecated avcodec flag AV_CODEC_FLAG_DROPCHANGED.
This option is meant to be used when the filtergraph should not be
reinited upon input parameter changes as that leads to loss of state
in the filtergraph potentially leading to broken or aborted output,
e.g. inserting of silence with first_pts specified in aresample.
Generally useful to avoid corrupted yet decodable packets in live
streaming inputs.
This option when enabled takes precedence over reinit_filters
The ///< or /**< form of doxygen comments are only to be used
when the documentation follows the member and the comment
block starts on the same line as the member. This commit
fixes wrong uses of them; in particular, this fixes the comment
for mb_height in H.264 SPS's structure which was wrongly added
to mb_width.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some frames may be buffered before a complex filtergraph can be configured.
This change ensures the side data removal in the cases where autorotation is
enabled also applies to them.
Fixes ticket #11487
Signed-off-by: James Almer <jamrial@gmail.com>
Global side data as exported by a decoder may no longer apply if a filter in
the chain altered the frames in some form, like changing color, dimensions,
or channel layout information.
After this change, any such changes in side data will be taken into account by
the encoder futher in the process.
Signed-off-by: James Almer <jamrial@gmail.com>
I.e. those that are only used to figure out input/output counts, since
some filters might expect a valid hw device in init and refuse to
initalize otherwise.
This requires complex filtergraphs to be created in a separate step
after parsing global options, after all hw devices are guaranteed to
exist.
The log message was logged for `filtergraphs[j]` which would cause a
heap buffer overflow in certain circumstances.
Correctly it should be logged for the current filtergraph, so just
use `fg` here.
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().
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.