This allows upstream filters to observe EOF on their corresponding outputs
and terminate early, which is particularly useful for decoders and demuxers
that may then gracefully release their resources.
Prevents "leaking" memory for previously used, but now unused, filter inputs.
THis is currently done by sch_demux_send() (via demux_stream_send_to_dst()),
sch_enc_send() (via enc_send_to_dst()), and sch_dec_send() (via
dec_send_to_dst()), but not by sch_filter_send().
Implement the same queue-closing logic for them. The main benefit here is that
this will allow them to mark downstream inputs as send-done (in addition
to received-done), which is useful for a following commit.
Cut off a choked demuxer's output codec/filter queues, effectively preventing
them from processing packets while the demuxer is choked. Avoids downstream
nodes from piling up extra input that a demuxer shouldn't currently be
sending.
The main benefit of this is to avoid queuing up excess packets that don't want
to be decoded yet, reducing memory consumption for idle inputs by preventing
them from being read earlier than needed.
Currently, when a demuxer thread is choked, it will avoid queuing more
packets, but any packets already present on the thread queue will still be
processed.
This can be quite wasteful if the choke is due to e.g. decoder not being
needed yet, such as in a filter graph involving concatenation-style filters.
Adding the ability to propagate the choke status to the thread queue directly
allows downstream decoders and filter graphs to avoid unnecessary work and
buffering.
Reduces the effective latency between scheduler updates and changes in the
thread workfload.
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.
This field is just saving (typically) a single pointer indirection; and IMO
makes the logic and graph relations unnecessarily complicated. I am also
considering adding choking logic to decoders and encoders as well, which this
field would get in the way of.
Apart from the unchoking logic in unchoke_for_input(), the only other place
that uses this field is the (cold) function check_acyclic(), which can be
served just as well with a simple function to do the graph traversal there.
I tested this extensively under different conditions and could not come up
with any scenario where using a larger queue size was actually beneficial.
Moreover, having such a large default queue is very wasteful especially
for larger frame sizes; and can in the worst case lead to an extra ~50% memory
footprint per input (with the default 16 threads), regardless of whether that
input is currently in use or not.
My methodology was to add logging in the event of a queue underrun/overrun,
and then observe and then observe the frequency of such events in practice,
as well as the impact on performance. I came up with an example filter graph
involving decoding, filtering and encoding with several input files and
various changes to move the bottleneck around.
I found that, in all configurations I tested, with all thread counts and
bottlenecks, using a queue size of 2 frames yielded practically identical
performance to a queue size of 8 frames. I was only able to consistently
measure a slowdown when restricting the queue to a single frame, where the
underruns ended up making up almost 1.1% of frame events in the worst case.
A summary of my test log follows:
= Bottleneck in decoder =
ffmpeg -i A -i B -i C -filter_complex "concat=n=3" -f null -
== 16 threads ==
=== Queue statistics (dec -> filtergraph) ===
- 8 frames = 91355 underruns, 1 overrun
- 4 frames = 91381 underruns, 2 overruns
- 2 frames = 91326 underruns, 21 overruns
- 1 frame = 91284 underruns, 102 overruns
=== Time elapsed ===
- 8 frames = 14.37s
- 4 frames = 14.28s
- 2 frames = 14.27s
- 1 frame = 14.35s
== 1 thread ==
=== Queue statistics (dec -> filtergraph) ===
- 8 frames = 91801 underruns, 0 overruns
- 4 frames = 91929 underruns, 1 overrun
- 2 frames = 91854 underruns, 7 overruns
- 1 frame = 91745 underrons, 83 overruns
=== Time elapsed ===
- 8 frames = 39.51s
- 4 frames = 39.94s
- 2 frames = 39.91s
- 1 frame = 41.69s
= Bottleneck in filter graph: =
ffmpeg -i A -i B -i C -filter_complex "concat=n=3,scale=3840x2160" -f null -
== 16 threads ==
=== Queue statistics (dec -> filtergraph) ===
- 8 frames = 277 underruns, 84673 overruns
- 4 frames = 640 underruns, 86523 overruns
- 2 frames = 850 underruns, 88751 overruns
- 1 frame = 1028 underruns, 89957 overruns
=== Time elapsed ===
- 8 frames = 26.35s
- 4 frames = 26.31s
- 2 frames = 26.38s
- 1 frame = 26.55s
== 1 thread ==
=== Queue statistics (dec -> filtergraph) ===
- 8 frames = 29746 underruns, 57033 overruns
- 4 frames = 29940 underruns, 58948 overruns
- 2 frames = 30160 underruns, 60185 overruns
- 1 frame = 30259 underruns, 61126 overruns
=== Time elapsed ===
- 8 frames = 52.08s
- 4 frames = 52.49s
- 2 frames = 52.25s
- 1 frame = 52.69s
= Bottleneck in encoder: =
ffmpeg -i A -i B -i C -filter_complex "concat=n=3" -c:v libx264 -preset veryfast -f null -
== 1 thread ==
== Queue statistics (filtergraph -> enc) ==
- 8 frames = 26763 underruns, 63535 overruns
- 4 frames = 26863 underruns, 63810 overruns
- 2 frames = 27243 underruns, 63839 overruns
- 1 frame = 27670 underruns, 63953 overruns
== Time elapsed ==
- 8 frames = 89.45s
- 4 frames = 89.04s
- 2 frames = 89.24s
- 1 frame = 90.26s
The code in the decoder just cares about allocating enough extra hw frames
to cover the size of the queue; but there's no reason we actually *have* to
use this many. We can safely relax the assertion to a <= check.
This is required placement by standard [[maybe_unused]] attribute, works
the same for __attribute__((unused)).
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add a separator line to show_filters() function output to maintain
consistent formatting with other show functions like show_codecs,
show_formats_devices, etc. This provides uniform formatting across
all command-line output functions for better readability and
parsing by external tools.
And add the missing goto fail. This should ensure the alpha mode is set and remove
bogus warnings printed by ffplay.
Signed-off-by: James Almer <jamrial@gmail.com>
d119ae2fd8 removed the loop-breaking condition
received_sigterm.
Thus, signals no longer gracefully shutdown ffmpeg.
Fixes: #10834
Signed-off-by: Patrick Wang <mail6543210@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We don't need to print the tags here because they're added as dict
elements to AVFrame->metadata and are printed elsewhere with ffprobe
-show_frames.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
instead of only AV-specific options. The previous code assumed that any
option not defining the codec in an `ffpreset` file is an AVOption. This
for example prevented the use of options defined in `OptionDef[]`, like
`-pix_fmt`, as part of preset files, requiring users to type these out
every time.
Closes: #1530
Signed-off-by: Andreas Hartmann <hartan@7x.de>
Fixes: signed integer overflow: 10 * 1952737655 cannot be represented in type 'int'
Fixes: PoC_avi_demux
Found-by: 2ourc3 (Salim LARGO)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This code always ignored the user-provided enc_ctx->chroma_sample_location
in favor of the location tagged on the frame. This leads to a very (IMHO)
unexpected outcome where -chroma_sample_location works differently from the
related options like -colorspace and -color_range, the latter of which
override the frame properties as a consequence of being configured on the
filter graph output.
The discrepancy comes from the fact that the chroma sample location does not
itself participate in filter graph negotiation.
Solve the situation by only overriding the enc_ctx option if it was left
unspecified by the user, and otherwise printing a warning if the requested
parameter does not match the frame parameter.
opt_codec() is mostly copied over from ffplay.c.
This is useful when different decoders have different capabilities,
or to test a specific decoder.
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Add av_freep() to free new_elem to avoid memory leak.
Fixes: 3ca1e31e63 ("fftools/cmdutils: Atomically add elements to list of pointers, fix crash")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Regardless of the source being an AVFMT_NOTIMESTAMPS format, if the timestamps
are generated like when using the use_wallclock_as_timestamps demuxer option,
then they are reliable.
Fixes ticket #11268
Signed-off-by: James Almer <jamrial@gmail.com>
CLI option parser checks if argument exists when needed, but in this
case only OPT_TYPE_BOOL where checked, so OPT_TYPE_FUNC without argument
where trying to load a file from `arg` which is NULL in this case.
Fixes crash on `ffmpeg -/version`
Fixes: 6d17991b7e
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Integer writing is impossible here as the first branch was dead code,
so remove it completely.
Fix CID 1646948
Reviewed-by: softworkz <softworkz@hotmail.com>
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>
This would make the goto dead code and also would not properly
call avtext_context_close.
Fix CID 1646939
Reviewed-by: softworkz <softworkz@hotmail.com>
