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

[Rémi Denis-Courmont]

Le 19 décembre 2023 11:29:04 GMT+02:00, Nicolas George <george at nsup.org> a écrit :
>Rémi Denis-Courmont (12023-12-19):
>> As others noted earlier, that won't work for Mac and Windows.
>
>If it works on Linux and other real Unixes, it is a lot better than if
>it does not work on any platform. And we should still blame whoever
>broke it rather than whoever is trying to fix it.

Anton's objections are against the horrible hacks necessary to support Mac and Windows, as far as I understand him.

Of course it's also objectionable for SDL to be modelled as a muxer, when it's ostensibly an audio output device and a video output device - not a multiplexer. (SPU blending, lip sync and whatever may require ESs to be processed together should not be tied to SDL.)

>> 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.
>
>You are confusing starting a process and executing a new executable.

Running on the main thread (the initial thread of an address space) requires an external executable, so if somebody is confusing the two, that's not me.

Besides, starting a new process without execution of an executable, in other words, forking without executing, is essentially impossible in a multithreaded Unix-like environment, since FFmpeg is not async-fork-safe. It is also completely impossible on Windows. So the distinction is completely helpless here.

>What? Having an API tu run functions in the main thread is a basic
>feature for any kind of threading architecture.

Oh really? And the POSIX thread function to run on the main thread is what exactly?

You're conflating main-loops and threads here. Thread-safe libraries don't normally depend on a main loop, even less the ability to run idle callbacks on it.