> On Mar 13, 2024, at 5:44 AM, Andy Hawkins <andy.hawk...@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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
