dodgepong on Jan 6, 2021

While SRT is supported it does not seem that there is anything using it? I haven't gone all the way through SRT yet however I am struggling to even find adequate documentation that I could even base an implementation off of.

This might be a reasonable place to start: https://github.com/obsproject/obs-studio/wiki/Streaming-With-SRT-Protocol

I would also invite @eric to share some of his experiencing using SRT in production settings.

Furthermore, I am not entirely sure how FTL negatively impacts OBS right now to justify its removal without the implementation of a suitable alternative (ex. WebRTC, RIST).

From the OP:

FTL support in OBS has always been buggy and problematic, and would break in mysterious ways for many users. While we could invest development time into debugging these issues, the opportunity cost of maintaining FTL support is far greater now that the protocol's progenitor and primary consumer is now defunct.

Essentially, it comes down to a support problem, which brings with it the weight of maintenance. People come into our support channels complaining about problems and we track down their problems to their use of FTL for one reason or another. We could spend time working on fixing OBS's issues with FTL, which could be time-consuming, but it's hard to justify doing that when so few people are using it anymore, especially with Mixer dying. It was developed to solve a Beam/Mixer problem, not an Internet problem, and as such it wasn't really developed with openness in mind (as evidenced by Mixer's refusal to release a server-side implementation). If we are going to spend time on a protocol in OBS, we would rather it be one that was open from the beginning, and actually has community and industry buy-in.

The only reason YouNow, Glimesh, etc. even bothered to base their services on FTL wasn't because it was a good protocol, but for two reasons: 1) it was supported by OBS, and 2) it wasn't RTMP. In my opinion, those aren't good enough reasons to pick a protocol. Standardization should also be a factor, or else every company out there would invent their own proprietary protocol and want to get it into OBS. I know, because other companies have tried to do that in OBS -- they propose some sort of non-standard janky protocol, and try to get OBS to support it for their own use. It has happened, and we've turned them down. If I'm being completely honest here (and this is my own opinion), I don't think we should have accepted the FTL output in OBS to begin with, and it was aggressive of Mixer to push it by fiat from the beginning.

The only reason FTL still exists at all is because still OBS supports it. It's a reverse chicken-and-egg problem.

If your issue is that there isn't currently a viable alternative to FTL in OBS for your purposes, then fine, that's a valid concern. We would be willing to talk about adjusting the timeline until a viable alternative is in place (most likely WebRTC). But I have yet to hear the merits of why FTL itself should continue to exist in light of other protocols that do the same thing but with more industry support and existing standardization. I'm all ears, though.

This might be a reasonable place to start: https://github.com/obsproject/obs-studio/wiki/Streaming-With-SRT-Protocol

It is not. SRT cannot compete with the low delay of FTL at all. And in addition to that, in order to deliver the video to a web browser, this requires both buffering and remuxing of the packet stream, which adds further delays.
Realistic delay for FTL (with h.264+Opus): time to encode a frame + network FIFO latency + ingest forwarding latency + time to decode first i-frame ~50-250ms
Realistic delay for SRT (with h.264+Opus, which you do not support, only AAC-LC works): time to encode a frame + A/V sync buffer delay + network LILO latency for i-frame + input buffer delay + remuxing delay + time to decode first p-frame ~700-900ms (optimistic)

[...] or else every company out there would invent their own proprietary protocol and want to get it into OBS. I know, because other companies have tried to do that in OBS -- they propose some sort of non-standard janky protocol, and try to get OBS to support it for their own use. It has happened, and we've turned them down.

I don't quite understand how adding protocols is a bad thing. At the very least, you should allow the addition of protocols through a plugin that gets installed separately, such that (at least on Windows) your signed and pre-built binaries can be used with any protocol and manually specified ingest server anyone could possibly want. Currently, that's not possible. Yes, someone can fork OBS and build their own binaries, but unless these binaries become well known, anti-cheat systems everywhere will block them from capturing video games (had been a big problem with FTL enabled builds of OBS before it got added to the official releases), require the purchasing (and proper use!) of expensive security certificates from an approved certification authority or just simply fail to run because modern security systems would block them ("[anti-virus] hasn't seen an executable with this file size and sha2 checksum before, for your safety, you may not run this"). This was the key motivation to even try to get it into OBS, rather than publishing and updating a fork, where whenever an update was released, BattlEye and EasyAntiCheat (the most popular solutions video game vendors were using at the time) would have it blocked, and people would roll back to the older version or never bother to update in the first place.

The only reason FTL still exists at all is because still OBS supports it. It's a reverse chicken-and-egg problem.

That OBS supports it is a bonus. FTL is proven technology. Beam/Mixer have been using it together with Janus for ~6 years (only about 2 of which it has been in OBS).

If your issue is that there isn't currently a viable alternative to FTL in OBS for your purposes, then fine, that's a valid concern.

There is no viable alternative, period. Even using the full WebRTC stack in OBS (current implementations do exist) doesn't offer as low of a delay as using FTL does (it's not a real concern to shave off those 50-100ms, whereas FTL's transport was designed for just that). When using FTL with a good ingest implementation (something that's not quite there, yet, either), getting the internal delays in OBS down would be the next logical step (they're still quite significant sometimes, even though they could be as low as 7-8ms with a GPU encoder these days).

dodgepong on Jan 6, 2021

Out of the three reasons you stated, the first two are just plain wrong

Can you explain how the first two reasons are just plain wrong? From the OP:

1. FTL was created by Mixer, who lead its development. With Mixer's demise, we consider FTL to be dead technology.

This is at the very least a matter of opinion, and our opinion is that it's dead. If you have a different opinion fine, but that doesn't mean the reason is "wrong". If you want to keep FTL around, then your job is to change our opinion. Convince us that FTL is not actually dead and is worth keeping around in context of other standards that had more standardized and open development with more industry buy-in.

1. While the FTL SDK is open source, the original server components are not. There are a variety of reverse-engineered server implementations available, but they are fragmented. We would prefer to encourage service providers to use more widely-used standardized protocols instead.

Are you suggesting that Mixer actually did have an open source server component released publicly? Can you link it to me?

and the third one, while understandable, usually comes down to one thing and one thing only: a bad internet connection

Are you offering to take ownership of the FTL implementation in OBS's code base, then?

Are you offering to take ownership of the FTL implementation in OBS's code base, then?

This is actually something that we have been discussing and may be willing to do

• Jay who's in the broadcast industry and with whom I did some tests with srt/obs when rewriting the srt output managed to have as low as 100-150 ms latency. You can talk to him on our obs discord server for details.

I am assuming here that this was also SRT to the client player, right?
I have not tried the Wowza Streaming Engine (costs money, there were free options). If someone has access to that and can test the delay with WebRTC delivery (which they now list is supported, it wasn't when I evaluated this last!) on a local network, please do get me some numbers about how many frames a 720p (16:9 aspect please!) 60fps video feed is behind the OBS preview and what the peak and mean A/V desync is like (there are standard tests for this, I don't think this needs explaining).
Nimble Streamer doesn't offer WebRTC output, leaving the only other browser delivery mechanisms to RTMP/HLS and RTSP (requires Flash, which isn't an option in just 6 days!). The former defeats the purpose of even using SRT and both require transcoding and/or remuxing and as such a frame buffer of up to several frames. Using SRT output (which doesn't work in a browser) gave between 80-300ms of delay on a local network. Using a remote network you easily pass the half a second mark, which is twice the delay of what you can get with FTL.
Edward Wu's SRT Live Server tested with similar results, not suitable for browser output, either.

• Latency is smaller in ftl than the alternatives (except webrtc ?). But srt or rist trade this off with better network resilience. IMHO lose a bit of latency against quality / stability is not a bad trade-off. Have in mind that many obs users have a bad internet so network congestion management is a big plus.

FTL is not resilient on packet loss by design. Its goal is to offer the lowest latency possible. If you add a retransmission mechanism, you need to have a (rather large in this scenario) buffer both on the output and the ingest's input. If you lose a frame, you wait for the next one, because by the time you realize something's amiss, that frame that would need retransmission is already out of date. Instead, you communicate to the output that you'd like to have a keyframe as soon as possible and continue from there. This will cause the video to shortly freeze because a frame was lost, but keeps the delay low, which is what you want here (resilience to be as real-time as possible, rather than resilience to deliver every frame). FTL works over "bad connections" (temporarily congested), it doesn't work over "broken" connections (that is those which intentionally block or drop traffic) or connections with insufficient bandwidth to reliably deliver a keyframe whenever one is needed.

FTL is not resilient on packet loss by design. Its goal is to offer the lowest latency possible. If you add a retransmission mechanism, you need to have a (rather large in this scenario) buffer both on the output and the ingest's input. If you lose a frame, you wait for the next one, because by the time you realize something's amiss, that frame that would need retransmission is already out of date.

I believe your assumption of SRT's inner workings here is incorrect, as far as I'm aware SRT uses forward error correction instead of retransmission for low latency packet loss resilience. (Correct me if I'm wrong)

EDIT: pkviet informed me that RIST does FEC, and SRT does too, but only since the very latest release. SRT used to not support FEC. My point still stands, FEC is better than no resilience by design, and incurs no latency penalty.

FEC is better than no resilience by design, and incurs no latency penalty.

That depends on how it works. In typical failure situations, entire UDP packets (multiple of which would make up a h.264 frame) are lost. To account for this, a significant amount of bandwidth needs to be used for this error correction, and for the example of Reed-Solomon coding in order to recover a frame of which a packet was lost, at least as many more packets with the same size of the lost packets are required. In order to compute the correcting code, you also need an output buffer and compute the counter value over all packets of a frame. This means incurring a delay of at least one frame for both the output buffer and the input buffer (actual delay depends on the framerate as a result), and additionally, the delay of computing the correcting codes. It may be possible to immediately send off what is in the output buffer while the computation happens and then not send any error correction packets, if all packets were delivered error free, but this difficult (you'd need to be able to reliably do all of that in under 3ms) to get right and introduces about the same delay as retransmitting lost packets, possibly a worse one on the ingest, since error correcting computation is required in addition to transmitting extra packets. If packets can be delivered and repaired significantly faster than frames are generated this works out great, in resource constrained environments (typical situation where issues occur) not as much.
Of note, this is overly simplified and only looks at the video aspect of the transmission. You tend to also have audio and possibly other metadata (closed captions, titles, format switches, etc.) to deal with.

dodgepong on Jan 6, 2021

Hey there! Part of the reason we opened this discussion was to see if the timetable was a reasonable one, so I'm happy to answer questions. I also have a few questions for you, if you don't mind.

Do you require services to be available for users to stream to? Or could we add Glimesh before our launch?

Generally we do check to see if a service is live before we merge a service PR, and we periodically check our services list to see if any existing services have silently died so that we can remove them. That said, there are some services listed that are not "open to the public", so that is not a disqualifier.

If you do require the service to be available, how much flexibility exists around the 1st timeline? Could we have the PR submitted but only merge it when the service launches?

Does your team have a date in mind that you were hoping to submit the PR? If we are going to move forward with FTL deprecation, we probably don't want to push it too far, but we might have some amount of flexibility still in that instance.

Do services.json updates go out frequently, or only with OBS releases? If so, could we merge it before the 1st to line it up with an OBS release?

Services updates are not tied to OBS releases and can be updated independently (and frequently are).

Once we are live, would you allow new regions to be added to the existing services list if they are using FTL?

Any now, my questions for you (which are all sort of variants of each other):

• What made you decide to use FTL over other alternatives? What alternatives did you consider?
• If OBS had not supported FTL when you started your project, what would you have done instead?
• If OBS had supported all major protocols as well as FTL (i.e. all the protocols mentioned in the OP), what would you have chosen, and why?

Thank you for your response, I am of course happy to help explain my point of view here, in addition to @haydenmc's already posted feedback below.

Generally we do check to see if a service is live before we merge a service PR, and we periodically check our services list to see if any existing services have silently died so that we can remove them.

Does your team have a date in mind that you were hoping to submit the PR? If we are going to move forward with FTL deprecation, we probably don't want to push it too far, but we might have some amount of flexibility still in that instance.

Awesome, that seems like we can make something work before the deadline then. We're very close to solidifying our available regions, and once we have that ready we can submit our pull request to add Glimesh to the services list. I'm so very excited about our upcoming launch, and I really appreciate y'all being flexible. I don't see any reason we couldn't get our services changes done before the Feb 1st deadline.

What made you decide to use FTL over other alternatives? What alternatives did you consider?

For us, there were a couple of reasons that FTL was chosen, but it might be helpful to explain the impetus behind "sub second streaming" in the first place. For me, real time engagements are the absolute future, especially in a internet connected, post (or mid) covid world, connecting audiences in real time with video, text, and other interactions is a beautiful way to deal with our ever-disconnected lives. Low latency streaming is not required for all communities, some streamers focus on the game, others focus on their in-game party members, but for the streamers who focus on chat (their community) low latency is paramount. It delivers a level of engagement we're not used to outside of real life and promotes engaging situations where you can feel like a bunch of old friends hanging out. Game streamers, musicians, programmers, and all other types of streamers find the value associated with true sub-second latency and Glimesh is here to deliver that to them.

So when Mixer died, communities were left without a home or even a viable alternative that had the same focus on these real time engagements. We started work on an early alpha preview immediately, joining in real time websocketed chat, along with Oven Media Engine's low latency RTMP => WebRTC & WebSocket streaming setup. We had good results but there looked to be early support issues & scaling issues that meant that OME wasn't quite ready for us.

Shortly after @haydenmc joined and shared the same passion for real time engagements and having worked with FTL before, preached that it could be a solid base for us. When he was explaining it to me the focus was really on the simplicity & reliability of the protocol. As a programmer simplicity excites me, as a nerd carrying on cool technology invigorates me, and as a founder FTL meant that we could deliver our users exactly what they were missing post-Mixer.

If OBS had not supported FTL when you started your project, what would you have done instead

If OBS has not supported FTL, we would have looked for alternatives that OBS did support. Unfortunately, OBS does not have too many hardened protocols for low latency streaming so I feel that might have fell on the multiple-second-latency RTMP and we would have lost something paramount for our community.

If OBS had supported all major protocols as well as FTL, what would you have chosen, and why?

As a small company the balance is always time and functionality. We have to pick and choose to build the best product for our community. My decision criteria would be to find the technology that we are comfortable with, with the required features, that is simple, and has a proven track record of success for sites similar to ours.

I again want to thank you for your time and flexibility, next steps from my side are to get Glimesh added to the services list as soon as possible.

Awesome, that seems like we can make something work before the deadline then.

We'll be on the lookout for your submission!

the focus was really on the simplicity & reliability of the protocol

It's interesting to me that the reliability of the protocol was mentioned as a feature, because if there's one main takeaway I've had from this discussion so far, it's that FTL's dedication to low latency is a double-edged sword whose other edge is low reliability. From @NCommander's post:

The primary difference between WebRTC, RIST, and HST vs. FTL is that FTL is designed to lose packets and intentionally does not give any notion of reliable packet delivery

Indeed, this low reliability seems to be the thing that gave FTL its reputation among our crew of OBS support volunteers as "buggy", as many users' frame dropping problems would be solved by them switching to RTMP on the same network.

@NCommander described FTL as "proven" in terms of its performance. As someone on the service side putting FTL through its paces, what has been your experience while testing FTL in suboptimal network connections, as might be found among a general user populace?

I'd also like to suggest another possibility in terms of the timetable. What if, instead of removing FTL on January 1st, 2022, we committed to implementing WebRTC output that allowed people to create plugins for their SDP exchange method of choice (WISH/Janus/Mediasoup/etc.), and then removed FTL an appropriate number of months after that was released?

Hi @NCommander, and thank you very much for this lengthy and comprehensive post. This was the sort of thing I've been looking for.

I confess that I've had to do quite a lot of learning and reading over the last several days to improve my understanding of all these different protocols, so I want to offer my apologies if I've said things in this thread that may not make sense or are even factually incorrect. I appreciate the explanation and context you’re able to provide here, especially as someone who was involved with the creation of FTL at the beginning.

If I’m understanding your post correctly, you’re saying that the advantages of FTL over other protocols are the unique combination of:

• Priority on low latency above all
• A built-in, uncomplicated signaling layer
• Easy transmission to viewers via WebRTC

Is that a fair summary? Did I miss anything?

(The remarks about FTL's success in the real world are fine, but I excluded it from the above list since it isn’t, strictly speaking, a feature of FTL. It is evidence that FTL is a useful protocol, but not a reason FTL is a useful protocol.)

Furthermore, I need to ask a question: what is the ongoing cost to keep this code in OBS? ftl-sdk isn’t what I call a fast moving target, and most of it hasn’t changed in a long time.

I tried to explain it earlier, but I will do so in more detail here. Ultimately, I think it comes down to the very fact that FTL was designed with low latency in mind instead of reliability. When it works, it’s great! When it doesn’t, users complain to us. FTL connections can fail catastrophically with extremely high numbers of dropped frames. Often, this was happening with users that had poor internet connections, but not exclusively. To quote one of our support volunteers:

When Mixer was still up, FTL was a pain to troubleshoot, because we didn't understand it very well, and didn't know what kinds of mitigating factors could be taken. Mostly it boiled down to: Using FTL: Dropped frames, stream looks terrible. Using RTMP: No dropped frames, stream ran perfectly.

The concern here is that a protocol that doesn’t have reliability as a priority translates into more people flooding our support systems wondering why their stream is dying. If the protocol is only intended to work on solid internet connections, then what are users on poor connections supposed to do, and how are they supposed to know if their internet connection is solid enough? Are they SOL? This is something that should be very clearly communicated to the user on the part of both the service provider and the encoder.

On the encoder side, the best solution would be something that could forcibly test users’ hardware and internet connections to verify that they can even successfully stream at all using FTL. But at that point, we’re talking about devoting development effort toward new features and bug fixing -- time that could be spent doing other things. We have an extremely limited development team (1 full-time developer) so we have to constantly make prioritization choices. Thus, we have to ask ourselves if continuing to support FTL is worthwhile, given the death of Mixer and the historical support problems that it caused for us.

In complete fairness, these support issues don’t come up nearly as often anymore since Mixer died. That said, FTL’s very presence in OBS encourages people to use FTL (see: Glimesh), which could raise the support load of the feature back up again. This leaves us with a choice: either deprecate FTL to discourage the continued use of FTL, or leave support in the program and commit to spending dev time/support time on it instead of other things.

In my opinion, the only way the right choice can be made on that decision is to determine whether the existence of FTL at all is justified in context of alternatives. If FTL deserves a place next to the other major streaming protocols, then it deserves support in OBS.

And the answer? Well, that’s what we’re discussing here. I think you’ve made a reasonable case for why FTL is unique among other protocols, which is an important step in favor of keeping FTL support, so thank you for that. Working on formalizing the FTL spec helps with that too.

As a side note, some of my OBS colleagues have suggested that the goal of ultra-low latency above all has not been sufficiently motivated (That is, what is the meaningful, practical difference between a unidirectional stream with 750ms latency vs. 250ms latency? What is the worth of a protocol that can achieve a little bit less latency at the cost of reliability?). Personally I think that discussion is a red herring, as it’s not our job to say why low latency is or isn’t useful. The point is that FTL has less latency than other options, and it’s up to the service provider (and user) to determine whether that feature is useful and worth the reliability trade-off. If they want to yeet packets into cyberspace with abandon, that is their prerogative.

As a side note, some of my OBS colleagues have suggested that the goal of ultra-low latency above all has not been sufficiently motivated (That is, what is the meaningful, practical difference between a unidirectional stream with 750ms latency vs. 250ms latency? What is the worth of a protocol that can achieve a little bit less latency at the cost of reliability?). Personally I think that discussion is a red herring, as it’s not our job to say why low latency is or isn’t useful. The point is that FTL has less latency than other options, and it’s up to the service provider (and user) to determine whether that feature is useful and worth the reliability trade-off. If they want to yeet packets into cyberspace with abandon, that is their prerogative.

I feel that I can speak on this because I can see where you guys are coming from. When I launched Lightspeed I though it was cool and I made it primarily to learn but I also thought it would be cool to have something like this out there that someone can self host (to me its like a 2021 minecraft server for the next generation of tech kids). Anyhow, I have been getting TONS of messages saying that people have been dying for something like this. A lot seem to be coming from the broadcasting industry (see here). I have also seen that someone is considering this for broadcasting a wedding so it really seems like there is a demand for ultra-low latency applications. Lightspeed is by no means a large company (or ever will be) but moreso of a niche application and it would be really disappointing to see FTL support go away. I dont plan to ever submit lightspeed for entry into services.json since we deal with custom servers exclusively but I would really like to see FTL support continue and I am personally willing to help in whatever way OBS needs to make that happen! Thank you again for this discussion and I apologize if I have come across as confrontational in previous posts.

The concern here is that a protocol that doesn’t have reliability as a priority translates into more people flooding our support systems wondering why their stream is dying. If the protocol is only intended to work on solid internet connections, then what are users on poor connections supposed to do, and how are they supposed to know if their internet connection is solid enough? Are they SOL? This is something that should be very clearly communicated to the user on the part of both the service provider and the encoder.

I have to push back on the "protocol is only intended to work on solid internet connections" bit. I've streamed both on mixer and twitch with my horrible 30Mbps down/3Mbps up connection and with the right configuration I had better results with FTL than I ever had with RTMP, with 1/5th the delay and much better video quality. It's possible with the right setup I could've had good results with RTMP as well, but I don't think it's fair to say that FTL only works well with good internet

SRT has large and growing support in the professional video broadcast industry in both hardware and software encoders/decoders.

SRT is not currently a good choice for a transport between a server and clients, but I believe is a good option for OBS to server transports.

Currently there are some deficiencies in using SRT with OBS:

• The configuration of the latency and the max bandwidth need to be specified in the query parameters
• It isn't intuitive for users as to what latency setting they should set
• The OBS speedtest won't work

SRT is a basic messaging protocol, with a convention of sending MPEG-TS over it, but it can be used to send anything. It would be easy to find or create a standard for running speedtests and latency tests (or establishing a stream and reading the latency stats from the SRT socket itself) and using that to provide good defaults for latency.

The max bandwidth setting can be derived from the bitrate specified on the encoder for the audio and video streams.

With this ability to measure appropriate SRT latency settings, it would provide fairly low latency (200-300ms in the US if there are POPs on both coasts).

The problem is that the SRT media packets and the RTP one differs and that appears to extend to how frame information is encoded. That means you'd have to convert one to the other at a CPU and latency hit. I don't know how different the two are, but most off the shelf implementations like FFMPEG usually require a full KF interval to transcode across protocols (which was our experience in converting FTL->RTMP). We're using RTP because that's what WebRTC uses to avoid a transcoding, muxing or demuxing step.

I don't deny SRT would work great for low latency video ingest, but in this case, it has to stay low latency to the last mile. It also doesn't define a specific signaling layer (neither does RTP, but FTL provides that role).

SRT header is 16 bytes, RTP header is (at minimum) 12 bytes - more if extension is used..

I've never dealt with video over RTP before I work in call centres so only ever voice and I've only ever seen 12 bytes..

So with the RTP header removed, how large is your packet? Can you add 16 bytes to it and still fit into the MTU?

Edit: or do you need to keep the RTP header? If so, then you would need to accomodate the extra 16 bytes

Hi @nazar-pc, and thanks for posting.

I noticed that you work with Restream.io, which had a history of supporting FTL until Mixer died. Can you comment on your experience with the FTL protocol at Restream, or is that more of a question for @Dead133?

We have similar impression to OBS feedback above.

It is great when it works, but with flaky connectivity users were disappointed with quality and there wasn't much our support team could help them with except decreasing bitrate or using RTMP. And in many cases switching to RTMP resulted in 1-2 seconds latency on Mixer that I don't remember being a deal-breaker for most users, Mixer worked really well even with RTMP.

Thanks for the feedback.

In your post above, you suggest that WebRTC might be a better alternative to FTL for the low latency use case. Despite that, looking at the merits of FTL on its own, do you think it ought to be deprecated, or do you think support for the protocol should remain present in OBS? Why or why not? (Note that I am not asking if you like the protocol, I am asking if you think its merits are deserving of continued support in OBS)

I imagine that might be a complicated question for someone who works at Restream, since obviously Restream is motivated to support whatever protocols are available from the services they support. So if Restream end up supporting a service like Glimesh that uses FTL, then Restream would also likely want users to have access to FTL in their encoder of choice.

If you don't mind me asking a relatively simplistic high-level question: What kind of latency should one expect when leveraging a WebRTC-based streaming stack? MFC for instance -- what kind of latency do those streamers experience?

dodgepong on Jan 8, 2021

I know Big Buck Bunny when I see it

850ms is admittedly higher than I expected, especially in context of FTL's claims* of sub-500ms latency. Do you know where that latency tends to come from? Also, on a broader scale, is 850ms of latency typical of a WebRTC stream with this sort of use case?

*It's been quite a while since I've used FTL myself to see how well those claims currently hold up, though I'm sure the FTL folks would be happy to share their results. I don't doubt them, but also haven't seen any actual test results recently.

The key strength issue could be resolved by going to [...] RSA keys [...], but that would delay call setup by several additional seconds.

This is fine (and not actually that long, either, it's in low three digit millisecond territory), since this is just for establishing a transport connection. You don't wait and queue video while this happens. You start sending from real-time as soon as you've got your symmetric key negotiated.

Nothing in WebRTC spec prevents usage of hardware encoders.

Nothing in WebRTC spec prevents usage of hardware encoders.

i'm aware; that's not my point. Regarding the current implementation of webrtc (so obs-studio-webrtc of Dr Alex) or the future implementation in obs, imo it'd be a very good thing to be able to leverage our encoders. If I read well the code of Dr Alex fork, the webrtc outputs use raw frames; it'd be convenient if we could pass them our encoded data.

the risk of using the same approach as the korean one, is to cut the RTP feedback loop, losing NACK, FEC, and all the other adaptability and resilience mechanisms while doing it. It would be better to inject the encoder in the media engine.

korean ?

• libwebrtc design allow for injectable Encoder (res dec.) factory. So each application can provide their own. It would be almost trivial to reuse OBS provided encodes in libwebrtc. Actually, the MFC fork did just that and leverages OBS' x264 instead of the libwebrtc provided openH264.

ah very cool

• in our current discussion with cafeine, reusing OBS hardware acceleration is on the roadmap,

excellent

• we also proposed to the OBS team already to simply reuse the libwebrtc implementation they already ship in CEF. One could argue that If it s good enough for the browser source (obs-ninja ...), it should be good enough for the main encoders as well.

i was wondering if we could leverage it; that's an interesting idea.

I am happy to have in depth discussion about any of your requirements anytime you guys want.
I understand OBS is your baby, and I am the one who need to make the effort to address your concerns. I'm happy to keep a fork in sync while you re not confortable with it.
We brought the idea behind WHIP to the IETF exactly for this: so that all stakeholder would have an opportunity to share their needs, their opinion and participate in an open and free environement. I would love to see the OBS team send a representative to the meetings and share with the group their feedback.

By the way @agouaillard-cosmo you can click in the "Write a reply" box beneath a thread to reply to just that post if you like, rather than make a new thread in the discussion at the bottom of the page. Might help keep the conversation more organized. (Discussions are a new feature of Github that we are still testing out.)

I apologize, i m new to this and on mobile the visual difference is less obvious than on desktop. I will be carefull.

For client to server use cases (like with OBS) you can avoid sending any IP addresses because server is reachable directly, so nothing leaks beyond IP address from which you do the request anyway.

Also there is mDNS even when browser is used in a more traditional way.
Also doing WebRTC over VPN is not a good idea

Let's imaging you were leaking your IP in OBS (whatever the protocol). It would only be "leaked" to the ingest node of the platform you are streaming to, which is very likely to know who you are already through authentication. RTMP, FTL, and many other protocol do not make any attempt at hiding the origin IP of the stream.

Content verification, age verification, ... there are many reasons why anonymous streaming to a platform is at best a bad idea and at at most illegal from the platform point of view. If you are trying to hide your IP to the platform you are streaming to, you might be in breach of their EULA.

Now, on the other side, let's imaging that the last mile delivery protocol used by the platform was leaking IP. It would only leak to the viewer the IP of the egress node of the platform, not of the original source of the stream. As a matter of fact, many CDNs use webrtc's Datachannel based solutions to smooth last mile delivery (peer5, ...)

Ok so if i get the gist of it correctly the only places that would technically get the IP of the streamer is the OBS client and the ingest server no matter what is happening on the ingest server or the OBS client and in terms of streaming that would be acceptable as that is 100% necessary for an actual stream to be live.

I think one of the major points for keeping FTL support for now, is that it is currently the only free open-source solution for getting low-latency content from OBS to an in-browser player, as far as I am aware. That is Project Lightspeed.

While I can get behind the pros and cons of FTL vs WebRTC on paper, it is a moot discussion if users don't actually have the option to choose one over the other in practice. The current situation is that if FTL support is removed from OBS at this point, that essentially removes the option of streaming low-latency content to a browser without migrating to a paid subscription service; a major hurdle for most people who just do this as a hobby in their free time.

Thanks for the reply. Discussions around improving OBS's SRT support would probably be better suited to an RFC so that we can keep this thread on the topic of FTL.

@J-Rogmann thanks for the offer of a webinar. I'd be interested. I can be reached on obs discord.
As to the srt params for srt output from obs, it's just a UI matter. I've thought of improving the ux , indeed passing them with the url is not very convenient. It's in my todo list.
We'd surely prefer a native implementation of srt. I've actually started a rewrite. But the current output (which I also wrote) seems to work fine so I don't have much incentive tbh.
Note that we ingest srt with the Media Source which relies on ffmpeg libs for demuxing and decoding. We already ingest from larix broadcaster. There's no plan to change srt ingest afaik.
As Ben suggested an rfc for srt would be better suited though. Or less formally it could be a separate GH discussion since we're straying from ftl.

Hi @dodgepong Is there any timeline about WebRTC output support?

Q3 2022 is our new target for an MVP of WebRTC output.

There will be a grace period, yes. Most development related to WebRTC at the moment is being handled by @DDRBoxman. Our updated timeline for a minimum of WHIP-based WebRTC support is looking closer to Q3 2022.