
<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>On Thu, Feb 13, 2020, at 11:37, Rémi Denis-Courmont wrote:<br></div><blockquote type="cite" id="qt"><div>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.<br></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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).<br></div><div><br></div><div>Now the big question, do we want to do the same with libvlc ?<br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>This new system is quite good since it's impossible to select a wrong track by mistake.<br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>What I propose: having 2 ways to select a track from VLC Core and LibVLC:<br></div><div> - by its string_id (used when restoring a previous player state)<br></div><div> - by its refcounted track pointer<br></div><div><br></div><div>What do you think ?<br></div><div><br></div><blockquote type="cite" id="qt"><div><br></div><div>So the aliasing problem exists.<br></div><div><br></div><div class="qt-gmail_quote"><div>Le 13 février 2020 11:11:52 GMT+02:00, Thomas Guillem <thomas@gllm.fr> a écrit :<br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:0pt;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><pre class="qt-k9mail"><div><br></div><div><br></div><div>On Wed, Feb 12, 2020, at 19:51, Rémi Denis-Courmont wrote:<br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(114, 159, 207);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div>Le keskiviikkona 12. helmikuuta 2020, 20.39.02 EET Thomas Guillem a écrit :<br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(173, 127, 168);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(138, 226, 52);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div>IMO the ES track should be referenced too, to prevent identifier aliasing<br></div><div>within a single input source with dynamic ES. i_id seems a lost cause with<br></div><div>or without the context pointer.<br></div></blockquote><div>I think we can trust a single output source to give us unique ids.<br></div></blockquote><div>And I'm 100% sure that you can't trust that. If the source gives fixed IDs, <br></div><div>nothing prevents it reusing them temporally, and it in fact will most likely <br></div><div>happens with TS.<br></div><div><br></div><div>You simply can't base your design on such a broken assumption.<br></div></blockquote><div><br></div><div>For me, if a TS output different tracks with the same ID, they are outputted at different offset and not at the same time.<br></div><div>Is my assumption correct ?<br></div><div>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.<br></div><div><br></div><div>If not, then I need to think about it.<br></div><div><br></div><div>> <br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(114, 159, 207);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div>-- <br></div><div>Rémi Denis-Courmont<br></div><div><a href="http://www.remlab.net/">http://www.remlab.net/</a><hr>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></blockquote><div><hr>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></pre></blockquote></div><div><br></div><div>-- <br></div><div>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. <br></div><div>_______________________________________________<br></div><div>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div>https://mailman.videolan.org/listinfo/vlc-devel<br></div></blockquote><div><br></div></body></html>