ZSzsiec·Feb 20, 2026
Ported from https://github.com/Haivision/srt with interop and bench tests
In No Compromise Pure Golang Version of Haivision's SRT (Secure Reliable Transport)Haivision
srt
C++2021–2026
Haivision / srt
srt
Secure, Reliable, Transport
4Distinct people
4Mentions
0Explicit recommenders
3.6KGitHub stars
What to know before exploring
What it is
Secure, Reliable, Transport
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year4 dated mentions
Observed mentions: 2021-01-04 06:59:06 UTC to 2026-02-20 20:30:08 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
4 sourcesWe 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
In We need a replacement for TCP in the datacenter [pdf]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
Read the rest
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
In Show HN: Lightspeed – subsecond, open source, self hosted stream from OBS