[FFmpeg-devel] [PATCH] avfilter/asubprocess: add audio subprocess filter

[Ramiro Polla]

Hi,

On Sun, Jun 30, 2024 at 6:19 PM Stefan Westerfeld <stefan at space.twc.de> wrote:
> Am 27.06.24 um 23:35 schrieb Ramiro Polla:
[...]
> Note that this isn't much different than what my asubprocess filter
> would do. However it is less readable and maintainable, and just leaves
> subprocess management to the shell.

The shell is a much more suitable place for subprocess management than FFmpeg.

> As for portability of my asubprocess filter, if building conditionally
> for unix-like-systems only is not an option for you, maybe the code
> could use a library for subprocess management, so that we don't need to
> reinvent the wheel here. I didn't deeply research this yet to evaluate
> all alternatives, but for instance glib-2.0 has portable subprocesses:
>
> https://docs.gtk.org/gio/class.Subprocess.html
>
> so if I would use this, the code should be portable and the ugly parts
> would live in glib-2.0 (where they already have been tested for a long
> time).

There is no way we're going to add any kind of dependency on glib :).

> > Since your project already uses FFmpeg, perhaps you could use it to
> > encode the output and keep the metadata as well. Or provide a simple
> > script that would invoke FFmpeg with the correct parameters.
>
> Yes, using the FFmpeg libs for reading the input and writing the output
> is something I considered before working on the asubprocess filter. It
> would probably be an alternative. However, there are cases where you
> have a video with two audio tracks as input and want to watermark it
> preserving tags in the audio tracks, so in the end I would have to
> implement code to handle video streams as well, which I'd like to avoid,
> especially since the ffmpeg command line utility is very flexible and
> powerful when dealing with video/audio stream transformations.

You can look at doc/examples/ for a base to transcode one audio stream
while copying all others (video included).

> As for using a "simple" script, the complexity of doing this in a script
> and managing lots of audiowmark subprocesses there is also something I'd
> rather avoid, if ffmpeg could do it cleanly, making writing this script
> a lot easier, and avoiding temp files or processing everything in
> multiple passes.

That would just be shifting the burden of managing subprocesses to
FFmpeg, which we would rather avoid.

Regards,
Ramiro