UI: Support FTL URLs for custom streaming service

[haydenmc]

Description

This change allows users to use the FTL protocol when choosing a custom streaming service. By providing a URL starting with ftl:// in the custom server field, the ftl_output plugin is chosen to handle transmitting stream data instead of rtmp_output.

Thank you for your time in reviewing this change!

Motivation and Context

In order to stream via the FTL protocol to a host that is not included in the curated list of streaming services, a user must manually update services.json with a service listing that specifies the ftl_output output.

Along with some folks at Glimesh.tv, I have been building an open-source FTL ingest server, and this change greatly simplifies the process for streamers to configure their OBS client for FTL streaming to a custom host.

How Has This Been Tested?

MSVC v142, Windows 10 20H2 19042.630

• Verified under debugger that ftl:// URLs properly select ftl_output for both Advanced and Simple output
• Verified that a custom ftl://hostname URL results in a successful connection to an FTL ingest server
• Verified under debugger that non-ftl:// URLs (ex. rtmp://) select their respective outputs (ex. rtmp_output)
• Verified under debugger that code path for existing FTL service YouNow is unaffected (younow_get_ingest is called)

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[notr1ch]

The FTL code in OBS is largely abandoned with the demise of Mixer and I don't think we should be encouraging new use cases. I would prefer to remove it entirely at some point as the protocol offers little benefit over other transports already supported by OBS / FFmpeg.

[haydenmc]

Completely understand and agree with the principle of discouraging support for abandoned protocols - I do know our YouNow friends have committed to ensuring that the SDK remains alive @rsiv, and myself plus the folks at Glimesh have as well.

Longer term on the Glimesh side we're investigating developing support for SRT, as that looks to be the emerging de facto standard, but today we have a significant engineering investment in FTL. With our launch nearing, we'd very much like to avoid trying to instruct our users to modify services.json in order to stream with us, and requiring a switch to the SRT protocol now would likely set our project back multiple months.

I understand that as a service that has not launched yet we're a very small voice in the scheme of things for OBS. But I'm hoping that the YouNow precedent is enough to indicate support for FTL at a minimum, and this small change would unblock other potential consumers of this protocol as well.

Thanks again for your time discussing this!

[dodgepong]

Personally I would rather YouNow also work toward dropping support for FTL.

Is there any reason you can't submit a PR to add your service to the OBS services file?

[kkartaltepe]

Personally, seeing two already diverging forks of the SDK is not a very promising claim of keeping it alive in a sustainable way for downstreams.

[RytoEX]

Completely understand and agree with the principle of discouraging support for abandoned protocols - I do know our YouNow friends have committed to ensuring that the SDK remains alive @rsiv, and myself plus the folks at Glimesh have as well.
[...]
I understand that as a service that has not launched yet we're a very small voice in the scheme of things for OBS. But I'm hoping that the YouNow precedent is enough to indicate support for FTL at a minimum, and this small change would unblock other potential consumers of this protocol as well.

To clarify, I pinged @rsiv about ftl-sdk needing a bump in the cmake_minimum_required version because of a warning I received in CMake 3.19 that compatibility would be dropped by CMake for versions older than 2.8.12. Not knowing what "Compatibility with CMake < 2.8.12 will be removed" means or which "future version of CMake", I felt it prudent to alert the only remaining known user of ftl-sdk about the issue. I should have also stated that, as hinted at by the above comments by @notr1ch and @dodgepong , there has been some discussion internally about dropping FTL support largely in part because of Mixer's shutdown and Restream dropping FTL support.

[dori4n]

Personally I would rather YouNow also work toward dropping support for FTL.

FTL is currently the only way to deliver low latency video to a browser, because all an FTL ingest has to do is relay the frames of the transport stream to the WebRTC video client. While SRT does purport to offer low latency, too, support is poor, and inherent difficulties exist that make choosing the right codecs and encoder settings difficult, especially for end users. FTL already defines the subset support for WebRTC video (AVC+Opus@48kHz), such that only handing the packets through is all that is required, and chances are, that the delay will still be lower in practice than using an SRT transport and remuxing (or heaven forbid transcode!) at the relay.

Is there any reason you can't submit a PR to add your service to the OBS services file?

That does sound like a good option on first glance, but even while Beam/Mixer was still around, it was always annoying not to be able to do what this change allows: Streaming to a custom FTL destination via a UI setting alone.

[derrod]

FTL is currently the only way to deliver low latency video to a browser

Well depends on how you define "low latency". Both Twitch and YouTube can reliably deliver glass-to-glass latencies of less than two seconds, even sub-second in some cases. So does Periscope. None of them are using anything but RTMP(S) and HTTP to achieve that feat.

While SRT does purport to offer low latency, too, support is poor

Arguably, support for FTL is even worse, and with the issues that we've had with the current library it's certainly not considered super stable.

inherent difficulties exist that make choosing the right codecs and encoder settings difficult

In the case of OBS this can be regulated through the services file. And disconnecting users that want to send something undesireable is certainly possible. Although OBS could use some improvements in that area.

Streaming to a custom FTL destination via a UI setting alone.

Which is precisely something that we do not want to encourage, as we want to get rid of FTL entirely.

[haydenmc]

Howdy friends, thanks for the discussion, appreciate your time once again.

Is there any reason you can't submit a PR to add your service to the OBS services file?

No reason at all! We have not yet finalized our set of ingest hostnames, but we will certainly open a PR to add Glimesh as a service once that's all said and done.

This particular PR just makes thing significantly easier for us up until that point - however, if the consensus is that OBS is not wanting to encourage users to stream to different/arbitrary FTL sources, I completely understand, and we can abandon this change.

I would like to hear more about OBS intent to drop support for FTL altogether, though, since this change would have a significant influence on our engineering priorities over at Glimesh. Is there a timeline in mind for when support might be dropped? Is there a way for me to stay up to speed on the plan for FTL?

Thank you!

[dodgepong]

I would like to hear more about OBS intent to drop support for FTL altogether, though, since this change would have a significant influence on our engineering priorities over at Glimesh. Is there a timeline in mind for when support might be dropped? Is there a way for me to stay up to speed on the plan for FTL?

Honestly it's been something we've been discussing internally for a bit, which was renewed recently by that CMake PR. As far as we are concerned, FTL as a technology is EOL with the death of Mixer. We would not encourage any new services to use it, and would encourage YouNow to migrate to a more standardized and widespread transmission protocol. We have no interest in continuing to bear the technical load of supporting a transmission protocol that is only in use by one relatively small service provider.

Unfortunately it's true that there aren't a lot of alternatives that OBS supports right now other than SRT, but I would not interpret OBS's current support of FTL as an invitation to continue to perform life support on a dead technology. We are far more interested in supporting protocols that are more standardized and have wider adoption, such as SRT or RIST. There is even talk of a standardized signaling protocol for exchanging SDP for WebRTC in the works, which may be closer to your liking when it is completed.

We're not about to remove FTL support tomorrow, but we will as soon as we are able to.

[haydenmc]

Thanks for the discussion all! I'm going to go ahead and close this request.

I'd like to ask that before removing FTL from OBS consumers such as Glimesh and YouNow can be given some advance notice so we can make sure we're ready to make the jump to a supported ingest standard on time. I would very much appreciate it! We will be actively investigating SRT support in the meantime.

Thanks again for your time!

[dori4n]

FTL is currently the only way to deliver low latency video to a browser

Well depends on how you define "low latency". Both Twitch and YouTube can reliably deliver glass-to-glass latencies of less than two seconds, even sub-second in some cases. So does Periscope. None of them are using anything but RTMP(S) and HTTP to achieve that feat.

When I said low latency, I meant it. Using WebRTC/FTL the latency can be as low as the encoder + network packet latency, measured as first in, first out. That will easily be less than 50ms. Maybe 100ms if you're talking US East Coast to US West Coast or US East Coast to Europe. For most users on Mixer who weren't optimizing for ultra-low delay, the real delay was still between 160-250ms (I am deliberately excluding those who intentionally or through misconfiguration had a delay of a whole second or more). That is below what most professional video post-processors use for A/V sync precision. You can play games through the livestream like this. With Twitch's "low-latency" RTMP/HLS implementation, you can't do that at all, since the perceived input lag is too severe.
The best SRT can do is around 80ms under very optimistic conditions, between 300-500ms is more common (better than RTMP, not really better than WebRTC).

with the issues that we've had with the current library it's certainly not considered super stable.

Could you elaborate on that? Yes, granted, there are some things the FTL SDK doesn't do, but which WebRTC offers, but in all my time using it and its various iterations, I haven't really had any considerable stability issues.

[rsiv]

I hope I'm not late to the party, but FTL works great for us. The main benefits are indeed the low latency, the easy integration with our WebRTC media server, and the fact that it is already supported by OBS. @dori4n thanks for elaborating on these points.

That said, we would love to see native WebRTC support in OBS. We experimented with it in the past, but it wasn't stable enough and we didn't want to maintain our custom build. Would you let me know when you discuss the signaling protocol so I can make sure it works for us? If we can get OBS to work with WebRTC, we'd be ready to drop FTL support.

P.S. One issue we have with FTL is when it is disconnected from ingest, it keeps trying to reconnect in a loop even after it successfully reconnected. Seems that send thread exits too late and causes the new stream to stop, but I'll need to debug it.

[nazar-pc]

For WebRTC there is already https://github.com/CoSMoSoftware/OBS-studio-webrtc with IETF draft implementation.
It would indeed be interesting to see native WebRTC support in OBS sooner than later.

[dodgepong]

Yes, we are watching the development of WHIP closely. It could possibly be a xkcd 927 situation but I would be happy to see wider adoption. Right now our biggest hurdle to WebRTC is our distaste for libwebrtc. We would be much happier if there existed a C-compatible library similar to this or even this (with the latter being a more likely possibility).

[Sean-Der]

@dodgepong https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c might be a good candidate! It is a pure C PeerConnection implementation has the same API as the browser.

it isn’t coupled with AWS either. It comes with a set of functions to make interacting with their REST API easy, but not needed. here is an example of exchanging media between two peers.

[dodgepong]

Thanks @Sean-Der, we'll definitely take a look at this!

EDIT: It appears that project depends on OpenSSL, which is problematic for the GPLv2 license.

EDIT 2: It works with mbedTLS, hooray!

[NCommander]

I'd like to ask the OBS team to reconsider this, or at least give an extension to axing FTL. I'm the original developer of FTL, and I maintained the Tachyon fork of OBS before FTL support was merged into mainline. I've take up stewardship of reviewing the protocol, standardizing it, and hopefully submitting it as an IETF draft at some point. The entire intent of the standardization is to avoid fracturing the ecosystem (which we're on the verge of doing, but I think we can stem in time).

Right now, I've got FTL-SDK forked off here https://github.com/ftl-protocol-dev/ftl-sdk with the intent of making this the new 'canonical' version of FTL SDK, and if there are breaking problems with OBS, I will be willing to commit to ongoing to support. We're also working on fully documenting the protocol and removing any ambiguity between implementations here: https://github.com/ftl-protocol-dev/ftl-specification. I'll admit we're still in the early days of getting here, but we're on Discord (https://discord.gg/5mt2g4qQ), and it's moving at a decent clip; I'm hoping to have the first finished draft in a few weeks.

At this time, Glimesh (https://glimesh.tv/) and @haydenmc have a working "in production" FTL stack, as does restream.io, and there are at least two independent implementations of FTL beyond that. I can understand wanted to axe the code, but I'm hoping you'd consider belaying for at least a little while that while I work to help build reference implementations and standards for the protocol, and Glimish and those filling Mixer's void.

If OBS does drop FTL support, it would mean forking, and reviving the original Tachyon client like we did pre-OBS integration, which frankly, isn't going to be pretty for anyone because I was at Beam, and it was a headache for all parties, and I'd like to avoid it if possible.

[dodgepong]

If OBS had supported WebRTC or RIST before you started working on FTL, would you have still worked on FTL? What problem is FTL solving that can't be solved by a more widely-accepted and open standard? What is the main advantage of FTL over other transport protocols beyond the fact that it's already implemented in OBS?

[Fenrirthviti]

Also to be clear here, we aren't, and never were, going to drop support immediately and that isn't the current plan. We wouldn't rip this out from under anyone without talking about it first, we are just expressing our current approach. Expect a discussion to open up on the project sometime either today or tomorrow on how best to proceed.

[dodgepong]

Please direct further FTL discussion here: #4021

[dodgepong]

Reopening this since we have not actually dropped support for FTL at this point, and it's a reasonable QOL change.