FFmpeg merges WebRTC support

Thank you :)

When are you coming back to the WebRTC space, lots more cool stuff you could b doing :) I really loved [0] it's so cool that a user can access a server behind a firewall/NAT without setting up a VPN or having SSH constantly listening.

[0] https://github.com/maxmcd/webtty

What sort of infrastructure do you need for scaling WebRTC multicast?

Are we entering an era where you don't need Amazon's budget to host something like Twitch?

[1]:

  gst-launch-1.0 playbin3 uri="gstwebrtc://localhost:8443?peer-id=<webrtcsink-peer-id>"

[1] https://gstreamer.freedesktop.org/documentation/rswebrtc/web...

That's impossible, VLC supports everything. If VLC doesn't support it, it doesn't exist.

I'd guess VLC will get support for it soon now that ffmpeg supports it.

Maybe I'm wrong but in this case, couldn't you create your own middleware server that could consume the Weber stream feed and then stream out as a regular vlc consumable feed? I'm guessing there will be some transcoding on the fly but that should be trivial..

Should ffplay support it if ffmpeg added support for it in general?

Absolutely! Some people have modified libwebrtc to do this today, but it wasn't upstreamed.

ICE (protocol for networking) supports this today. It just needs to get into the software.

I've also been trying (and mostly failing) to build such a setup over the last few weeks. What are you thinking in terms of the overall building blocks to get this to work?

I've been struggling to get a proper low-latency screen+audio recording going (on macos) and streaming that over WebRTC. Either the audio gets de-sync, or the streaming latency is too high.

WebRTC actual's complezity is very high. WHIP seems to be the standard path for most apps to integrate, but it does rely on an exterior service to actually do anything.

Hypothetically ffmpeg could be an ICE server for peer-connecting, do SDP for stream negotiation possibly with a side of WHEP (egress protocol) as well, could do SCTP for actual stream transfer. Such that it could sort of act as a standalone peer, rather than offload that work to a gateway service.

Worth noting that gstreamer & OBS also are WHIP based, rely on an external gateway for their WebRTC support. There's not one clear way to do a bunch of the WebRTC layer cake (albeit WHEP is fairly popular I think at this point?), so WHIP is a good way to support sending videos, without having to make a bunch of other decisions that may or may not jive with how someone wants to implement WebRTC in their system; those decisions are all in the WHIP gateway. It may be better to decouple, not try to do it all, which would require specific opinionative approaches.

I still don't understand any practical use cases. Can you give some examples? (I'm not being obtuse here I'm genuinely curious what this can enable now.)

So it's only the receiving part of WebRTC, now being able to use WHIP in order to ask a server for a stream?

Are there any popular/well-known WebRTC senders (or servers)? I'm pretty sure this is not for YouTube etc., right? So what would I watch through WebRTC?

Wow, you are not wrong. I just asked Gemini "how can I use ffmpeg to apply a lower third image to a video?" and it gave a very detailed explanation of using an overlay filter. Have not tested its answer yet but on its face it looks legit.

It can't be a Hacker News thread without at least one mention of LLMs, even if the thread is completely unrelated.

There's plugins for most of the modern stuff at https://pidgin.im/plugins

I'm quite happy with Beeper, it still has some bugs and isn't open source, but it saves me from remembering where different contacts live.

most recently: https://cyberpress.org/critical-libvpx-vulnerability-in-fire..., but you can have your pick from any year https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webrtc

You're right that biggest reason people usually recommend disabling it is to prevent your IP from leaking when using a VPN https://www.techradar.com/vpn/webrtc-leaks but not having to worry about RCE or DoS is a nice bonus

I'm not sure how much will this impact ffmpeg users. Considering that WebRTC has a bad track record in terms of security though, I do worry a little that its inclusion in one more place on our systems could increase attack surface.

I assume autoexec is referring to the plethora of WebRTC vulnerabilities which have affected browsers, messengers, and any other software which implements WebRTC for client use. Its full implementation is seemingly difficult to get right.

Of course, you're right that this implementation is very small. It's very different than a typical client implementation, I don't share the same concerns. It's also only the WHIP portion of WebRTC, and anyone processing user input through ffmpeg is hopefully compiling a version enabling only the features they use, or at least "--disable-muxer=whip" and others at configure time. Or, you know, you could specify everything explicitly at runtime so ffmpeg won't load features based on variable user input.

Leaking local IP addresses?

Yes, pretty much every bit of ffmpeg can be enabled or disabled when compiling.

if you're worried about arbitrary code exec from an ffmpeg vuln, docker is not a sufficient security boundary.

FWIW I also can’t pass the Anubis pass on iOS Safari, even though I can on any other site. I see the Anubis success screen for a moment before it switches to the “invalid response” screen.

edit: Trying again a few minutes later worked

I got stuck on access denied. Canada IPv4. Safari on iOS.