> On May 19, 2015, at 8:07 AM, Stas Tsymbalov <[email protected] > <mailto:[email protected]>> wrote: > > > Right now if for some reason one replica stops requesting frames from > replicator but dows not deactivates whole delivery process stops as > replicator patiently waits for this replica to request frames.
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’.) Therefore, I won’t be including this patch. 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.) However, I have now installed a new version (2015.05.25) of the “LIVE555 Streaming Media” code that includes (slightly modified) your “StreamReplicator” patches 1-3. Please download this version, and let us know if you see any problems. (I’ll be reviewing your other proposed patches shortly.) Thanks again for your help. Ross Finlayson Live Networks, Inc. http://www.live555.com/ <http://www.live555.com/>
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
