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 <finlay...@live555.com>
To: LIVE555 Streaming Media - development & use
<live-de...@ns.live555.com>
Subject: Re: [Live-devel] RTSP Server Packet Loss
Message-ID: <7eb75df7-2d99-43c0-927d-70a86e972...@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
______________________________________________________________________
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
