Hi, On Sun, Jun 30, 2024 at 6:19 PM Stefan Westerfeld <ste...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
