[vlc-devel] [PATCH 1/6] input_item: add WITH_ASSOCIATED_MEDIA meta request
ajanni at videolabs.io
Wed Dec 4 18:22:46 CET 2019
Thank you for your opinion,
On Wed, Dec 04, 2019 at 02:59:02PM +0100, Thomas Guillem wrote:
> I think we should preparse associated medias by default and don't let the choice to the VLC or LibVLC user.
> So it explains why external subtitles info were never displayed in diverse VLC ports.
I would be fine with this then, it changes the behaviour for
LibVLC users but I guess it's more a bugfix than a feature
change from their point of view. The documentation is not
really clear on whether they should appear or not though.
What would other people here prefer to have?
> On Wed, Dec 4, 2019, at 14:05, Alexandre Janniaux wrote:
> > Hi,
> > On Wed, Dec 04, 2019 at 01:37:54PM +0200, Rémi Denis-Courmont wrote:
> > > Hi
> > >
> > > I haven't considered what the proper behaviour would be. I just don't think it's right to delegate it to the application, as the app has less info, and the app dev likely less expertise than we do.
> > I think I understand better what is needed. A developer using
> > LibVLC and associated medias will not expect that he must use
> > a flag to have its associated media parsed.
> > I just note that it's not worse than the current situation in
> > which they will never be able to parse them at all and just
> > feel that it is a bug in LibVLC.
> > A nicer LibVLC implementation would be to have the function
> > adding associated media taking the option directly, or even
> > a mandatory parameter to tell whether it must take it into
> > account in the LibVLC reports, but it needs a lot of change
> > in the input code and LibVLC media player which I might not
> > be able to afford considering a potential rewrite of the
> > media_player, the future work on input and cachhing and the
> > current complexity of input slaves.
> > The "nicer LibVLC implementation" doesn't even solve the
> > issue you're mentioning completely and probably still poorly
> > workaround the real problem but it's hard to define it for me
> > currently.
> > Maybe the real issue is the abstraction given to LibVLC users
> > for handling associated media and preparsing, which is too
> > low level?
> > At first I would have expected something like this:
> > ```
> > libvlc_media_t *video = libvlc_media_new....();
> > libvlc_media_t *subtitle = libvlc_media_new....();
> > // create preparser, whatever we name it
> > libvlc_preparser_t *preparser = libvlc_preparser_new...();
> > // will get track info of video file
> > libvlc_preparser_req_t *parse_req = libvlc_preparser_preparse(preparser, video);
> > // create the full media
> > libvlc_media_list *media_list = libvlc_media_list_new...();
> > libvlc_media_list_add_media(media_list, video);
> > libvlc_media_list_add_media(media_list, audio);
> > libvlc_media_t *combined = libvlc_media_list_combine_and_release(media_list);
> > // Here `combined` can be created with any tools given from VLC core
> > ```
> > Actually, I was even confused by `libvlc_media_list_set_media`
> > and though it was already doing that.
> > But I'm far from knowing all LibVLC clients code and history
> > so my main point is that I feel that what you require is not
> > an issue with my patches but with the actual code instead, and
> > that my patch just extend something you already don't like.
> > I might be wrong of course, feel free to confirm or deny what
> > I described. I'm mostly trying to find a solution and would
> > not try to proclaim anything at this stade.
> > Thank you for your feedback,
> > Regards,
> > --
> > Alexandre Janniaux
> > Videolabs
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel