[Live-devel] Interpreting Presentation Time

[Jesse Hemingway]

I see - thank you.  That was a bit of a sanity check.  In our case, we need
to keep server-to-client latency low and predictable.  Our use case is
indeed like the exception you mention, with multiple receivers in the same
'room' that need to stay synced, i.e. having similar requirements as VoIP
applications.

After reading the specs, I already know that having a simple 'presentation
time' (and if I read this
post<http://web.archiveorange.com/archive/v/yWJfLHyqIEBiJenCZWNL>
correctly,
adjusted Normal Time) is a big convenience.  But since I'm sure it's far
from trivial to alter Live555 to support these new RTP/RTCP extensions, it
appears the only viable alternative would be to add another proprietary,
out-of-band connection to exchange ping information.

Another thing I'm unclear on is who is buffering this data when the client
falls behind.  Let's say the client has a small socket buffer, so it can
obviously only take in so much before discarding.  Even in this case, I
notice that the client can continue to play back at a much slower rate for
an indeterminate period of time, with similar UDP packet loss as it would
have if it was keeping up.  This attains against at least a couple
different RTSP servers in my tests.  Does a typical RTSP server buffer
large amounts of outgoing data, or is this again a matter of how it's
configured?

It looks like the RR contains the highest sequence number received, as well
as some timing info, so then it seems the server at least would know that
the client has fallen behind.  Since the server already has the info, maybe
it makes more sense to have the server automatically drop data, skip ahead
or adjust bandwidth requirements to maintain latency.  In which case, I've
been thinking about this thing backwards.

-Jesse


On Tue, Feb 19, 2013 at 1:27 AM, Ross Finlayson <finlayson at live555.com>wrote:

> Sorry if this is a stupid question, but I can't fully understand how
> Live555's Presentation Times are to be applied, *aside* from synchronizing
> parallel media streams.
>
>
> That's correct.  The presentation time indicates the time of each frame,
> relative to other frames of the same media type, and to frames of other
> media type(s) (if any).  They are used to render each frame at the
> appropriate time (again, relative to other frames of the same media type,
> and to frames of other media type(s) (if any)).
>
>
>  Is there any way to use these presentation times to determine the
> receiver's time offset from the server?
>
>
> No.  Although the presentation times are generated by the server, they are
> not 'absolute' times, because you don't know what 'absolute' clock, if any,
> the server's clock is synchronized to.
>
>
> I'm still a bit mystified about how (or whether) it's possible to relate
> presentation times as computed for afterGettingFrame() to absolute time, as
> the server understands it.
>
>
> It's not possible (without extensions to RTP/RTCP that we don't currently
> support).  But it's rarely something that you really need.  (See below.)
>
>
>  This would help calculate round-trip latency or ask the server to skip
> ahead when the client falls behind due to network or other delays.
>
>
> Do you really need to know much time the receiver/player is behind the
> sender?  You usually shouldn't - unless you have *multiple* receivers
> (e.g., in the same room) that you need to keep synchronized with each
> other.  (As I noted above, there are RTP/RTCP extensions - currently being
> standardized by the IETF - to handle this situation, but it's not something
> that I plan to support any time soon, and it's rarely something that people
> really need.)
>
>
>  I know that SR's and RR's have something to do with it
>
>
> Our *server* uses its received "RR" packets (from each receiver) to
> estimate the round-trip time to the receiver (note the function
> "RTPTransmissionStats::roundTripTime()").  However, this functionality is
> not available to receivers.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130219/710892f0/attachment.html>