Rewriting an entire component is a waste of time if we don't fully understand a deadlock and why Windows avoids it, and why we can be sure we will also avoid it.
At least it would be frontend API specific problems to solve, which can be solved without worrying about breaking other frontends with some backend threading changes.
I don't understand this, sorry. How does changing the library we use make this any more "frontend API specific problems"?
And, again, we can change the threads we make read requests from without needing to rewrite anything. You can handle pending read requests from the same thread that you call wg_parser_stream_get_buffer() from.
Sure through very convoluted ways we maybe can. FFmpeg is simply better there because it doesn't force any threading pattern upon us.
Queueing requests and consuming them isn't convoluted. That's a ubiquitous pattern.
Anyway, having experimented with FFmpeg up to the point where it mostly passes all our tests, I can say that it's definitely a better fit for us as a backend.
- It doesn't force any unix side threads upon us, it can still use internal decoding threads but hides them and we don't need to care,
ffmpeg doesn't actually guarantee that in the documentation. If we're willing to rely on internals like that, we can get the same behaviour from gstreamer by overriding the default thread pool.
- it is performing better in every decoding scenario I tried with (20% faster on a given H264 4K video),
20% speed difference cannot possibly be attributable simply to glue. Was GStreamer using avdec_h264 here? Was software decoding being used in both cases?
- it is simpler, the whole branch is ~6K LoC shorter than winegstreamer, while passing most of the tests (with some additional successes, and a couple of remaining failures),
That can't possibly be true; there's only 6000 lines of GStreamer glue in the first place. (And about a thousand lines of that would go away if we didn't have two separate paths to translate media types.)
- most of the code is moved to the frontend modules, IMO much better for maintainability, given how hard it has been to get reviews for the MF media source, I'd say that's a huge win.
I don't even understand this. The code that's on the Unix side of winegstreamer is Unix side glue, I don't even see why any of it would be moved to the PE side without unnecessarily convolution or duplication. And whether someone reviews and points out problems with code has nothing to do with where it is. Since I've been ousted as maintainer it's not like I have any say over the "backend" compared to the "frontend" anyway.
Now, with that said, here are the problems I see with ffmpeg and this rewrite:
(1) Much worse documentation. Many symbols simply aren't documented.
(2) Narrower codec support. Perhaps nobody cares about this except for our users, but broad codec support is a useful feature. By virtue of wrapping ffmpeg, GStreamer necessarily has broader support.
(3) In 23 years of existence, GStreamer has broken backwards compatibility once. ffmpeg was started at about the same time and has broken backwards compatibility 61 times.
(4) This rewrite throws away 7 years of active development and maintenance, and understanding of the GStreamer libraries, and wastes time reviewing, testing, and debugging. It does this without actually fixing any bugs.