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

[Francois Cartegnie]

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