how to get VLC to send RTCP Sender reports

[DonMcL]

Hello,

By using the following command:

vlc -vvv ts/hobbit*.mp4 --rtcp-port 0 --sout '#rtp{mux=ts,dst=DEST_IP_ADDRESS,sdp=sap,name="TestStream"}'

I've been able to use the RTP sequence numbers to obtain stats on number of video packets received, received outside a receive window, received out of Sequence, duplicates packets received, and packets lost.

I would like to use RTCP sender reports to obtain network latency statistics.
So far I have not seen any RTCP packets (Payload Type 200) packets at the receive end. (Have I just missed them?)
Can someone tell me what I need to do to get VLC to send RTCP sender reports to the receiver?
Do I need to use the --rtcp-port 0 or --sout-rtp-rtcp-mux options in some way?

Thanks,
Don

[Rémi Denis-Courmont]

VLC is sending RTCP-SR automatically. You don't need any settings for that.

With that said, RTCP is mostly useless if you mux as MPEG-TS.

[DonMcL]

Sorry for the late follow-up. I've been working on other things.

1) Please explain "With that said, RTCP is mostly useless if you mux as MPEG-TS." (I'm really just using the RTCP NTP timestamp and txTs, and RTCP txTs to gather packet level stats.)


2) I am currently using the following command to send an mp4 video: vlc -vvv long*.mp4 --sout '#rtp{mux=ts,dst=DEST.IP.ADDRESS,sdp=sap,name="TestStream"}'
On the receiving host I am receiving and playing the video with: vlc -vvv rtp://
The 2 hosts are connected via Ethernet network, and latency is very low.
This works fine.

On the receiving host I am using libpcap to capture the RTP and RTCP packets. I am using the pcap packet capture receive timestamp, minus the RTCP NTP transmit timestamp to monitor the packet latency.
I am also using the RTP rx time - the last RTCP NTP time + (RTP presentation timestamp - RTCP presentation timestamp) to calculate the RTP packet latency. This tracks the RTCP latency from above.
I am also using the RTP sequence numbers to monitor packet loss, etc.

The "problem" is the calculated latency starts low (< 1 ms), and grows continuously to > 23 ms.
I do not believe this is a problem with clock syncronisation. The two hosts have their time syncronised using NTP, and while the program was reporting latency of 13 ms, ntpdate reported the host clocks were syncronised to within 96 microseconds and (if I'm reading it correctly) the path latency is .025 ms. So I don't believe the path between the 2 hosts is congested or the host system clocks have drifted that far apart. See below.

Question) Is there anything "funny" with the ntp timestamps inserted into the RTCP headers that could be causing these latency measurements to "walk" like this?

Thanks for any insight you can provide.
Don



C:\Users\don\workspace\vlcStats\Debug> ntpdate -b -u -
d 142.92.62.164
10 Jul 15:07:20 ntpdate[9184]: ntpdate 4.2.8p10@1.3728-o Mar 23 13:48:34 (UTC+01
:00) 2017 (1)
host found : dhcp-62-164.dgim.crc.ca
10 Jul 15:07:20 ntpdate[9184]: AdjustTokenPrivileges failed: Not all privileges
or groups referenced are assigned to the caller.
10 Jul 15:07:20 ntpdate[9184]: Raised to high priority class, realtime requires
Increase Scheduling Priority privilege (enabled with secpol.msc).
Looking for host 142.92.62.164 and service ntp
142.92.62.164 reversed to dhcp-62-164.dgim.crc.ca
transmit(142.92.62.164)
receive(142.92.62.164)
transmit(142.92.62.164)
receive(142.92.62.164)
transmit(142.92.62.164)
receive(142.92.62.164)
transmit(142.92.62.164)
receive(142.92.62.164)
server 142.92.62.164, port 123
stratum 2, precision -20, leap 00, trust 000
refid [142.92.62.164], delay 0.02556, dispersion 0.00002
transmitted 4, in filter 4
reference time: dd0e4b51.b871b3e7 Mon, Jul 10 2017 14:52:01.720
originate timestamp: dd0e4eef.01765636 Mon, Jul 10 2017 15:07:27.005
transmit timestamp: dd0e4eef.016bb2d7 Mon, Jul 10 2017 15:07:27.005
filter delay: 0.02556 0.02556 0.02556 0.02556
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000096 0.000117 0.000178 0.000135
0.000000 0.000000 0.000000 0.000000
delay 0.02556, dispersion 0.00002
offset 0.000096

10 Jul 15:07:27 ntpdate[9184]: step time server 142.92.62.164 offset 0.000096 sec

[Rémi Denis-Courmont]

The only practical use of RTCP-SR is to synchronize multiple sessions. With MPEG-TS, there is only one session, and all the elementary streams are synchronized via MPEG-TS own clock. So RTCP-SR is useless.

[DonMcL]

Hi Remi,

> The only practical use of RTCP-SR is to synchronize multiple sessions. With MPEG-TS, there is only one session, and all the elementary streams are synchronized via MPEG-TS own clock. So RTCP-SR is useless.

As I said, I was not using RTCP to synchronise multiple sessions. I am using it to attempt to measure path latency.
I assumed that the NTP timestamp in the RTCP-SR was tied to the realtime clock in the sender - so it could be used for said latency measurements - but I don't think it is tied to they system realtime clock.

1) After 1 hour, NTP between the two hosts reveals that the two system clock are never more than .7 ms out of sync. Yet the NTP timestamp in the RTCP header has drifted by about 70 ms.
2) After that 1 hour, using the RTCP-SR NTP timestamp reveals the presentation clock is 90,000 Hz. (but by measuring the drift it is really closer to 90,000.7 Hz)
3) I'm guessing the NTP timestamp in the RTCP-SR is fabricated from the 90,000 Hz clock, and not from the system realtime clock.

Do you know if the guess in 3) is correct?
If you don't know, that's OK, I'll download and look into the source code.

Thanks,
Don

[DonMcL]

Typo. #2 should say 90,001.7 Hz.

[DonMcL]

Hi Remi,

It looks like I grabbed the wrong end of the stick (ok link).
It appears it is WinPcap / Win10Pcap that is using unsynchronised timestamps in their struct pcap_pkthdr. I was fooled because they put the timestamps into a struct timeval, which I wrongly assumed came from gettimeofday().

So it looks like RTCP-SR NTP timestamps will work just fine for measuring path latency (subject to the limits of NTP time synchronisation between the hosts.)

Thanks, and sorry for bothering you,
Don