[vlc-devel] [PATCH 00/17] RFC Split block_t into 2 different data containers

[Rémi Denis-Courmont]

Hi,

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.

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.

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.

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.

Le 25 avril 2019 13:34:09 GMT+03:00, Francois Cartegnie <fcvlcdev at free.fr> a écrit :
>Le 25/04/2019 à 10:20, Denis Charmet a écrit :
>
>> For now, without overhauling the whole stream process I don't see the
>> point to keep flags which will be discarded anyway.
>> 
>> Even with a better architecture, knowing you have a discontinuity
>> doesn't even mean you can recover. MKV could (and already does as
>best
>> as he can without it since it doesn't trust anything). MP4 not
>segmented
>> I'm afraid your index is screwed anyway. AVI (lol). Can't tell for
>ASF
>> and all the other esoteric ones.
>
>That's exactly the kind of media not sent over unreliable transport.
>
>> And to answer Thomas, adding a discontinuity packet for TS was, imho,
>> the smartest way to do that.
>
>I'm sure you don't want to dive again into H222 to recheck what TS
>discontinuity flag real purpose is and its multiple meanings depending
>on PID or location. Global discontinuity does not exists and that means
>your access does need to track every PID. Twisting its definition for
>our own use created unfixable handling of legit streams cases.
>
>Thus, this implies TS transport only.
>
>If I want to demux raw H264/UDP or any synccode based stream and drops
>keeps killing the following startcodes, loss info is useful.
>
>Pulling a mandatory contiguous byte stream from demuxer when it's not
>really contiguous data or content seems a broken concept to me.
>
>We have an architecture problem again for those cases, not mentioning
>the passive access seeks and other slave demux/dvd/bluray things.
>
>-- 
>Francois Cartegnie
>VideoLAN - VLC Developer
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190425/66dce065/attachment.html>