On Thu Apr 4 16:16:18 2024 +0000, Elizabeth Figura wrote:
(2/5 is just adding a test, I'll assume you mean 1/5.)
Yes, sorry.
Yeah, I'm not sure about that part either. I'm not sure about any of
this, other than what BURIKO needs, and I have no idea about _why_ any of that.
As mentioned in bugzilla, using the MPEG splitter and decoders may
have a performance impact, even in applications that don't care about compressed MPEG; that's why I chose this approach. And, as you said, changing filter priorities yields a regression risk.
But if you feel that the improved do-it-right-ness outweighs said
drawbacks, then so be it. Please confirm which way you want it. Yes, it makes performance worse and debugging harder, but at this point the ship has sailed; that's a problem we just need to deal with. That was one of the motivations for delaying doing the work to implement compressed output support, but now we've reached the point where we need it. I think the tradeoffs at this point are such that always using the real MPEG-1 splitter and AVI splitter is the right option.
Sure, done. Except that autoplug-continue thing you mentioned; the avisplit tests still pass, so I think it already supports everything it should. If not, the CI will remind me.
I also did the same change to wavparse, then deleted the now-single-member wg_parser_type enum - if every caller passes the same value, it's just a waste of space. (I can drop those commits if you don't like them, I don't think they yield any functional changes. They're just cleanups.)
Maybe it's possible to add GstAllocator support and tell GStreamer to write directly into IMediaSample; that'd reduce the copies to just a few thread sync ops. But that's out of scope for this MR.
And if not (and until then), computers have gotten faster in the 13 years since decodebin_parser was created (a2916f3a0bfe7e4d2157c5a7413358391d00ba71 - though the name is newer), the overhead is probably less noticable than it would've been back then.