Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Alexander Strasser via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

On 2023-12-14 01:47 +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote:
> > Quoting Zhao Zhili (2023-12-12 18:27:39)
> [...]
> > Honestly I don't see how this could be done in ffmpeg CLI without
> > disgusting hacks, but before that the question is:
>
> > why is there an SDL
> > "muxer" and why would anyone want to use it in ffmpeg CLI? What actual
> > use cases does it serve that cannot be better handled otherwise?
>
> As the author of the first sdl.c muxer, maybe I can answer to this
> question. It was done partly as an exercise and for fun, but also
> because this was useful extremely handy for testing (e.g. to display
> the output of a filterchain from ffmpeg, or to display a streamed
> video in realtime).

That is what I used it for countless times as well.

It has a lot of merit in handling compared to piping to a player,
where one needs to run 2 processes in one command line with all
the drawbacks that come with it.


> The final goal was (still is) to unify all the tools as very thin
> instances of the library. Even if this might be not practical, I think
> it is a good final design plan (e.g. ffprobe might be turned to a
> custom muxer, ffplay would be the realtime output of a filtergraph
> connected to a rendering device, ffmpeg would be a data filtergraph
> processor, and you can mix rendering and encoding if you add a movie
> sink to the game).

I agree to this perspective. Making most of the functionality
available through the FFmpeg libs and therefore available for
wider application of a broader audience seems valuable.

Such a big goal that cannot be reached in a predictable time frame
should be challenged over the years and the plans, in so far they
exist, need to be adjusted accordingly. Still that doesn't mean
the goal is not worthwhile or not achievable.


On an ending note: I don't like at all the way this discussion unraveled:
1. Someone wants to fix a reported problem after the new threading changes
2. It is questioned why a feature that exists for over a decade is there

I hope this can get back on a more constructive rail. Otherwise
I fear it just sets precedence for more to come :(


  Alexander
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".