Re: [PATCH v3 0/1] MR5340: maintainers: Remove MF GStreamer section.

[Elizabeth Figura (＠zfigura)]

> Please merge this. Like I previously explained I'm not interested in fighting over code, forcing anyone into doing something they don't want, or in endless and pointless ideological discussions.
>
> I'm now pretty much convinced that GStreamer is not a good choice as a backend because of the impedance mismatch and the amount of dogma that apparently comes with it. I will probably start looking into other options.

All else aside, there is no dogma about winegstreamer. As maintainer, I tried to use my experience working with the component to architect the best design that accommodates all of the necessary fixes and features. As reviewer, I seek to point out functional problems with any new patches. 5998 has some of these functional problems.

Fundamentally the question is one of expediency and correctness, not ideology. 5988 makes use of existing code to fix the same bugs as 5998 proposes to rewrite the entire DLL to fix, and it avoids the problems that 5998 introduces.

GStreamer is a poor fit in some ways, in particular its asynchronous nature and its use of callbacks from new Unix threads. For these reasons, I've never loved it. However, it is also a very good choice in some other ways: it is heavily developed, has extensive codec support, has a stable API, and the project leadership is very open to new APIs. The only other library I know of with extensive enough codec support is ffmpeg, which does *not* have a stable API. Between the two options, I believe that GStreamer is the better one, especially because it already exists and works well.

Moreover, those problems with GStreamer have already been solved, and I've also talked to the project leadership about extending GStreamer to solve them on the other side and simplify our code anyway.

Between (1) GStreamer and Wine as it exists now, (2) GStreamer with future extensions to simplify Wine code, and (3) writing the whole component from scratch in some other library, it is eminently much more expedient to choose the first option, perhaps with an eye to the second, than switching to some other library.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/5340#note_77742