Rtsp over tcp: Received packet without DTS after a gap

[Mailing List SVR]

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,

Nicola

>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150517/5304c398/attachment.html>