[Live-devel] Interpreting Presentation Time

[Jesse Hemingway]

I realized that there is semi-documented support for manually getting ping
times via RTSP, by sending an empty GET_PARAMETERS command.  The round-trip
latency can be measured from the response time.  Apparently this is
problematic on certain servers, which do not respond to that command after
the PLAY command has occurred, so YMMV.

Thanks,
Jesse


On Tue, Feb 19, 2013 at 8:35 AM, Jesse Hemingway <
Jesse.Hemingway at nerdery.com> wrote:

> 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/3c4d13b7/attachment.html>