[vlc-devel] [PATCH v2 5/5] libvlc: media: set WITH_ASSOCIATED_MEDIA option to preparser

[Thomas Guillem]

On Sun, Feb 9, 2020, at 12:11, Alexandre Janniaux wrote:
> Hi,
> 
> On Sat, Feb 08, 2020 at 04:35:49PM +0200, Rémi Denis-Courmont wrote:
> > Le perjantaina 7. helmikuuta 2020, 23.04.49 EET Alexandre Janniaux a écrit :
> > > When a LibVLC client associates multiple inputs to a media through the
> > > input slave mechanism, it should expect that all associated media get
> > > preparsed so that listing tracks and elementary stream ids give
> > > a comprehensive result.
> > >
> > > To achieve this, always set the WITH_ASSOCIATED_MEDIA when requesting
> > > a preparsing from the LibVLC API.
> >
> > For tracks, that's very agreeable. For meta-data, not so much: You probably
> > don't want the meta of an external subtitle file clobbering the meta of the
> > main input. It's not clear if this controls onl the first case, or both, which
> > IMO would be wrong.
> 
> Indeed, but I'm not sure whether fixing this can be part of
> this patchset and if it should be done before or after. Also
> it would work for most usual cases but would mainly break
> when associating multiple audio files together or an audio
> file with a video file and different metadata, which is my
> use case but probably not the usual one as this mechanism is
> mainly targeting video + subtitle.
> 
> It needs fixing though. It's unclear to me whether other
> metadata should be parsed but provided differently to the
> libvlc client or not parsed.
> 
> The first case is probably best fitted for a more general
> use case, but would need a different libvlc_media_get_meta
> so as to have different meta store per input, which would
> mean this should probably go into libvlc 4.
> 
> If you believe this is a blocking issue for this patchset,
> I can try providing a fix for the issue with meta.
> 
> >
> > Also, if it's always set, then I'm not exactly clear why it needs a flag.
> >
> 
> The flag is always set for libvlc client, as requested in the
> previous review, but not for libvlccore users. I'm not sure
> I can generalize to libvlccore without breaking other users
> (preparsing, medialibrary, thumbnailing, though I didn't
> check those).
> 
> As I mainly want to fix libvlc for this issue, I'd prefer
> not to include libvlccore change into this patchset,
> especially since I'm not a user of this API in libvlccore.
> If it is deemed unecessary by other clients, it could be
> removed without changing libvlc new behaviour and libvlc
> API/ABI and the resulting patches will be clearer to
> interpret.

We could also add a libvlc flag for that, cf. libvlc_media_parse_flag_t

> 
> Regards,
> --
> Alexandre Janniaux
> Videolabs
> 
> > > ---
> > >  lib/media.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/lib/media.c b/lib/media.c
> > > index f045c729d2..bd40fc388a 100644
> > > --- a/lib/media.c
> > > +++ b/lib/media.c
> > > @@ -801,6 +801,9 @@ static int media_parse(libvlc_media_t *media, bool
> > > b_async, if (parse_flag & libvlc_media_do_interact)
> > >              parse_scope |= META_REQUEST_OPTION_DO_INTERACT;
> > >
> > > +        /* Always preparse associated media when using libvlc. */
> > > +        parse_scope |= META_REQUEST_OPTION_WITH_ASSOCIATED_MEDIA;
> > > +
> > >          ret = libvlc_MetadataRequest(libvlc, item, parse_scope,
> > >                                       &input_preparser_callbacks, media,
> > >                                       timeout, media);
> >
> >
> > --
> > Реми Дёни-Курмон
> > http://www.remlab.net/
> >
> >
> >
> > _______________________________________________
> > 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:
> https://mailman.videolan.org/listinfo/vlc-devel