On Mon Sep 9 22:39:45 2024 +0000, Rémi Bernon wrote:
I don't understand this, sorry. How does changing the library we use
make this any more "frontend API specific problems"? Because being synchronous and thread-free the backend is agnostic to any use case and frontends can decide to organize their calls the way they like, letting us implement the same threading pattern as native in each frontend.
Queueing requests and consuming them isn't convoluted. That's a
ubiquitous pattern. It is definitely more convoluted than not having to do anything.
20% speed difference cannot possibly be attributable simply to glue.
Was GStreamer using avdec_h264 here? Was software decoding being used in both cases? Both are using the same FFmpeg libraries, so any overhead is due to either GStreamer or winegstreamer. GStreamer-based H264 decoder takes 4.6ms per output frame on average to decode the full "Vampire: The Masquerade - Bloodhunt" intro video to I420 (so even without any kind of color conversion), the FFmpeg-based decoder code takes 3.5ms per frame on average.
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.) With a change to drop winegstreamer entirely to the wip/winedmo branch in my tree: $ git diff origin/master..wip/winedmo --shortstat 90 files changed, 19455 insertions(+), 25703 deletions(-) There's some things left unimplemented here and there, and most importantly I didn't reimplement any kind of generic decoding parser, but it still passes most of the tests (and fixes multiple todo_wine) and 6K LoC leaves a lot of room for the missing bits.
(1) Much worse documentation. Many symbols simply aren't documented.
To the contraty to GStreamer, we don't actually need to use much of the API, and to understand much about it either, everything is completely straightforward. The headers are well documented, proof is that I've been able to rewrite pretty much everything in a couple of weeks, and didn't feel at loss at any point.
(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. GStreamer does not necessarily have a broader support, and the main reason is that it disables several of the FFmpeg-based formats because they have considered a long time ago that the gst-libav code was not good enough. They instead have re-implemented several of them differently and never reconsidered that decision. If you have some examples of formats supported by GStreamer and not by FFmpeg, I am interested to know because I'm confident that FFmpeg is more widely used in the industry.
(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. Of which I've written a large amount. I don't think it throws away anything, the code is still there in mostly the same form and the actual useful knowledge we acquired is about the Win32 side of things, this isn't lost. Tests aren't lost. Sure, this introduces potential regressions, and it throws away a lot of the testing that has been done on a different version of the code. I've been trying hard enough not to lose that before when I was still trying to use GStreamer, but that didn't seem to matter so much at the time. Then, many of the problems that the testing has found were in the frontend, and that isn't lost either. Regardless, it's not because we've put a lot of effort into something that we have to be stuck with it forever if it's not a good fit. I think that GStreamer complexity have forced to waste a huge amount of time and effort in the past reviews (say how hard I had to argue to get wg_transform, zero copy accepted), whereas if we had been using FFmpeg instead at that time, it would have been a no-brainer to implement (I did, it is absolutely plain simple and even still completely out-performing our current code).
For what it's worth, replacing GStreamer with ffmpeg is something I
have thought about for some time. The API fit is broadly better. However, those reasons are always what has led me to believe that it's simply not worth it. Then lets try it. Fwiw this is *not* replacing anything at this point or even in the near or far future, not until we decide it does, and instead it offers an alternative backend to users.
hi as user how can test your winedmo branch (which dependencies are required?, need some 32bit dependencies?), and work for 32bit apps?