[Live-devel] Access to RTPSink object on OnDemandServerMediaSubsession childs

[Ross Finlayson]

> I'm implementing statistics on our software (liveMediaStreamer framework <https://github.com/ua-i2cat/liveMediaStreamer>) and I'd like to have access to the RTPTransmissionStatsDB. But, I do not see how to get the RTPSink object (which has the RTPTransmissionStatsDB and its stats).
> 
> Which should be the proper way to get the RTPSink object related to my OnDemandServerMediaSubsession childs? I've seen that OnDemandServerMediaSubsession has a friend classe StreamState which has the RTPSink associated but, anyway, I'm not able to have access to it.

First of all, note that while a “OnDemandServerMediaSubsession” object refers to a track of streamable media, a “RTPSink” object refers to a receiving client (or possibly multiple clients if “reuseFirstSource” is True).  So there’s (in general) a one-to-many relationship between “OnDemandServerMediaSubsession” and “RTPSink”.  Thus, it doesn’t make sense to talk about *the* RTPSink object for your “OnDemandServerMediaSubsession”.

However…
There are at least two possible ways to get access to the “RTPSink” objects:

1/ Note the pure virtual function “createNewRTPSink()” that you have implemented in your “OnDemandServerMediaSubsession” subclass.  You can use your implementation of this function to get access to the “RTPTransmissionStatsDB” for the new “RTPSink”, after you’ve created it.
The drawback of this approach, though, is that you don’t know when the “RTPSink” object later gets deleted, so - if you’re not careful - you may end up holding a reference or pointer to a “RTPTransmissionStatsDB” that has been deleted.

2/ Define a subclass “myRTCPInstance” of the “RTCPInstance” class.  Then, in your "OnDemandServerMediaSubsession” subclass, reimplement the
	"createRTCP()” virtual function to create a “myRTCPInstance” object, rather than a “RTCPInstance” object.  Note that “createRTCP()” contains a “sink” parameter, pointing to a “RTPSink”, from which you can get the “RTPTransmissionStatsDB”.
The advantage of this approach over approach 1/ is that - by defining a subclass of “RTCPInstance”, you can learn when the “RTPInstance” object gets deleted, and thus when the “RTPSink” object gets deleted.  (The “RTCPInstance” object always gets deleted immediately before the “RTPSink” object.)  Thus, you can use your “myRTCPInstance” destructor to figure out when the “RTPTransmissionStatsDB” should no longer be used.

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/20150813/908c871b/attachment.html>