[Live-devel] [PATCH 4/4] StreamReplicator: add frame delivery timeout

[Ross Finlayson]

>> If all of your clients are unicast RTSP clients, all using just one “OnDemandServerMediaSubsession” subclass, then you shouldn’t need to use “StreamReplicator” at all.  Instead, just ensure that your “OnDemandServerMediaSubsession” subclass’s constructor sets the “reuseFirstSource” parameter to True when it calls the parent (“OnDemandServerMediaSubsession”) constructor.  Setting the “reuseFirstSource” parameter to True will ensure that only one instance of your encoder source (your “FramedSource” subclass) is in existence at any time.  (You must still allow for your “FramedSource” subclass to be closed, then later re-opened; however, no more than one object of this class will be in existence at any given time.)
>> 
>> In this case the ‘replication’ (transmitting packets to the multiple unicast clients) will happen automatically at a lower level, inside the “Groupsock” object.
> 
> I have already tried this, and it worked terribly. With StreamReplicator and reuseFirstSource==False I have managed to send VP8 video to about 400 clients for 500-900 Mbit/s total bandwidth. With reuseFirstSource==True after 20 connected  clients send errors have started to appear, and after about 40 clients video on clients became unwatchable due to packet loss. My guess this happened because with reuseFirstSource==True OnDemandServerMediaSubsession uses just one socket to send to all clients and hence all data goes through one OS socket send buffer which is simply not big enough to handle that much data. This happens on Windows by the way (send error is WSAEWOULDBLOCK), maybe on normal operating systems this will work fine

Yes :-)

However, if Windows lets you increase the size of its OS socket send buffer (using the standard POSIX "setsockopt(socket, SOL_SOCKET, SO_SNDBU, ...)” call), then you could try calling our “increaseSendBufferTo()” function, which does this.  (By default, our code sets output socket buffers to 50 kBytes.)

If you can do this (and set “reuseFirstSource” to True), then that should be a lot more efficient than using multiple “StreamReplica”s with “reuseFirstSource” set to False.  In the latter case, you have the extra overhead of copying to the replicas, plus the fact that you’ll have multiple sockets for RTP and RTCP (one of each for each client), which you don’t have if you set “reuseFirstSource” to True.  (You’d be more likely to run into the OS's limit on the number of open sockets.)


> Anyway, sorry for wasting your time with specifics of my use-case. I just wanted explain why I think that including timeouts in StreamReplicator and not somewhere else is better.

Or you could just fix whatever it is in your application that can cause your replicas to hang :-)  If your replicas are all feeding into “RTPSink”s, then the only thing (that I know of) that could cause a write to a “RTPSink” to ‘hang’ would be if it got fed an excessively large “fDurationInMicroseconds” value when it was delivered a frame (or H.264 NAL unit).  Perhaps your patches to the “H264VideoStreamFramer” code (which I’m still reviewing) fixed this problem for you (or maybe even caused it?).  In any case, it should be easy to check for and fix if necessary.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150525/3304047a/attachment.html>