Rtsp over tcp: Received packet without DTS after a gap

[Sebastian Dröge]

On So, 2015-05-17 at 21:20 +0200, Mailing List SVR wrote:
> Il 17/05/2015 18:13, Sebastian Dröge ha scritto:
> > On So, 2015-05-17 at 17:51 +0200, Mailing List SVR wrote:
> >> Hi,
> >>
> >> Sebastian, based on my experience, when there is low bandwidth between
> >> client and server some rtsp server drop something in tcp mode (I think
> >> it is similar to what multifdsink do when a client is late).
> >>
> >> Please take a look at the attacched capture (rtsp over tcp), you can see
> >> several gaps in sequence number, for example 60-61 ... 63 or
> >> 65...67...70 or 79-80...85 and so on, however this stream is properly
> >> handled by gstreamer, so I don't fully understand your answer, I know
> >> that tcp is a reliable protocol but probably the sender can dedice to
> >> drop something probably based on client sending queue size,
> > That makes sense, yes. We would have to implement something to resync
> > with TCP after a gap then. The main problem here is that for TCP we only
> > measure the capture time at the very beginning once, not for following
> > packets (as TCP generally has a lot of buffering everywhere and we can't
> > assume that packets arrive in real time, like we do with UDP).
> 
> are you sure? Without looking at the code this seems not true, I have 
> several files saved from rtsp over tcp with gap properly setted,
> 
> the only difference from 1.4 and git master seems the new error about 
> packet without DTS after gap that seems to happen only sometime,

Yes, the calculations below will overflow and produce weird results if
there is a gap in TCP mode. Because in TCP mode only the very first
buffer will have a PTS/DTS, all following ones don't. And the code in
the jitterbuffer will then calculate things with GST_CLOCK_TIME_NONE.

A solution for this would be to somehow get the current capture time
again whenever there is a gap, but not sure how to best do that.

Can you file a bug about this?

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150518/e5428fa9/attachment.sig>