Synchronize the "RTCP" time using RTSP Range ?

[PROMONET Michel]

Hi Ross,

I was still thinking on my issue to send presentation time from an RTSP server to an RTSP client.

I wondering if it could be a way that RTSP server answer to PLAY with an absolute Range (like Range: clock=xxxxTxxxxxZ-) and use this information and the rtpTime from the RTP-Info to initialize conversion between RTP time and NTP time.

Do you think it's an acceptable way ?

Best Regards,

Michel.

[@@ THALES GROUP INTERNAL @@]

[Ross Finlayson]

I'm not sure specifically what you're asking, but as I've said (many times) before, the presentation times that are delivered at the receiver end *will* be synchronized, when (and only when) the first RTCP "SR" is received.

The "RTP-Info" information is different - it helps the receiver get the 'normal play time' (think: the time that would be shown on a VCR display) after the "PLAY".

The client code is working just fine. There is nothing to 'fix'.

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

[PROMONET Michel]

This post might be inappropriate. Click to display it.

[Ross Finlayson]

What I was suggesting is this “missing” NTP information (before RTCP “SR”) could perhaps be computed from RTSP PLAY answer.
It is quite annoying to drop data waiting for RTCP “SR” because we cannot send the timestamp through RTSP/RTP/RTCP mechanism.

What I can probably do is upgrade our server code so that it sends a RTCP "SR" packet immediately upon handling a "PLAY" command (before the first RTP packet is sent). (I think this is actually prescribed in one of the IETF RFCs.) That won't be 100% reliable (because this first RTCP packet may get lost, but most of the time it will eliminate the delay before RTCP synchronization occurs.

Yes, it would be nice if the "RTP-Info:" data included a NTP-format time (the same as in RTCP "SR"s), but unfortunately that's not in the standard.


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

[Jeff Shanab]

I record video from a security camera. I do not want to throw away up to the first 2 seconds so I measure the offset and adjust my timestamps to the timebase of the machine. When I get the sync notification I adjust the adjustment. This adjustment is continually applied to all timestamps.

It is not the ntp time of the server, but it is an exact offset from the beginning of the hour of a ntp syned machine, we split our video on the hour boundry.
We let the camera independently sync to a ntp server and it all stays very close.






This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone.

From: live-devel-***@ns.live555.com [mailto:live-devel-***@ns.live555.com] On Behalf Of Ross Finlayson
Sent: Monday, March 18, 2013 3:57 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Synchronize the "RTCP" time using RTSP Range ?

What I was suggesting is this "missing" NTP information (before RTCP "SR") could perhaps be computed from RTSP PLAY answer.
It is quite annoying to drop data waiting for RTCP "SR" because we cannot send the timestamp through RTSP/RTP/RTCP mechanism.

What I can probably do is upgrade our server code so that it sends a RTCP "SR" packet immediately upon handling a "PLAY" command (before the first RTP packet is sent). (I think this is actually prescribed in one of the IETF RFCs.) That won't be 100% reliable (because this first RTCP packet may get lost, but most of the time it will eliminate the delay before RTCP synchronization occurs.

Yes, it would be nice if the "RTP-Info:" data included a NTP-format time (the same as in RTCP "SR"s), but unfortunately that's not in the standard.

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

[PROMONET Michel]

Hi Ross,

Thanks for your support and your patience.

But as you said reducing SR period just reduce the risk.

Perhaps a trade-off between the standard and what could do a live555 user could be to give a way to RTSPClient user to give the fSyncTime initialization.
Through a non standard way to acquire the time reference (perhaps additional RTSP ), I guess it will then be possible through MediaSubSession -> RTPSource -> RTPReceptionStats to set the initial value.

Do you think this could be an acceptable way ?

Best Regards,

Michel.

[@@ THALES GROUP INTERNAL @@]

De : live-devel-***@ns.live555.com [mailto:live-devel-***@ns.live555.com] De la part de Ross Finlayson
Envoyé : lundi 18 mars 2013 21:57
À : LIVE555 Streaming Media - development & use
Objet : Re: [Live-devel] Synchronize the "RTCP" time using RTSP Range ?

What I was suggesting is this "missing" NTP information (before RTCP "SR") could perhaps be computed from RTSP PLAY answer.
It is quite annoying to drop data waiting for RTCP "SR" because we cannot send the timestamp through RTSP/RTP/RTCP mechanism.

What I can probably do is upgrade our server code so that it sends a RTCP "SR" packet immediately upon handling a "PLAY" command (before the first RTP packet is sent). (I think this is actually prescribed in one of the IETF RFCs.) That won't be 100% reliable (because this first RTCP packet may get lost, but most of the time it will eliminate the delay before RTCP synchronization occurs.

Yes, it would be nice if the "RTP-Info:" data included a NTP-format time (the same as in RTCP "SR"s), but unfortunately that's not in the standard.

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

[Ross Finlayson]

As I said before (and am, I hope, saying for the last time), I'm not going to be doing anything non-standard here.

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

[Ralf Globisch]

Michel, I think the probability of loosing the first SR is very minor, SR
packets are relatively small in comparison to the video packets and are
less likely to get dropped by routers. Or do you have any indication
otherwise? Ross's fix should do the trick.

However if you want to decrease that probability further RFC6051(
http://tools.ietf.org/html/rfc6051 ) might be of use.
I'm not sure if it applies here, but from what I recall it's basically an
extension header for RTP that includes an NTP timestamp allowing one to do
as the name says: rapid synchronisation. You could add this extension
header to the first e.g. 5 RTP packets *if* you notice a problem with the
first SR being lost. To be sure read the draft to make sure it applies to
this use case.

Post by Ross Finlayson
As I said before (and am, I hope, saying for the last time), I'm not

going to be doing anything non-standard here.
@Ross I would say this is a standard-conformant way? Standard conformant
RTP applications *should* ignore the header in any case if the don't
understand it, so it shouldn't break other clients...

@Michel If you do write the extension header and rapid sync code, you could
consider contributing it back to the live555 codebase.

Regards,
Ralf

[PROMONET Michel]

Hi Ralf, Ross,

Thanks for the link to the RCF6501 that bring a solution to know the timestamp of the first RTP packet.
I follow times to times the ONVIF specification http://www.onvif.org/specs/stream/ONVIF-Streaming-Spec-v210.pdf that also propose to insert a NTP timestamp (and other things to allow streaming backward) in the RTP header extension but using a different profile.

In previous mail Ross told me that supporting RTP header extension in live555 is not in the roadmap.
I will continue to try to find a way.

Thanks,

Michel.

[@@ THALES GROUP INTERNAL @@]

De : live-devel-***@ns.live555.com [mailto:live-devel-***@ns.live555.com] De la part de Ralf Globisch
Envoyé : mercredi 20 mars 2013 09:17
À : ***@live555.com; live-***@ns.live555.com
Objet : Re: [Live-devel] Synchronize the "RTCP" time using RTSP Range ?

Michel, I think the probability of loosing the first SR is very minor, SR packets are relatively small in comparison to the video packets and are less likely to get dropped by routers. Or do you have any indication otherwise? Ross's fix should do the trick.

However if you want to decrease that probability further RFC6051( http://tools.ietf.org/html/rfc6051 ) might be of use.
I'm not sure if it applies here, but from what I recall it's basically an extension header for RTP that includes an NTP timestamp allowing one to do as the name says: rapid synchronisation. You could add this extension header to the first e.g. 5 RTP packets *if* you notice a problem with the first SR being lost. To be sure read the draft to make sure it applies to this use case.

Post by Ross Finlayson
As I said before (and am, I hope, saying for the last time), I'm not going to be doing anything non-standard here.

@Ross I would say this is a standard-conformant way? Standard conformant RTP applications *should* ignore the header in any case if the don't understand it, so it shouldn't break other clients...

@Michel If you do write the extension header and rapid sync code, you could consider contributing it back to the live555 codebase.

Regards,
Ralf