[Live-devel] [PATCH] Provide access to the full time mapping inthe last received sender report

[Colin Caughie]

Thanks for the reply. I actually made that change about a year ago; I
was aware that the code was already calculating presentation time for
the purpose of synchronization, but for some reason I thought it was
just a relative presentation time, not an absolute one that accurately
reflected the time of frame capture. Looking at the code now though I'm
not sure why I came to that conclusion as it definitely looks like it's
doing the right thing.

 

In which case please disregard my patch.

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Monday, April 01, 2013 4:52 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] [PATCH] Provide access to the full time
mapping inthe last received sender report

 

	The attached patch allows access to the last received sender
report RTP timestamp, making it possible to get the full NTP/RTP time
mapping currently in effect (since it was already possible to get the
last received NTP timestamp).

	 

	This information can be used to calculate the wallclock
timestamp of each sample in a live stream sent by an IP camera,
according to the camera's clock.

 

I think you may not realize that our software already does this
automatically!  Whenever each frame of data is received (from a
"RTPSource" subclass), then the "presentationTime" value will
automatically get set to the value calculated from RTCP's 'RTP
timestamp-to-NTP' mapping, as long as it has received at least one RTCP
"SR" packet.

 

In other words, receiving application software should never need to look
at RTP timestamps (or RTCP-reported NTP times) directly.  Instead, it
just needs to look at the "presentation time" values for each received
frame.

 

For more information see

 
http://www.live555.com/liveMedia/faq.html#separate-rtp-streams

and

 
http://www.live555.com/liveMedia/faq.html#rtcp-synchronization-issue

 

(Therefore, I won't be applying your patch, unless you can demonstrate a
clear need for it.)

 

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/20130401/de02f931/attachment.html>