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

From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue
Date: Thu, 14 Dec 2023 08:48:38 +0100
Message-ID: <170254011817.8914.11563902500718557350@lain.khirnov.net> (raw)
In-Reply-To: <ZXpQsKbNogNlor3i@mariano>

Quoting Stefano Sabatini (2023-12-14 01:47:44)
> 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).

As mentioned elsewhere in the thread, you can just as well pipe raw
video in yuv4mpeg or nut to the video player of your choice and thus
avoid all these hacks.

> 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 have to strongly disagree. This is neither practically workable,
nor a good goal to aim at. This mindset IMO inevitably leads to (among
other problems):
* endless scope creep
* bloated, inefficient, and buggy libraries, trying (and failing) to
  support every use case under the sun
* myopic API design aimed at fulfilling the needs of precisely one
  caller; this is a problem e.g avfilter badly suffers from, and to a
  lesser extent avformat

-- 
Anton Khirnov
_______________________________________________
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".