
<html><head></head><body>I don't understand the statement.<br><br>One point is that there is nothing to do for raw UDP and DTV because nothing can be done.<br><br>Another point is that you can either have tight coupling between RTP accesses and TS demuxer(s) with a new ad-hoc interface, like FFmpeg. Or you can have lose coupling based on chained demux as now, which exposes stream reset but not packet loss.<br><br>You can't have the cake and eat it though. We're not going to bend over backward to fit RTP idiosyncrasies into stream_t just for the TS demuxer.<br><br><div class="gmail_quote">Le 25 avril 2019 12:29:39 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 25/04/2019 à 10:30, 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;">Hi,<br><br>The TS demuxer has to detect and handle packet loss internally anyway because raw UDP and DVB accesses _cannot_ detect it. Ditto mid-stream reset. You are getting nowhere with adding a flag that you cannot rely on.<br><br>Meanwhile, RTP-TS is already handling stream reset and already uses a semi-ad-hoc interface to the TS demuxer. You don't need to mess with stream filters and vlc_data_t if you want a fully ad-hoc interface there to handle packet loss.<br></blockquote><br>So the answer is to point the only RTP payload working with that<br>abstraction/around the problem ?<br></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>