[RFC PATCH 0/5] Add MPEG video parser to MPEG splitter filter.
Akihiro Sagawa
sagawa.aki at gmail.com
Fri Jun 26 08:13:47 CDT 2020
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/kirikiri2/trunk/kirikiri2/src/core/visual/win32/krmovie/dsmovie.cpp#L1503
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.
More information about the wine-devel
mailing list