[Live-devel] Synchronize the "RTCP" time using RTSP Range ?

PROMONET Michel michel.promonet at thalesgroup.com
Fri Mar 22 02:26:31 PDT 2013


                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-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ralf Globisch
Envoyé : mercredi 20 mars 2013 09:17
À : finlayson at live555.com; live-devel at 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.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130322/196db0ac/attachment-0001.html>


More information about the live-devel mailing list