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 : [email protected]
[mailto:[email protected]] 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/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
