On Mon, 22 Jun 2020 11:22:48 -0500, Zebediah Figura wrote:
On 6/21/20 1:40 AM, Akihiro Sagawa wrote:
I'll work on MPEG video decoder filter, next. Because, at this point, we can't build a pipeline for MPEG video files with the MPEG splitter. After finishing up the decoder, I'll submit both of patchset. Supporting system stream (audio+video) will be the subsequent development.
So, I'm guessing that the application that wants this builds the entire graph themselves? Or do they insert mpegvideoparse and autoplug the rest? If the latter, I kind of wonder if we could wire it up to decodebin instead...
I greatly appreciate your review and apologize for late response. My main target application is KiriKiri2[1] based visual novel. It creates MPEG splitter/vide/audio filters and connects respectively. KiriKiri2 is released under GPL2, so we can read its source code on GitHub for details[2].
[1] https://en.wikipedia.org/wiki/List_of_visual_novel_engines#KiriKiri [2] https://github.com/krkrz/krkr2/blob/dec49af97e174d31059c3ccd7efc700ba3c6b788...
I'll improve my patchset and submit it with the video filter's patchset when ready.
I think patch 1/5 makes sense, though the title is a little awkward. It might be a good idea to split it (it is already a little large), with one patch as something like "quartz/tests: Pass a file name to some MPEG splitter test functions" and one patch as something like "quartz/tests: Separate audio-specific MPEG splitter tests into their own functions."
The rest of the patches look fine at a cursory glance, though see also my question above. I do wonder
I'm not sure it's worth going out of your way to make test_enum_media_types() work with both sinks. The point is just to show that IEnumMediaTypes functions have a certain behaviour across most or all filters.
As always it'd be nice to put tests before fixes (so 5/5 before 4/5, I guess), but if that gets too awkward it'd not a big deal.