> Code that uses the “StreamReplicator” class is expected to be ‘well-behaved’. > I.e., it is expected that any code that uses a “StreamReplica” will continue > requesting frames from that replica - or else explicitly indicate that it no > longer wants to receive data from this replica, either by calling > “stopGettingFrames()” on the replica, or else by closing (deleting) the > replica object entirely. (In either case, this will cause the replica to be > ‘deactivated’.) In our application replicas are being used by RTPSinks, to multiply one source (from encoder) to multiple clients using class derived from OnDemandServerMediaSubsession (we need to support unicast). One time that I encountered that replica stopped requesting frames it was with H264VideoRTPSink. I didn't yet investigate further why this happened.
> Rather than including ‘timeout’ functionality in the “StreamReplicator” code > (which would make already complex code even more complex), it’d be better to > add timeouts to the higher-level application code that uses > “StreamReplicator”. I.e., in your application code - if you’re worried that > (for whatever reason) - one of the “StreamReplica”s has stopped working, then > you can add the timeout check there. (If the ‘timeout’ expires, then you can > simply delete the “StreamReplica” object.) I have considered adding FrameFilter-derived class on top of each replica to do timeouts but this has performance disadvantage because in this case instead of one there will be hundreds (how many replicas are being created in our case) extra calls to scheduleDelayedTask and unscheduleDelayedTask which are not so cheap. To summarize: If timeout checks are made independently for each of N replicas there will be 2*N scheduled tasks for each frame (1 made by RTPSink + 1 for timeout check) and N tasks will get canceled (in the normal mode of operation, when timeouts are never reached). If timeout checks are made in bulk like in proposed patch there will be N+1 scheduled tasks and 1 canceled task for each frame. -- Stas Tsymbalov TrueConf LLC http://trueconf.com/ _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
