Rtsp over tcp: Received packet without DTS after a gap

[Sebastian Dröge]

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).

-- 
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/20150517/019187dd/attachment.sig>