[Live-devel] Retrieving buffers of data from an RTSP derived stream

[Ross Finlayson]

> On Mar 13, 2024, at 5:44 AM, Andy Hawkins <Andy.Hawkins at uniguest.com> wrote:
> 
> 'Proprietary' was perhaps the wrong choice of word. The link between the two is SRT, which is an open standard.

OK, I’m somewhat aware of SRT, because I was at the IETF MOPS working group meeting - described at the end of the “History” section here
	https://en.wikipedia.org/wiki/Secure_Reliable_Transport#History
where it was presented.


> I'm not sure that using RTP / RTSP for the link between sites would necessarily work for us. We're often faced with unreliable network links, and the SRT protocol does a good job of handling lost / out of order data.

An alternative might be to stream RTP (and RTCP) packets over a TCP connection - i.e., the TCP connection that’s already being used for RTSP (the ‘control’ protocol).  This is something that the "LIVE555 Proxy Server” already supports (using the “-t” command-line option); see "Back-end streaming over TCP” here:
	http://live555.com/proxyServer/
This will give you reliable (and in-order) delivery; one possible drawback being that ‘late’ media data (i.e., too late to be useful) will not get dropped, which may give you higher latency than SRT if your network is very lossy.  But if your media source is RTSP/RTP, and you want to send the media (eventually) to RTSP/RTP clients, then it seems like a lot of complexity to translate to-and-from an intermediate protocol (SRT) in-between.

But if you intend to stick with using SRT, and the media data that you plan to transmit over SRT is just a MPEG Transport Stream (rather than individual audio and video media ‘packets’), then the fact that you’re using SRT as your intermediate transport is irrelevant, as far as LIVE555 is concerned.  At each end of the SRT link, LIVE555 would see just a MPEG Transport Stream.  At the ‘right-hand’ end of the chain, your RTSP server could simply take - as input - a MPEG Transport Stream, and stream that to (RTSP/RTP) clients, without demultiplexing the Transport Stream at all.  See, for example, how our “testOnDemandRTSPServer” demo application implements the “mpeg2TransportStreamTest” stream, and see http://live555.com/liveMedia/faq.html#liveInput-unicast .  (Alternatively you could demultiplex the Transport Stream - using our “MPEG2TransportStreamDemux” class - into individual audio and video streams before re-streaming them from your RTSP server, but that adds a lot of complexity.)  At the ‘left-hand’ end of the chain, when you receive data from your ‘back end’ RTSP/RTP servers, if the data is already a MPEG Transport Stream, then this is trivial.  But if not (the RTP data consists of separate audio and video streams), then you would need to buffer and time-synchronize the audio/video streams, and then multiplex them (using our “MPEG2TransportStreamMultiplexor”) into a MPEG Transport Stream - again, adding a lot of complexity.  Again, in this case, it would be a lot simpler to try to use RTSP/RTP all the way.

This is probably as much help as I can give you now ‘for free’ on this mailing list.  (But I am open to possible helping your company as a consultant on your project, should you be interested.)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/