[Live-devel] RTSP Server Packet Loss

[Martin Sherburn]

Hello Ross,

Thanks for your speedy reply. I am aware that UDP packets are considered unreliable and can therefore be dropped, but if they get dropped it results in video corruption on the receiving side which doesn't make for a great RTSP server. I have tried your suggestion of increasing the send buffer sizes, this seems to do the trick as well. I believe 50 kb is not enough for my use case, I have a 40 Mb/s 1920x1080 H264 source video file running at 30 frames per second. So each frame is roughly 160 kB being bursted out every 33ms. My NIC is 1Gb/s so it is capable in dealing with the average bandwidth, just not capable in dealing with the bursts.

It might be nice to inform the user that packets are getting lost in this way because it took me a while to trace it back to the server. Or tie the send buffer size to the OutPacketBuffer::maxSize in some way, as it seems likely that if you need to increase that value to deal with larger frames you will also need to increase the socket send buffer size.

Regards,

Martin.

-----Original Message-----
Date: Sat, 28 Nov 2015 05:23:32 +1300
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Subject: Re: [Live-devel] RTSP Server Packet Loss
Message-ID: <7EB75DF7-2D99-43C0-927D-70A86E972314 at live555.com>
Content-Type: text/plain; charset=utf-8

No, there is no bug here (and so, there will be no change to the code).  UDP packets are not expected to be sent/received reliably; occasional packet loss can (and in general, will) occur.  This can occur for several reasons - including congestion on your network, which is the case here.

If a UDP socket write fails with a ?would block? error, then this is because you are - at least temporarily - exceeding the capacity of your network (by trying to send too much data too fast).  In this case it?s completely correct for the server to discard (i.e., not transmit) the outgoing UDP packet.  If the server were, instead, to ?block? until it became possible to transmit the packet, then this could take an arbitrary amount of time, and would also block the server from handling other events (including handling requests from and/or streaming to other concurrent clients) during that time.  (Note that LIVE555-based applications are event-based, using a single-threaded event loop for concurrency; that?s why I/O - including network I/O - is asynchronous (i.e., non-blocking).)


Note, however, that the Operating System has its own buffer for outgoing packets, and if your stream(s) happen to be especially bursty, then it it possible to increase the size of this buffer - so that it becomes less likely that transmission of outgoing packets will fail in this way.  This can be done using the ?increaseSendBufferTo()? function.  By default, this buffer size is set to at least 50 kBytes (for each socket); note the call to ?increaseSendBufferTo()? in ?liveMedia/RTPInterface.cpp?.  If you wished, you *could* increase the size of this buffer even more by making another call to ?increaseSendBufferTo()? (e.g., in your own ?createNewRTPSink()? function, in your own ?OnDemandServerMediaSubsession? subclass).  (The default size (50 kBytes) seems to be enough for most people, however.)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________