GRVYDEV
Info: The Future of FTL
Hi there!
I was crawling through everything around the tech used in Lightspeed. I even found https://github.com/obsproject/obs-studio/issues/3881 by @GRVYDEV
As I am somewhat a packaging freak I brought FTL to Arch Linux today with the AUR package obs-studio-ftl. To get this upstream into Arch I planned to upstream my changes needed for packaging in OBS: https://github.com/obsproject/obs-studio/pull/4018
But looking at comments in my PR, as well as this PR it seems as if FTL is going to be removed soon-ish from OBS, as it is unmaintained and there are competing protocols trying to achieve the same goals.
Therefore I want to propose to move away from FTL to SRT, which could be a really good replacement, that's already supported in OBS through ffmpeg.
To be honest this is really a bummer as Lightspeed is really amazing software. But building on a wonky foundation would probably make maintaining this more and more difficult over time.
There are a few SRT protocol libraries on crates.io. Notably srt-rs which procides bindings for the aforementioned SRT library.
Now I haven't researched anything regarding codecs and how easy the SRT -> WebRTC "translation" will be. I might add more details later
You're awesome! So yes OBS wants to ditch FTL however I am working with a group of people (including the original mastermind behind FTL) in order to canonize it and revive it. I am not sure how long that will take however worst case we will maintain a fork of OBS with FTL support. I don't want to move to SRT since A) its super complicated and B) converting SRT to RTP sounds like a nightmare. This is the reason that I want to keep the ingest decoupled from the WebRTC broadcast though as someone could easily swap another ingest in as long as it outputs RTP packets
That sounds double awesome!
I would then really suggest that you chime in on my PR, as that might help to keep the support alive. Because from their perspective it just seems dead right now, which is totally understandable.
That sounds double awesome!
I would then really suggest that you chime in on my PR, as that might help to keep the support alive. Because from their perspective it just seems dead right now, which is totally understandable.
Done :)
I am going to reopen this issue since there are some things going on behind the scenes with OBS and FTL. There may potentially be another fork of OBS created in order to maintain FTL support but as of right now it looks like we will have support until Jan 2022
I use SRT and wrap it in WebSockets with Nimble Streamer and would be totally up for SRT in Lightspeed but I do imagine there is work that would need to be done on the server side.
It seems just to unwrap the SRT stream (which just wraps around whatever streaming media you send "through" it) and then transmits it over WebSockets, uses minimal CPU also.
There is also https://hjortsberg.org/notes/Sending-UDP-over-Internet-using-SRT.html which should explain it more.
I will say that I probably will not implement SRT. 1) it is not low latency and 2) it would require transmuxing which would add cpu and latency overhead
I get about 100ms encoder-to-decoder but I do agree about the transmuxing bit, Good to know and no worries!
What is the current state of the world for FTL + OBS?
With regards to the current situation on FTL staying in OBS, it seems unlikely at this point.
See this discussion about it
OBS is moving to support this use case via WISH-based WebRTC output. This is essentially the same way that FTL works except you use a WebRTC SDP negotiation instead of the simpler FTL negotiation. It's probably worth implementing a WISH endpoint
