Srt: multiple streams with different modes

[vandanachadha]

My requirement is to start a process which will create multiple streams, with my server being in listener mode for some, and in caller mode for others. From what I understand of srt-multiplex, this can be used for either i (input) or o (output). For my problem, do I start multiple instances of srt-multiplex in different threads? Or is there a better solution. Pls advise

[rndi]

@vandanachadha , I would suggest a single thread serving a collection of listener and caller sockets configured for non-blocking operation. In fact, you should be able to re-use at least some of the code in srt-live-transmit main loop to do just that. You don't have to call SRT send/receive APIs from the same thread as these calls are protected internally.

[ethouris]

The srt-multiplex tool does indeed multiple SRT connections (within one application) using one single so-called "UDP-channel" (a pair of host:port that send UDP packets from one to another). All connections would have to be made inside one application because it's not possible to bind one UDP port simultaneously by multiple applications (more precisely, it's possible, but you don't have any per-app dispatching capability, even if a system allows it). The "UDP channel" is all that the system can see, so for the system transmitting multiple streams over this channel looks like just one stream.

As I understand you're trying to run transmission of multiple streams, so the sender would get streams from multiple UDP ports and then resend them through SRT, but there would be some receivers each one potentially requesting a different stream. If you want to receive ALL THESE STREAMS at once by the receiver, then you should simply run ONE instance of srt-multiplex on the receiving side (as SRT caller), of course redirecting every stream to a distinct UDP port.

If you want to have a potential receivers that may request one of the streams that your SRT listener is serving, you may try to use simply srt-live-transmit to receive it, just add the streamid=<name> parameter to the URI so that the listener will pin your connection into the right stream; I don't know if this really works (that is, whether srt-multiplex correctly handles the multiple connections, including breaking and reconnecting while streaming) because I have never predicted srt-multiplex to be used for anything more than to demonstrate how the Stream ID and internal multiplexer are working.

Anyway, this "internal multiplexer" feature was predicted to be used in network environments with some serious firewall settings, such as that only one port will be available for you to use. With this you can make multiple connections from one application where the source UDP port is the same. Additionally the Stream ID feature was predicted for such a situation that you expose one UDP port for SRT connection, but it will serve multiple streams. You connect to it and additionally the Stream ID specifies, which exactly stream you want to receive.

[vandanachadha]

Thank you both for your comments, but pls help me decide whether to use stransmit-live or srt-multiplex. I am a novice in this arena and your guidance is very valuable.
From what I have understood from above:

1. Make changes to starnsmit-live main function to start a thread, and in this thread, within a loop, create a source/target and start a stream with a name in non blocking mode, and then iterate to next source/target, start another stream and so on.
2. Or use srt-multiplex?
   To clarify, what I am trying to do is, "trying to run transmission of multiple streams", and each stream consists of a mode (listener,caller, rendezvous) and a source port/ip and a destination port/ip. So there can be a stream in caller mode on source 192.168.1.1:8001 and destination 192.168.1.2:8002 and another stream in listener mode with source :8003 and destination 192.168.1.3:8003 and so on.

[rndi]

Hello @vandanachadha, option (1) in your list should work. 'srt-multiplex' is more of a 'stream trunking' solution and it does not sound like that is what you are after. I am actually contemplating if we should add 'one-to-many' capability to srt-live-transmit: it should not be that hard and will give us an opportunity to polish up that code. Perhaps you can contribute some code from your experiments that can help with that.

[stoyanovgeorge]

Actually, there are more people who want exactly that feature @rndi . You can refer to issue 574

[maxsharabayko]

Closing this request.
srt-live-transmit is meant to be a simple application, a quick start for people to get themselves familiar with the protocol and workflows. The main development effort is focused on the SRT library itself.

Having multiple clients sounds like a solution (e.g. SRT Gateway) that depends on the target appliance. Definitely not something for a sample application.

But the application you need can be quite easily done based on the code of the srt-live-transmit. The SRT library fully supports this workflows.