Adding FTL as ingest protocol

[llspalex]

Has Airensoft considered adding FTL support to OME? Specifically for use with WebRTC playback.

I know it's a bit of a 'dead' protocol, but it does have native OBS support and since this merged PR, it is much easier to stream using FTL in OBS. You can enter an FTL URL in the output settings the same way you can an RTMP URL (so there is no need for a custom services.json file, like there used to be 😃).

FTL uses h264 video and Opus audio, so there is no audio transcode required like there is for WebRTC playback of RTMP sources. It also uses UDP instead of TCP, so it's good for use cases where ultra low latency is the top priority (ie. it doesn't add additional latency when packet loss occurs, like RTMP does).

Project Lightspeed is a popular repo that supports FTL with WebRTC playback, but it isn't anywhere close to being as sophisticated as OME is as a media server: https://github.com/GRVYDEV/Project-Lightspeed#about-the-project

Some interesting notes on FTL: https://hayden.fyi/posts/2020-08-03-Faster-Than-Light-protocol-engineering-notes.html

OBS is planning to deprecate FTL when WebRTC output is added: https://github.com/obsproject/obs-studio/discussions/4021 Here's the RFC relating to WebRTC output from OBS: https://github.com/ddrboxman/rfcs/blob/patch-1/text/0043-webrtc-output.md

But it's hard to know how far away WebRTC support in OBS actually is (Q4 of 2021 seems ambitious), and the OBS maintainers have said that FTL will continue to be supported for 9 months after WebRTC support arrives.

I know that it is probably not worth it to add support for an ingest protocol that is 'on its way out' - but it would be interesting to know if Airensoft has considered it / what your views are on this.

[getroot]

In the past, FTL support was one of my top priorities. That's because OME can play WebRTC without re-encoding OPUS, and OBS supported it. But unfortunately I forgot FTL since Mixer was shut down. The first Mixer was one of the services that shook my heart. It would have been great if they had added to the content as much as they invested in technology.

[llspalex]

@getroot I too was amazed by Mixer's FTL when I first tried it.

Is there any chance FTL will make its way into OME? It is really great that it doesn't require any server-side encoding, plus the now-easy use of FTL URLs with OBS. It seems to be making a bit of a comeback, with open source projects Glimesh and Project Lightspeed supporting it.

[getroot]

Well... I have a lot of higher priority tasks. For example, full support of WebRTC WHIP, LLHLS, LLDASH, ABR (WebRTC, HLS, DASH), higher stability, higher performance, lower system resource usage, full support of RTSP, etc...

Among them, WebRTC WHIP is probably a good alternative to FTL. This will also get better in the future as no server-side encoding is required and even Simulcast or SVC is supported. And I'm one of those people who believes AV1 can unify all codecs eventually. FTL will unfortunately not be able to support it properly.

[getroot]

And as you can see, WebRTC is already too vast, and more features will be added in the future. Can I support them all? I will keep working hard. FTL will not be of interest to me unless there is a special event.

[llspalex]

Thanks @getroot - always interesting to hear your thoughts.

[basisbit]

FTL nowadays is mostly replaced / succeeded by SRT based streaming. It has all the advantages of FTL but does not come with the disadvantages of FTL.

See https://restream.io/blog/streaming-protocols/

[llspalex]

@basisbit I experience higher latency when streaming SRT from OBS to OME with WebRTC playback, in comparison to RTMP. With the same x264 encoder settings.

With RTMP I get ~300ms glass-to-glass latency, with SRT ~900ms. I haven't found a way to reduce this with OBS / SRT / OME.

[basisbit]

SRT will use the buffer size which you specify. You probably just din't specify one and thus a way too big buffer by default was used.

I suggest you to read this: https://castr.io/blog/srt-vs-rtmp/ for some real world data. Then add something like &latency=100000 to your SRT URL. OBS developers suggest using a buffer size (latency value) of 2.5 times the transit latency between you and the server. See https://obsproject.com/wiki/Streaming-With-SRT-Protocol

With RTMP streaming, it is pure luck if low delay stream playback works or not. As soon as there is even just a little occasional packet loss, RTMP latency goes up.

[llspalex]

I am familiar with the OBS link, which states that the default latency is 120ms so I didn't think it requires specifying in the SRT URL. Nevertheless, I expriemented with specifying &latency=100000 in the SRT URL and seem to have much better results latency-wise (more in line with what I've been getting with RTMP).

I believe the SRT latency is / can also be set by the listener (ie. OME) - which defaults to 120ms - but couldn't find reference to this in the OME source code. And that the latency of the stream will be determiend by whichever latency is set higher (between caller and listener).

I consistently get really low latency with RTMP ingest and WebRTC playback, as do others. I'm talking streaming daily for months. Granted the ping to my nearest OME server is only 8ms. But yes - on occasions where there is packet loss, the latency goes up - sometimes substantially. I have been very impressed with SRT when used to stream over very long distances (ie. EU to Australia), where RTMP just collapses.

A WebRTC protocol like the proposed WHIP I believe will be better than both FTL and SRT for ultra low latency requirements. Will be interesting to see how that unfolds.

[getroot]

I closed this issue because it has been inactive for a long time. If further discussion is needed, please do not hesitate to reopen the issue.