vMix is handling SRT as an unwanted option and does not care about it. Going thru the different threads it shows that we need:

- A proper Streaming window for SRT, not only the enable button in the outputs
- A proper Statistics window that will keep updating the stats even if its not in the focus
- A correct handling of audio-pids for streams with multiaudio-tracks, for example multilanguange streaming events
- Support for Audio/Video only SRT streams
- A method to set the encoding mtu-size. SRT is working via UDP, if you do it via a mobile connection and/or 4G/LTE bonding solutions, the available mtu size is much smaller than blasting it out with MTU 1500 via the lan port

SRT is the streaming protocol of the professionals, i don't really understand why it doesn't get more support and love from the vMix team?

Best regards, Martin

vMix 26 will take care of at least one of your concerns (multi track audio with PIDs). The rest of your concerns are valid but I don't think any of them are critical. Your first concern I don't understand but the stats are pretty good in vMix compared to other products. As bonding over SRT becomes a bit more mainstream I think they will add more options for it but 1.5 is barely supported right now. A lot of developers are implementing it quickly as it's open source but for it to be integrated into a product it takes time.

EDIT - I saw some one else raise a similar feature request for the SRT indicator in vMix so I think I see the trend here in having SRT have it's own area in vMix rather than being behind the Output area and having a bit more transparency when it's not working or disconnected.

I'd like to add my +1 to some ideas and comments of the original post:
-A correct handling of audio-pids for streams with multiaudio-tracks, for example multilanguange streaming event

Vmix 26 does support multiple audio tracks - thanks for that feature Team Vmix! However, I cannot set the PIDs manually. Vmix does start with the standard PID 256 for the first audio track, and puts the video track as the one with the last PID. While it is possible on server side to monitor and route incoming audio tracks within an SRT stream while it only contains two or three languages, this does not scale well with the maximum currently possible in Vmix - or for multiple clients at the same time. Especially if the audio engineer/Vmix operator decides to switch audio busses to adapt to some local audio setups just to not get mixed up to much.

So my proposal here:
per audio bus (also for master) add a line underneath the "name" input field, where you can set a PID. This way, the PIDs also can be discontinual in their numbering and alwys represent the same language no matter on which audio bus you put it. The server logic can then sort everything out by itself (picking and remuxing audio/video pids and forward them to the right HLS encoding engine or what so ever).
An alternative solution: Use the already existing name field, and abuse it as a JSON input string, to a) name the language and b) add the PID. E.g. {"lang":"eng", "pid":1005}

Following this idea: the video PID and service PID should also be possible to be set.

My current solution to this is to use ffmpeg to grab the separate tracks from Vmix, put them into a mpegts frame, add the corresponding PIDs and send everything via SRT. Unfortunately the srt implementation into ffmpeg isn't the best either. Monitoring and restarting a failed connection is not a charm at all.


Example of what I mean with discontinual numbering:
Video - PID 999
Bus Master - original floor audio - PID 1000
Bus A - PID 1001: english
BUS B - PID 1005: spanish
Bus C - PID 1006: german
Bus D - PID 1025: mandarin


I also support a dedicated menu to SRT, other than the current placement in the "external" menu.

+1. We're streaming to major US television networks and want to make sure the we stay up to date on the protocol.

Thanks,

Fritz Golman
IHeartMedia