Hacker News Reader

Comment by rlyshw | Hacker News Reader

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

View on HN

So FTL is supported by OBS and was used by Mixer. I’m interested to move to SRT in the future since you’re correct, FTL support will be going away eventually

Also the work required to adapt what I have to SRT is non trivial and I would rather have something that works right now and then build in SRT support in the future

Also, you’re not “hacking” obs. oBS is compiled with the FTL sdk you just have to tell it to use it.

Got it. I’m fresh on FTL, first I’ve really dug into it so apologies for the ignorance. I’m in the industry of stream transport and mostly work with SRT.

Looking forward to tinkering with this!

No worries :) enjoy and please let me know what you find!

Apparently since FTL is a proprietary protocol, it is not supported on most Linux distributions.

I wanted to try this, even made a docker config and only then realized I can't stream to it from Archlinux.

SRT seems like an overly complicated solution that has already been solved by KCP protocol.

Yes to the first half of this at least (KCP is not something I've heard of).

Having recently attempted to use SRT for an event's backend restreaming stack, the low latency was nice but it's a pain in the ass. It's really not designed for links where latency isn't known and consistent. You have to bake an expected latency amount into initial protocol negotiation or you'll end up with problems, and OBS' support is quite poor (failure to establish a connection for whatever reason is likely to freeze it up completely, it sucks up a lot of cpu vs. rtmp, etc).

And the other end of the stack is either pretty immature and kind of wonky (haivision's own software, srt-live-server) or requires you to pay to use it or is very closed source.

WebRTC of some sort is definitely the future of this, imo. Even if the stack kind of sucks right now the results are fabulous (discord's video streaming for eg. is webrtc based and is easily the lowest latency free screen sharing I've seen outside share-my-desktop stuff like parsec or rdp).

It looks like this uses the already-built-into-obs support for the webrtc-based ftl protocol mixer used and microsoft killed. That's actually really clever and honestly I think this is far more appealing than SRT.

What sucked about the ‘WebRTC stack’? I think the situation is much better these days. We have multiple options. SRT only has one with lots of bindings. With WebRTC you could use any of these!

* werift (Typescript)

* Pion (Golang)

* aiortc (Python)

* KVS WebRTC (mbedtls, embedded C)

* GStreamer's webrtcbin

* rawrtc (C++)

* webrtc-rs (Rust)

* libwebrtc Google’s Implementation (C++)

SRT is massively complicated hence just the one implementation from one person. It’s based on a defunct file transfer protocol.

RIST adds nack based retransmissions to decades old RTP and has multiple implementations.

Hm it would be interested to see RIST used in OBS

Reply on news.ycombinator.com