[vlc-devel] [RFC PATCH 8/9] RFC: es_out: fix group_id and i_id collision
thomas at gllm.fr
Thu Feb 13 12:03:37 CET 2020
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:
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
> 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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel