0

I am sending a video stream from the browser to gstreamer using webrtc. I can get the RTP time of the packets and NTP time from RTCP SR packets in gstreamer. At receiver At receiver I want to calculate the time elapsed since that packet was created at the sender.

i am currently calculating delay as

delay = sent time of packet - receive time of the packet

(all clients do not have same NTP time)

time difference =( NTP of receiver - Ntp of sender )

i am converting RTP time of every RTP packet to NTP values

90000 is the clock rate

send time of packet =(RTP time in RTP packet) - RTP Time in RTCP packet) )/90000 ) * 1000000000 + NTP in RTCP (converting value to ns)

delay = ( receiver NTP in ns - time differences ) - sent time of packet in ns (in NTP values)

the delay shows around 12046392 nano sec in local network i don't think its correct am i doing something wrong in the calculation.

Usama
  • 159
  • 1
  • 13

1 Answers1

3

RTCP SR can help mapping RTP (relative based on sample clock) timestamps to NTP (global absolute - wall clock) timestamps.

Unsure what exactly is meant by "At sender ... calculate the time elapsed since that packet was created at the sender."

If you are interested in calculating the time difference in seconds between two of those RTP timestamps you need to know the media/sample clock rate generating them. You can derive this clock rate by correlating with RTCP SR NTP timestamps but you need at least two of them.

If you want to know how much time elapsed since sender created the RTCP SR just calculate the difference between current time and the received NTP timestamp. The RTCP SR NTP timestamp is literally the current time when the packet was created.

The RTP timestamp attached to the NTP one inside RTCP SR packet is the interpolated current media/sample clock time. By this relation one can compute the absolute wall time for every RTP timestamp but not without knowing at least the media clock rate (e.b. by deriving it from to RTCP SR packets or by reading it from some media header as the player obviously needs to know media clock rates for correct playback speed).

TL;DR: Can't compute because crucial info is missing.

Edit: Your calculcations look good to me. I assume one packet of RTP data contains multiple media samples. The RTP timestamp references the time for the first byte of the first sample in a packet. So the time when a packet left the sender should be close to RTP_to_NTP_timestamp_in_seconds + ( number_of_samples_in_packet / clock ). I guess the media data in one packet could add up to multiple milliseconds. Maybe number_of_samples_in_packet / clock is about 12 milliseconds? I guess the time between two RTP packets is then also close to 12 ms.

Edit2: From RFC4587: If a video image occupies more than one packet, the timestamp SHALL be the same on all of those packets. Which could also affect your calculation. But should be minor, I guess.

thomas
  • 175
  • 1
  • 9