SRT has recently augmented its firewall traversal techniques by supporting multiple streams with a single UDP port, otherwise known as multiplexing. This simplifies the challenges of firewall traversal for complex streaming workflows and is particularly useful in broadcast applications such as the remote production (REMI) of multiple live feeds.
Haivision SRT Gateway now features Stream ID, which allows users to send multiple SRT streams from different sources through a single UDP port and read the Stream IDs to decide how to route them from there. A major benefit to this is that it facilitates firewall traversal by only opening up one port and has only one listening socket on a server, rather than having to open a UDP socket for each stream that’s coming in. An IT department can dedicate a single port that can be used for any number of simultaneous SRT streams, preventing the need for broadcast engineers and video producers to request additional ports depending on the event covered.
We are interested in this feature for reasons similar to the ones described by Haivision above. We use SRT as ingestion protocol from multiple clients (many) and we want our interaction with the different IT departments to be as smooth as possible. If we could tell them a specific port to open in their firewall instead of telling them to open all UDP ports, that would be nice. It would also be nice to be able to provide the ingestion URI to our users well in advance their actual broadcast.
So what I am wondering is what the correct GStreamer abstraction or implementation of this would be? Where we could have a single UDP socket but multiple SRT (mpeg-ts) streams out from the element / bin.
We would like to be notified when a new SRT connection is made on the UDP socket and act on it and relay the stream to the correct processing point.
Does anyone have an idea of how an multiplexing SRT element / bin could look like in GStreamer?
My preferred option is to have multiple instances of the srtsink element, each with one pad, and then have a way for them to share the same connection. We can either have a global hash table of connections, and have a string property, if two elements have the same value set in that property, then they will use the same underlying SRT connection. We can also have an property that exposes the a “socket” object that can be read and then set on the other element, but that’s not going to work with gst-launch, so it’s a less desirable option in my opinion.
Doing it at the GStreamer level (either an element with multiple pads or a bin or something like that) is going to be a lot less flexible. Having multiple elements means you can do something like having multiple independant pipelines send over the same SRT multiplex. We could also have a srtsrc and srtsink share the same bi-directional connection.
I agree that this sounds like a nice way to go! I am still reading up on the SRT lib API but it seems to be that a limitation one might end up hitting here is that there may only be one listener on a SRTSOCKET at a time. That might mean we would need some kind of “authoritative” receiver.
I will see dig a bit more and see if I can talk to the srtlib people before returning here.
I had a further look at it, I’m not sure that you actually need to do something so complicated. The caller-connecting signal already tells you about the stream-id of the incoming stream. You can then just have multiple srtsrc/srtsink elements in listener more on the same socket/port and I think each will handle a different stream.