<html><head></head><body>Hi,<br><br>The only thing that RTP will tell you is how many RTP packets were lost (modulo 65536). Strictly speaking - since you bring H.222 - that says nothing of how many TS packets were lost though.<br><br>In particular, with multiple PT multiplexed on the RTP session (e.g journaling), you could have non-zero RTP packet loss with zero TS packet loss. In that sense, it cannot detect loss - just like raw UDP and DTV.<br><br>In general, I agree that byte stream is a poor abstraction for packet-oriented and/or lossy source. However in this specific case, I don't see what a discontinuity flag will get you.<br><br>Still, if you want to define a new packet-oriented demuxer capability that uses a yet-to-be-defined interface with its source, that's fine as far as I am concerned.<br><br><div class="gmail_quote">Le 25 avril 2019 13:34:09 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:20, Denis Charmet a écrit :<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">For now, without overhauling the whole stream process I don't see the<br>point to keep flags which will be discarded anyway.<br><br>Even with a better architecture, knowing you have a discontinuity<br>doesn't even mean you can recover. MKV could (and already does as best<br>as he can without it since it doesn't trust anything). MP4 not segmented<br>I'm afraid your index is screwed anyway. AVI (lol). Can't tell for ASF<br>and all the other esoteric ones.<br></blockquote><br>That's exactly the kind of media not sent over unreliable transport.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">And to answer Thomas, adding a discontinuity packet for TS was, imho,<br>the smartest way to do that.<br></blockquote><br>I'm sure you don't want to dive again into H222 to recheck what TS<br>discontinuity flag real purpose is and its multiple meanings depending<br>on PID or location. Global discontinuity does not exists and that means<br>your access does need to track every PID. Twisting its definition for<br>our own use created unfixable handling of legit streams cases.<br><br>Thus, this implies TS transport only.<br><br>If I want to demux raw H264/UDP or any synccode based stream and drops<br>keeps killing the following startcodes, loss info is useful.<br><br>Pulling a mandatory contiguous byte stream from demuxer when it's not<br>really contiguous data or content seems a broken concept to me.<br><br>We have an architecture problem again for those cases, not mentioning<br>the passive access seeks and other slave demux/dvd/bluray things.<br></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>