[Live-devel] Synchronize the "RTCP" time using RTSP Range ?
PROMONET Michel
michel.promonet at thalesgroup.com
Tue Mar 19 08:42:05 PDT 2013
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-bounces at ns.live555.com [mailto:live-devel-bounces at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130319/063f3156/attachment.html>
More information about the live-devel
mailing list