webRTC timestamp information

[Paul Poupet]

I am student in computer science and I am working on a school project that uses webRTC. I have a lot of trouble for one specific question and I would like to know if you can help me on that issue.

Webrtc uses rtp to payload data when sending video or audio. In the RTP specifications, it seems clear that a timestamp is used to reorder received packet when playing it.
Is there any way to access to this timestamp information? Isn't it the subject of this API: http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time ?
Our aim would be for the receiver of a media stream to tell the delay between him playing the stream and the time it was sent.

If you can help me or tell me where to find the information, it would be really useful. Thank you in advance,

Regards,

Paul POUPET

[Peter Boström]

What do you mean by reordering? What level are you doing this project on? Are you parsing packets or using PeerConnection within Firefox/Chromium? If you're hacking the native code, this line might be of interest: https://chromium.googlesource.com/external/webrtc/+/bd05f0ba52be050d7b438d5e191b8976506018d2/webrtc/video/receive_statistics_proxy.cc#109

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9cf9bff2-dfab-4d57-a299-16b4dbe6876c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Poupet]

Hi,
We are indeed working with peerConnection in Firefox and would like to use javascript to access time data. The end-goal is to determine precisely delay between sending and playing time, in order to synchronise multiple receivers. I couldn't find any easy way to access rtp timestamps in the api, so I wondered If you had any idea about how to do so. It seems weird not to have access to it on an higher level.
Our backup plan was to use the getstat API and use the round trip time and jitter in order to infer this delay, but I am not sure of the accuracy of that method! Besides, we would need to open a data channel for the sender to send the RTT data to the receivers.. A tad overcomplicated!
Another strange thing: there seems to be a timestamp information on the InboundRTP but documentation say it is the receiving time of the packet.

Thanks for your answer :-)

[Philipp Hancke]

In chrome, the googCaptureStartNtpTimeMs value from getStats might expose that. googCurrentDelayMs looks also interesting. Check chrome://webrtc-internals, it's part of the ssrc_12345_recv reports.

Now both still seem to be set when munging the sdp and removing the abs-send-time header extension.

--

[Peter Boström]

For verbosity: Synchronizing >1 track is tracked here: https://bugs.chromium.org/p/webrtc/issues/detail?id=4762 (though not likely to be fixed anytime soon).

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAJraKYh2_M%3DVM8sr1C4QXZaHwHZRpMwmSwSmog9Jf_ETHaSdug%40mail.gmail.com.

[Paul Poupet]

Well, i guess I wasn't really clear. My config is more like: one sender multiple receivers, one unique stream, and I want those receiver to playback the stream exactly at the same time..
My plan was to use RTP timestamp and offset the signal accordingly. Indeed googCaptureStartNtpTimeMs seems interesting.. But it really doesn't look like a timestamp (I have seen values like -1). I had a look at googCurrentDelayMs but it seems to be in addition to the network delay. I planned to use that and the jitter to calculate the compensation but the big question remains: How much time did the transport took?

[Peter Boström]

I don't remember, but I'm wondering whether elapsed time in the video tag and googCaptureStartNtpTimeMs are enough to get a NTP time per video frame, if that's the case then those could be used. I guess that that value is -1 until we have an estimate of the NTP time of the initial frame, or something like that.

On Tue, Nov 17, 2015 at 5:53 PM Paul Poupet <paul....@gmail.com> wrote:

Well, i guess I wasn't really clear. My config is more like: one sender multiple receivers, one unique stream, and I want those receiver to playback the stream exactly at the same time..
My plan was to use RTP timestamp and offset the signal accordingly. Indeed googCaptureStartNtpTimeMs seems interesting.. But it really doesn't look like a timestamp (I have seen values like -1). I had a look at googCurrentDelayMs but it seems to be in addition to the network delay. I planned to use that and the jitter to calculate the compensation but the big question remains: How much time did the transport took?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d2f603b8-5ef9-48dd-8f43-57317029378c%40googlegroups.com.

[Peter Boström]

You'll of course need your receivers' clocks to be in sync, and it sounds like you also need to synchronize playout delay across all receivers.

[Justin Uberti]

googCaptureStartNtpTimeMs + video.currentTime should give you a playout time in the receiver's clock. We get the NTP timestamp in the first SR from the sender.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sFDcv3QPUSAmHro49BrvW8etKw4ASw7wtV1LNJGVcVRKQ%40mail.gmail.com.

[Paul Poupet]

Thanks a lot for all the answers.
Well synchronisation should be achieved through ntp shouldn't it? I always thought it was a constant process but I am not sure of the precision of this process. Maybe doing some NTP request from the javascript and interpolate to compensate for drift could give me a reliable synchronisation?
Regarding the video.currentTime, this is a really great idea. We are streaming audio from a microphone and during tests I realized that the 0 of the currentime was the time the listener joined the stream. I concluded that it wasn't usable. But in addition with the googCaptureStartNtpTimeMs, it could work. The specification says it is in second though, so I am not sure of the accuracy (I am looking into hundreth of seconds precision)..

[Peter Boström]

I think video duration is a float though.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e75cb040-a97b-459d-b231-e60990140b54%40googlegroups.com.

[Justin Uberti]

yes, currentTime is a float. You'll need to do some mangling to get the units right with the NTP timestamp, but you can look at AppRTC code to see how this is done.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sGQuQ6UBnDNqwrD7aWPhfcAZqeaY4msNK3jV81yri6mpw%40mail.gmail.com.

[Paul Poupet]

It does not seem to give enough precision.

We need a perfect synchronisation so the perfect delay between the devices. Maybe we can use other tricks (inaudible frequencies or ...) does anyone have an idea ?

[Harry She]

Hi there, I found this post, and my project partner and I are trying to do pretty much the same thing. We are streaming the stereo mix of a desktop to multiple devices and want to synchronise the audio output of the devices. Does anyone have any advances or suggestions?

[Corey Cole]

It does look like all the puzzle pieces are in place to calculate end-to-end delay even if there is a TURN/relay server in the middle of the webrtc connection. @henbos has recently spec'd it out in the w3c webrtc-stats repo on github.

If there isn't a relay server in the middle, it seems that round trip time statistic should be sufficient, as long as it is accurate enough.

Did anyone find a different solution or adequate estimation for this delay to calculate synchronization of multiple devices in a broadcast configuration?