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

["Rémi Denis-Courmont" <remi@remlab.net>]

Le 19 décembre 2023 14:51:21 GMT+02:00, Nicolas George <george@nsup.org> a écrit :
>Rémi Denis-Courmont (12023-12-19):
>> Anton's objections are against the horrible hacks necessary to support
>> Mac and Windows, as far as I understand him.
>
>I have not read that. If that is true, maybe he could start with
>refraining from using expressions like “horrible hacks”.
>
>> Of course it's also objectionable for SDL to be modelled as a muxer,
>
>Sigh. Do we have to explain this once again? Devices have to present as
>muxers and demuxers in order to be usable transparently by applications
>designed for plain files. And anyway, the manner frames enter or leave a
>device is orthogonal to the implementation of said device, so bringing
>this question in the discussion is irrelevant.

That's a horrible hack of the kind that makes one infer that whoever wrote the library doesn't understand API design.

>> Running on the main thread (the initial thread of an address space)
>> requires an external executable
>
>No. Or [citation needed].

I don't care if you disagree with the definition of "main thread" in the context of SDL.

>> 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,
>
>It is less than standards-compliant and portable, but it is doable.

You could certainly engineer a custom OS that would allow this, but I don't think that's really relevant, whilst the issue at stake is support for Apple's OS. Hence "essentially impossible" as opposed to "impossible".

>
>> since FFmpeg is not async-fork-safe.
>
>This is something that should be fixed, do you not think?

First, good luck with that. Making FFmpeg work under POSIX fork-safe constraints is simply not realistic, not to mention the underlying libraries that FFmpeg would have to fork (pun unintended). If it were feasible, we wouldn't need to have this argument: somebody could just fix the SDL muxer internals without messing with the FFmpeg APIs.

Second, even if you did succeed at this,  the result would be unmaintainable, as you'd have to mind those constraints for all future code changes.

And third, you would leak memory and resources of other threads that just happened to be allocated to the parent process at the time of fork. This is highly undesirable.
_______________________________________________
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".