[Live-devel] rtp over rtsp, tcp sending: dropped frames

[Gajdosik Johannes]

On Tue, 9 Aug 2016 12:47:49 -0700
Ross Finlayson <finlayson at live555.com> wrote:

Thanks for your answer!

> > In my opinion this behaviour is inappropriate, since I use TCP streaming exactly because I never must drop a frame.  
> 
> This is unrealistic, and impossible if your network stream is exceeding the capacity of your network - which is what’s happening in your case.

My network is good enough (gigabit lan). Just the serverside tcp send buffer is too small (50kB) for big I-Frames, which can easily be bigger than 300kB. Also I prefer a dropped connection to a lost frame. A clean solution could be to keep all the data that cannot be sent right away (EAGAIN) in a buffer for later sending instead of silently dropping the frame.


> 
> You are streaming datagrams, which means that - even if you’re encapsulating them within a TCP connection - you have to be prepared for the possibility of some of these datagrams being lost.  It’s important to understand the difference between transmitting a stream - which occurs at a fixed data rate, regardless of what kind of network you happen to have underneath you - and downloading a file (i.e, the World-Wide Web), which occurs over TCP connections whose speed automatically matches the speed of the underlying network.  We’re doing the former; not the latter.
> 
> I won’t be changing the existing code in this case.  Please also read these earlier responses to other people who have asked the same thing:
> 	http://lists.live555.com/pipermail/live-devel/2014-September/018693.html
> 	http://lists.live555.com/pipermail/live-devel/2015-July/019523.html

I understand that you will not change your code. Nevertheless I hope that my post will be useful to some other people who experience the same problem of lost frames on the serverside and want to change this behaviour.


> > I also find that increasing the TCP sendbuffer from 50kB to 1MB in GenericMediaServer.cpp is helpful in this cause.  
> 
> FYI, this is something that you can do yourself, in your own code - e.g., in your implementation of the “createNewRTPSink()” virtual function.

Thanks, I will try that!

> 
> Also:
> 
> > especially when I send big I-Frames.  
> 
> It’s best not to try and transmit very large I-frames.  Instead, they are best broken up into multiple ‘slice’ NAL units.  

I do not create the large I-frames by myself, but I just get them from IP-Cameras and store/retransmit them without reencoding.

Yours,
Johannes Gajdosik