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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3019 bytes --]

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.

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.
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 ?
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.
Naively that feels relatively clean to me

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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