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

[Thomas Guillem]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200213/7458604a/attachment.html>