Linux skills would be required to roll your own solution like that. With your Cloud server, you can host that in a VPS, it can then use SRT from the closest server, to distribute to the other servers strategically placed closer to your viewers and with SRT of course you control the latency.Ĭloud Server #1 might be in Australia -> SRT (200ms fixed latency) Cloud Server #2 in Singapore -> Viewer hitting Singapore server.Īnd of course you can rent as many cloud servers as you like and host them at virtually any VPS provider. Vmix SRT -> Cloud Server with heaps of bandwidth -> Clients via SLDP with HLS fallback on Apple devices. I wish Youtube and Facebook would accept it, but for now I "republish" via RTMP(S) from our servers. So from the streaming server to the client, not really popular/useful. Between streaming servers (again supported), so you can build your own CDN with reliable latency.įor now it's not a last mile protocol. I think SRT is a great protocol for me fantastic to get video to the streaming server (my server supports it).
VMIX STREAMING PLUS
How much packet-loss largely depends on how you set the latency (in milliseconds), plus the overhead bandwidth which by default is usually around 20% and doesn't need modification. While not technically faster than RTMP, it has error correction and can tolerate packet loss. Mostly because the latency is "set" and video "fixed" when packets are lost via the overhead in the SRT protocol. I've been using SRT for a while and have to say it's improvement of RTMP. Haivision (developers) have been doing testing around the world, showing how SRT compares to RTMP. According to amazon link above, the following are planned for the future:īut also of interest, and which vMix has partial capability is SRT.
This is an interesting subject, and I think we would all welcome some expert advice.