岑湛权 via ffmpeg-devel (HE12026-05-19):
> libavfilter supports cyclic filter graphs. Without cmd_visited the BFS
> traversal loops forever on such graphs. It is a single int per filter
> context; I do not see a cheaper way to guarantee termination.
You need to allocate something to keep track, but allocating it globally
for such a niche feature is no acceptable: you will need to allocate
what you need yourself and manage it.
I would not object to adding a small integer in AVFilterContext,
initialized at graph configuration, to serve as index into an array for
features that require storing data about other filters.
But before discussing implementations details, let us be sure it is
necessary.
> ffmpeg -f lavfi -i sine=440:d=3 -filter_complex \
> "[0:a]asendcmd=mode=forward:commands='1.0 volume@v1 volume 0.5',\
> volume@v1=1.0,volume@v2=1.0,aformat=sample_fmts=s16[out]" \
> -map "[out]" -y /tmp/out.wav
>
> The chain is: asendcmd → volume@v1 → volume@v2 → aformat → out.
> At t=1s the command starts at v1 and propagates forward (downstream).
> Both v1 and v2 receive "volume 0.5", so the output amplitude becomes
> 0.25 (0.5 × 0.5).
>
> Why existing mechanisms cannot do this:
>
> 1. avfilter_graph_send_command("volume@v1", "volume", "0.5", FLAG_ONE)
> — sets v1 only, does not touch v2.
>
> 2. avfilter_graph_send_command("volume", "volume", "0.5", 0)
> — sets every volume filter in the graph, including unrelated paths.
>
> 3. There is no existing call that means "set this parameter on v1 and
> propagate to everything downstream of it that understands the
> command."
But you can just send the command to both filters explicitly:
1.0 volume@v1 volume 0.5, 1.0 volume@v2 volume 0.5
No need for run-time propagation when you can statically analyze the
graph.
Regards,
--
Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
