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-boun...@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@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
