[vlc-devel] [RFC PATCH 8/9] RFC: es_out: fix group_id and i_id collision

[Alexandre Janniaux]

Hi,

I think it can probably be merged as-is as the API is not
constraining the underlying id-providing method. Maybe you
could just add a scheme identifier to be able to migrate the
id from one version to another without loosing the user saved
preferences ?

Regards,
--
Alexandre Janniaux
Videolabs


On Thu, Feb 13, 2020 at 12:03:37PM +0100, Thomas Guillem wrote:
>
> On Thu, Feb 13, 2020, at 11:37, Rémi Denis-Courmont wrote:
> > It's not a problem if you have a synchronous track selection API. But most likely you don't. Currently we only have an asynchronous one, and I can't see a practical way around that.
>
> For VLC Core, we use a refcounted vlc_es_id_t that is just an opaque structure owned by the legacy es_out_id_t.
>
> So, VLC interfaces and control modules are able (and are cuttently doing it) to select a track without any possible error (they are not using the int i_id all).
>
> Now the big question, do we want to do the same with libvlc ?
> If we do that, libvlc will return some libvlc_track that will hold a reference to the vlc_es_id_t, that will prevent the es_out_id_t deletion, but *not* the the track removal by the demux.
>
> If a removed track is selected, the es_out will do nothing. It will happen when the track is selected and removed just after by the demux.
>
> This new system is quite good since it's impossible to select a wrong track by mistake.
> But I still want to be able to select a track by its string_id. Mainly to restore the player previous state from a db.
>
> What I designed won't be perfect, but will cover 99% of use case (without error). I don't really see how I can improve it without making this id more complicated.
>
> What I propose: having 2 ways to select a track from VLC Core and LibVLC:
>  - by its string_id (used when restoring a previous player state)
>  - by its refcounted track pointer
>
> What do you think ?
>
> >
> > So the aliasing problem exists.
> >
> > Le 13 février 2020 11:11:52 GMT+02:00, Thomas Guillem <thomas at gllm.fr> a écrit :
> >>
> >>
> >> On Wed, Feb 12, 2020, at 19:51, Rémi Denis-Courmont wrote:
> >>> Le keskiviikkona 12. helmikuuta 2020, 20.39.02 EET Thomas Guillem a écrit :
> >>>>> IMO the ES track should be referenced too, to prevent identifier aliasing
> >>>>> within a single input source with dynamic ES. i_id seems a lost cause with
> >>>>> or without the context pointer.
> >>>> I think we can trust a single output source to give us unique ids.
> >>> And I'm 100% sure that you can't trust that. If the source gives fixed IDs,
> >>> nothing prevents it reusing them temporally, and it in fact will most likely
> >>> happens with TS.
> >>>
> >>> You simply can't base your design on such a broken assumption.
> >>
> >> For me, if a TS output different tracks with the same ID, they are outputted at different offset and not at the same time.
> >> Is my assumption correct ?
> >> If it's correct, I don't see any problem having the same identifier for 2 different tracks having the same id at different offset of the file.
> >>
> >> If not, then I need to think about it.
> >>
> >> >
> >>> --
> >>> Rémi Denis-Courmont
> >>> 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
> >
> > --
> > Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
> > _______________________________________________
> > 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