[vlc-devel] [vlc-commits] access: rtp: handle drops for discontinuity propagation

[Rémi Denis-Courmont]

Le keskiviikkona 6. syyskuuta 2017, 19.42.01 EEST Francois Cartegnie a écrit :
> Le 06/09/2017 à 19:15, Rémi Denis-Courmont a écrit :
> > Le keskiviikkona 6. syyskuuta 2017, 18.57.33 EEST Francois Cartegnie a 
écrit :
> >> Le 06/09/2017 à 18:08, Rémi Denis-Courmont a écrit :
> >>> Le keskiviikkona 6. syyskuuta 2017, 14.33.57 EEST Francois Cartegnie a
> > 
> > écrit :
> >>>> vlc | branch: master | Francois Cartegnie <fcvlcdev at free.fr> | Tue Sep 
> >>>> 5
> >>>> 15:15:56 2017 +0200| [079eaa8cb024fabbc38168b9ad7bb5abb4e0de7b] |
> >>>> committer: Francois Cartegnie
> >>>> 
> >>>> access: rtp: handle drops for discontinuity propagation
> >>> 
> >>> This is totally counter sensical. Discontinuity must be passed
> >>> downstream,
> >>> not upstream. Please revert.
> >> 
> >> ???? that's downstream, still notifying decoders.
> > 
> > Immediately, you´re passing the flag to the *upstream* RTP code, instead
> > of
> > the *downstream* ES output or demux, and clobbering the RTP-level state
> > all
> > the while. Passing it downstream is setting the flag to the output block.
> > 
> >> Previously the flagged discontinuity block could have been dropped.
> > 
> > That sounds like a limitation/bug of the depayloading callback. That does
> > not sound like a reason to pass the flag in the wrong direction.
> 
> I can't understand a thing.
> 
> New code is just tagging the source with discontinuity

And exactly the RTP source is the *upstream* of the payload handler. It tracks 
per-source infos, not per-payload infos. Tracking payload-level discontinuity 
there is counter-sensical. (And it will fail miserably if/when there are more 
than one payload types, or depayloading becomes asynchronous.)

> instead of tagging the block directly, and the block flag is applied on the
> current block (what was just done before), or next queued block in case that
> block is dropped.

This belongs in a flag within the payload-specific private data then. This has 
no business with the RTP source.

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/