On Tue, 9 Aug 2016 12:47:49 -0700 Ross Finlayson <finlay...@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 _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
