[Live-devel] live555 question

[McLachlan, Donald (IC)]

That is all excellent news.  In the mean time I've done 2 tests.

1) ./testOnDemandRTSPServer <-> ./openRTSP -Q -F test.ts.ts.out rtsp://<IPADDRESS:8554/mpeg2TransportStreamTest

And I saw the QoS stats.

2) ./testMPEG2TransportStreamer <-> ./testRTSPClient rtsp://<IPADDRESS>:8554/mpeg2TransportStreamTest

And saw there was no '!' after the printouts of the presentation times.  From this I understand the client/server are RTCP-synchronized.


I've been told that currently the plan is for "core" -> "UE" data path only.
Server and client will be able to synchronise via NTP  via the control channel.
But there will be no reverse channel at all, so RTSP connection will not happen.
It is not clear to me whether one achieve something similar using the TestMPEG2TransportStreamer -> TestMPEG2TransportReceiver.
?


-----Original Message-----
From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: April-26-17 1:46 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] live555 question

> Given that the data flow is across a one-way link (and there is no return path) the sender will not receive Receiver Reports from the receiver.  Off the top of your head, do you know whether this will cause any problems?

No.  (Of course, you’ll need a TCP back channel for the RTSP connection - but once RTP/RTCP packets start flowing from the sender, it doesn’t matter if the sender doesn’t receive RTCP Reception Report (“RR”) packets back from the receiver(s).)

Once a stream has been RTCP-synchronized, then a receiver can compute the end-to-end latency *only if* its clock is synchronized with that of the sender (e.g., using NTP), and then this is trivial to do: Just look at the presentation time of each received media frame, and compare this to the (receiver’s) current ‘wall clock’ time (by calling “gettimeofday()”).

(The *sender* can compute the end-to-end latency to each receiver even without synchronized clocks, but *only if* it receives RTCP “RR” packets back from the receiver.  This is described in RFC 3550.)

Applications that use our library do not need to look at (or care about) ‘RTP timestamps’.  Our software automatically converts these to/from ‘presentation times’, which is all that you should need to care about.


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