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

[Rémi Denis-Courmont]

Le 18 décembre 2023 21:58:39 GMT+02:00, Michael Niedermayer <michael at niedermayer.cc> a écrit :
>On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
>> Quoting Stefano Sabatini (2023-12-16 16:18:07)
>> > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
>> > > Anton Khirnov (12023-12-14):
>> > [...]
>> > > > I have to strongly disagree. This is neither practically workable,
>> > > > nor a good goal to aim at.
>> > > 
>> > > And I strongly agree with Stefano. Having the tools just thin wrappers
>> > > around the libraries is the only way to ensure the libraries are
>> > > maximally useful for other applications. Otherwise, useful code will
>> > > only reside in the tools and be only available through a clumsy
>> > > command-line interface.
>> > > 
>> > > >			     This mindset IMO inevitably leads to (among
>> > > > other problems):
>> > 
>> > > > * endless scope creep
>> > 
>> > Scope creep is a general tendency in software, as it tends to grow
>> > with more functionality and use cases in mind (FFmpeg itself started
>> > as an MPEG decoder). OTOH there is good and bad scope creep, it is bad
>> > if the functionality goes beyond the original design and core use
>> > case, or if the extension is not carefully designed and suffers from
>> > assumptions which limit how the software can be used. For example,
>> > making constraints about where the main thread can be executed.
>> > 
>> > (Unrelated note: I greatly appreciate Anton's threaded architecture
>> > endeavor, and I'm fine with the idea that something can result broken
>> > as a consequence of a major redesign, but I also think we should fix
>> > what can be fixed rather than just dismiss that as "not useful".
>> 
>> The entire question here is whether SDL muxing is useful enough to
>> warrant massive hacks in ffmpeg CLI.
>
>I think the first question is, does this actually need
>"massive hacks in ffmpeg CLI" ?

>If you ignore the recommandition that SDL should be run from the main
>thread then iam not sure what change would be needed in ffmpeg CLI at all.

As others noted earlier, that won't work for Mac and Windows.

>If you do want to run it in the main thread, well theres the option
>for the muxer to launch a seperate process by some way internally.

Starting a process from a library is not very practical. You need to locate the executable and the way to do that is different if you're working with a proper installation, or testing in the development tree.

I reckon that testing is a big motivation for the SDL code, so this can't be simply ignored.

And then you need an IPC, which is not portable, and not very different from the piping alternative proposal up-thread.

>then it has its own main thread (not great but its a clean solution)
>
>teh 2nd question is, is SDL the only thing requireing "main thread" or
>some "single thread" or other limitation ?

On Windows, it requires its own thread to use a single-threaded COM apartment. On Mac, it must run on the main thread to access GUI functionality. Main thread here means the initial thread in the address space.

>does any other decoder, encoder, muxer, demuxer, filter ... use an
>external lib thats not fully thread safe ? or has funny limitations ?

>The last option would maybe be to run some sort of AVExecutor on the
>main thread and allow things like muxers to que operations on it.
>The  muxers would totally unchanged be running on a random thread
>but que some operation on the main thread if an external lib, driver or
>other needs it.

To me, that counts as a horrible hack for a library to have, TBH. And if nothing other than SDL on Mac would even need this, then it's very much an ad-hoc kludge.

>Naively that feels relatively clean to me
>
>thx
>
>[...]