[Live-devel] Regarding QoS and RTPTransmissionStat

[Ross Finlayson]

> On Oct 20, 2026, at 7:52 AM, MANDJUKOWSKI Esteban via live-devel <live-devel at us.live555.com> wrote:
> 
>> I’m not sure what you mean by “duplicates”.  The “RTPTransmissionStats” database is indexed by SSRC, which (the “SSRC()” field in “RTPTransmissionStats”) should be different for each client.
> 
> The "SSRC()" field is indeed different for each entry, the duplicates arise from how I gather the RTPTransmissionStats.

The ‘duplicates’ (more than one “RTPTransmissionStats” with the same “SSRC()”) occur with streams where “fNumStreamStates” > 1; i.e., with streams that contain both a video track and an audio track.  In this case, the client uses more than one “RTPSource” (and thus more than one “RTCPInstance”), but these use the same SSRC (so that the client can time-synchronize the video and audio stream).

So, these “RTPTransmissionStats” aren’t really duplicates, because - even though their SSRC is the same - they are for different “RTPSink”s (video and audio).  If you want to distinguish them, then you should do so by “RTPSink”.


> So the issue here might be that I am storing the QoSRTSPClientSession instances instead of the RTPSinks in my QoSDashboard. 
> Is it possible to access active RTPSinks in order to loop over them rather than RTSPClientSession ?

You are already getting the individual “RTPSink”s when you call “getRTPSinkandRTCP()” for each subsession (video and audio).  I suggest that you distinguish the “RTPTransmissionStats” this way, rather than storing them all in a single data structure.  This is also a good idea because the QOS properties of the stream might differ depending on the subsession media type (video or audio).


> How can I tell apart which instances of RTPTransmissionStats that are in the RTPTransmissionDB are for this particular ClientSession and which are from other sessions ?

“RTPTransmissionStats” are only for RTP/RTCP (a data transmission protocol), which is a lower-level protocol than RTSP (a control protocol).  Note that you could, in principle, set up RTP/RTCP server -> client streaming using only a “RTPSink” (and “RTCPInstance”) at the server end, and a “RTPSource” (and “RTCPInstance”) at the client end, if you knew in advance the IP addresses and port numbers to use at each end.  I.e., without using RTSP at all.  But RTSP makes this easy (and gives you control over the streams).

So, there’s no way to map from a “RTPTransmissionStats” to a “RTSPClientSession”, because RTP/RTCP does not require the use of RTSP.


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