[Live-devel] Regarding QoS and RTPTransmissionStat

MANDJUKOWSKI Esteban Esteban.Mandjukowski at telecomnancy.eu
Wed Oct 21 02:14:02 PDT 2026


> > 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”.

I see, thanks for the explanation. I thought the SSRC's goal was to be
a unique ID.

> “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.

That is a little disappointing : my objective was to be able to gather
a list of active streams of every client (represented by IP + port I
guess) and be able to display the QOS statistics :

+----------------------------------------------------------------------
--------------------------------------------------------------+
| Client IP          | Protocol   | Stream         | Codec    | Packets
sent    | Bytes sent      | Loss %    | Jitter (ms)  | RTT(ms)   |
+----------------------------------------------------------------------
--------------------------------------------------------------+

I am very surprised no one came up with such important (from my point
of view, of course) network diagnosis feature. 

Can you confirm that, for clients using TCP to connect to a stream, it
is not possible to obtain the IP address they are using ? 

Best regards,
MANDJUKOWSKI Esteban






More information about the live-devel mailing list