
<html><head></head><body>I said to keep the ID as meta in the format, so iwe can still match TS ES. But stop using it as track identifier in LibVLC and input interfaces...<br>

<br>

If ES is a reference counted object, the pointer itself is intrinsically guaranteed to be temporally unique - even in the racy cases of ES deletion or addition and even across demux slaves.<br><br><div class="gmail_quote">Le 17 août 2018 15:58:02 GMT+03:00, Francois Cartegnie <fcvlcdev@free.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Le 17/08/2018 à 14:19, Rémi Denis-Courmont a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> No it doesn't unless that problem is already there.<br> <br> You can still remux based on FMT ID. Obviously it won't work if two tracks have same ID, but it does not work with the current system either.<br></blockquote><br>The issue is collision with slaves and that's exactly the same with<br>group id, which is TS program. (and in a similar way the main program<br>creation hijacking)<br><br>That's still the point of reworking es out and namespace/identify es per<br>input. There's no reason not to remove the program/es id information,<br>unless you want to drop support for mpeg TS and sout.<br></pre></blockquote></div><br>

-- <br>

Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>