What does HackerNews think of srt?

Secure, Reliable, Transport

Language: C++

#32 in C++
We have been testing out various protocols to overcome in our case TCP head-of-line blocking by using the protocols->

SRT: https://github.com/Haivision/srt (C++ wrapper https://github.com/andersc/cppSRTWrapper)

RIST: https://code.videolan.org/rist/rist-cpp

KCP: https://github.com/Unit-X/kcp-cpp

We wrap all data in a common container format https://github.com/agilecontent/efp

To decouple the data from the transport.

Yes the above solutions are media centric but can be used for almost any arbitrary data.

The protocols are not 'fare' so starvation may happen, and must be handled on the application level.

/A

I've tried to deal with this many years back, I think the latency is inherent in the protocols, there's layers like 2/3 layers of buffers that by the time the frame reaches the client several seconds have already passed.

When I was researching this back then, there was only one protocol in OBS that was fast enough, but it was proprietary. It was called FTL and was what Mixer used (twitch competitor, now dead). Mixer was so fast that I could move my mouse from the stream window, latency was probably very similar to cloud gaming services today.

Not sure what you're trying to attempt, but if you want low latency webrtc will probably be the best performing because it's p2p, however there's no official support for it in OBS and client support is weird, you might have to cook up some webrtc webpage just for it, but if you want sub 100ms latency it's the way to go.

The alternative that OBS supports is SRT, but I have never used it, the arch wiki claims it has ~1s delay. Maybe the 1to1 version lowers it and it seems simple enough if you can use ffplay/vlc where you're watching.

SRT Project Page: https://github.com/Haivision/srt

Live Server Implementation: https://github.com/Edward-Wu/srt-live-server

1to1 Client Implementation: https://github.com/Haivision/srt/blob/master/apps/srt-live-t...

This project is pretty cool, I’ll tinker around with it tomorrow.

As an aside, I’ve noticed you’re building out your own stream protocol stack (FTL/LightSpeed). What’s the reasoning there? Seems slightly inconvenient to have to “hack” OBS to make the output stream work. Will FTL support be merged into OBS in the future?

If you’re just trying to avoid the latency of RTMP then I might suggest considering the existing SRT protocol[1]. It’s been open source for a while and is well-established(native support in OBS core and optional in FFMPEG). Seems to already solve a lot of the transport-level stuff that you’re working on with FTL.

[1] Secure Reliable Transport: https://github.com/Haivision/srt