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.<div>
<br></div><div>Thanks,</div><div>Jesse<br><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 8:35 AM, Jesse Hemingway <span dir="ltr"><<a href="mailto:Jesse.Hemingway@nerdery.com" target="_blank">Jesse.Hemingway@nerdery.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <div>
<br></div><div>After reading the specs, I already know that having a simple 'presentation time' (and if I read <a href="http://web.archiveorange.com/archive/v/yWJfLHyqIEBiJenCZWNL" target="_blank">this post</a> 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.<div>
<br></div><div>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? </div>
<div><br></div><div>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.<br>
<div><br></div><div>-Jesse<br><div><br></div><div><br><div class="gmail_quote"><div><div class="h5">On Tue, Feb 19, 2013 at 1:27 AM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word"><div><div><blockquote type="cite">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.</blockquote>
<div><br></div></div>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)).</div>
<div><br></div><div><div><br><blockquote type="cite"> Is there any way to use these presentation times to determine the receiver's time offset from the server?</blockquote><div><br></div></div>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.</div>
<div><br></div><div><div><br><blockquote type="cite">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.</blockquote>
<div><br></div></div>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.)</div><div><br></div><div><div>
<br><blockquote type="cite"> 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.</blockquote><div><br></div></div>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.)</div>
<div><br></div><div><div><br><blockquote type="cite"> I know that SR's and RR's have something to do with it</blockquote><div><br></div></div>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.</div>
<span><font color="#888888"><br><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px">Ross Finlayson<br>
Live Networks, Inc.<br><a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a></span></span>
</div>
<br></font></span></div><br></div></div>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br><br></div></div></div></div>
</blockquote></div><br><br></div>