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

[Rémi Denis-Courmont]

I don't understand the statement.

One point is that there is nothing to do for raw UDP and DTV because nothing can be done.

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.

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.

Le 25 avril 2019 12:29:39 GMT+03:00, Francois Cartegnie <fcvlcdev at free.fr> a écrit :
>Le 25/04/2019 à 10:30, Rémi Denis-Courmont a écrit :
>> Hi,
>> 
>> 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.
>> 
>> 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.
>
>So the answer is to point the only RTP payload working with that
>abstraction/around the problem ?
>
>-- 
>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/1cea9c74/attachment.html>