> 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.
Yes, you can do this. “testMPEG2TransportStreamer” ->
“testMPEG2TransportRece
That is all excellent news. In the mean time I've done 2 tests.
1) ./testOnDemandRTSPServer <-> ./openRTSP -Q -F test.ts.ts.out
rtsp:// ./testRTSPClient
rtsp://:8554/mpeg2TransportStreamTest
And saw there was no '!' after the printouts of the presentation times. From
this I understand the cl
> 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 connecti
Hi Ross,
From that link:
> Outputting QOS statistics
>
> Use the "-Q" option to output QOS ("quality of service") statistics about the
> data stream (when the program exits). These statistics
> include the (minimum, average, maximum) bitrate, packet loss rate, and
> inter-packet gap.
Thanks,
> On Apr 26, 2017, at 3:14 AM, Ralf Globisch wrote:
>
> Ross, minor correction:
>
> RTSPServer::RTSPClientSession(ourClientConnection, urlPreSuffix, urlSuffix,
> fullRequestStr);
>
> should be
>
> RTSPServer::RTSPClientSession::handleCmd_SETUP(ourClientConnection,
> urlPreSuffix, urlS
Ross, minor correction:
RTSPServer::RTSPClientSession(ourClientConnection, urlPreSuffix, urlSuffix,
fullRequestStr);
should be
RTSPServer::RTSPClientSession::handleCmd_SETUP(ourClientConnection,
urlPreSuffix, urlSuffix, fullRequestStr);
Regards,
Ralf
--
This message is subject t
> we would like to
> 1) limit the number of client, do you have any suggestion about this?
> 2) if system cpu usage is very high, we want to response special custom rtsp
> header.
Here’s how you can do both of these things:
1/ Download the latest version (2017.04.26) of the code; it contains a n
