FFmpeg merges WebRTC support • Hacker News Board

Re: FFmpeg merges WebRTC support

#41

Post by lpln3452 » Wed, Jun 04, 2025, 5:23 PM UTC

gruez wrote: post #38

globie wrote: post #29

Earlier quoted context omitted.

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 po…

>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. Like what? I did a quick search and most seem to be stuff like ip leaks and fingerprinting, which isn't relevant in ffmpeg.

This is exactly the question I have.

While WebRTC causes fingerprinting risks in browsers, isn’t that unrelated to running ffmpeg?

Re: FFmpeg merges WebRTC support

#42

Post by bastawhiz » Wed, Jun 04, 2025, 5:23 PM UTC

MrThoughtful wrote: post #22

bastawhiz wrote: post #12

Earlier quoted context omitted.

If you visit the ffmpeg.wasm documentation, the first example on the Usage page does almost exactly this: https://ffmpegwasm.netlify.app/docs/getting-started/usage It transcodes a webm file to MP4, but making it speed up the video is trivial: just add arguments to `ffmpeg.exec()`. Your lack of success in this task is trusting an LLM to know about cutting-edge libraries and how to use them, not a lack of progress in t…

The problem is that they don't provide the full code that can run in the browser. I have not managed to get the function they show in the first example to run in the browser.

That's just wrong. The example is live: you can run it right there on the page. If the code isn't working when you write it, you're probably importing something incorrectly (or you're not running it in an environment with React, which is where the `use*` functions come from). You can even click on the source of the log lines when the example is running (on the right edge of the Chrome console) to jump into the hot-loaded code and see the exact code that's running it.

Re: FFmpeg merges WebRTC support

#43

Post by autoexec » Wed, Jun 04, 2025, 5:27 PM UTC

Sean-Der wrote: post #23

autoexec wrote: post #11

Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. WebRTC security flaws are responsible for a lot of compromises. It's one of the first things I disable after installing a browser

What security flaws? This implementation is very small. I feel 100% confident we are giving users the best thing possible.

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.

Re: FFmpeg merges WebRTC support

#44

Post by xxpor » Wed, Jun 04, 2025, 5:29 PM UTC

mschuster91 wrote: post #39

autoexec wrote: post #11

Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. WebRTC security flaws are responsible for a lot of compromises. It's one of the first things I disable after installing a browser

> Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. ffmpeg has had so many issues in the past [1], it's best practice anyway to keep it well contained when dealing with user input. Create a docker image with nothing but ffmpeg and its dependencies installed and do a "docker run" for every transcode job you got. Or maybe add ClamAV, OpenOffice and ImageMagick in the image as well if you also…

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

Re: FFmpeg merges WebRTC support

#45

Post by baggy_trough » Wed, Jun 04, 2025, 5:31 PM UTC

xxpor wrote: post #44

mschuster91 wrote: post #39

Earlier quoted context omitted.

> Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. ffmpeg has had so many issues in the past [1], it's best practice anyway to keep it well contained when dealing with user input. Create a docker image with nothing but ffmpeg and its dependencies installed and do a "docker run" for every transcode job you got. Or maybe add ClamAV, OpenOffice and ImageMagick in the image as well if you also…

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

What is?

Re: FFmpeg merges WebRTC support

#46

Post by bastawhiz » Wed, Jun 04, 2025, 5:32 PM UTC

minimaxir wrote: post #28

jsheard wrote: post #26

Earlier quoted context omitted.

I'm sorry, but if you give up on something you would "love to use" just because LLMs are unable to oneshot it then you might be a bit too dependent on AI.

Time is a finite resource, and there's an opportunity cost. If an easy PoC for a complex project can't be created using AI and it would take hours/days to create a PoC organically that may not even be useful, it's better project management to just do something else entirely if it's not part of a critical path.

I can't disagree with this take more vehemently. This isn't an "easy PoC". This is "copy and paste it from the docs"-level effort:

https://ffmpegwasm.netlify.app/docs/getting-started/usage/

If you can't be arsed to google the library and read the Usage page and run the _one command_ on the Installation page to come up with a working example (or: tweak the single line of the sample code in the live editor in the docs to do what you want it to do), how do you expect to do anything beyond "an easy PoC"? At what point does your inability/unwillingness to do single-digit-minutes of effort to explore an idea really just mean you aren't the right person for the job? Hell, even just pasting the code sample into the LLM and asking it to change it for you would get you to the right answer.

Re: FFmpeg merges WebRTC support

#47

Post by Sean-Der » Wed, Jun 04, 2025, 5:34 PM UTC

autoexec wrote: post #43

Sean-Der wrote: post #23

Earlier quoted context omitted.

What security flaws? This implementation is very small. I feel 100% confident we are giving users the best thing possible.

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 mu…

Those are issues in multiple implementations though! Lots of them are just issues in Chromium around Javascript (webrtc code wasn't even started yet)

That would be like saying saying 'webrtc is more secure then http' by posting this https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=http

IP Leaking has been fixed since 2019[0]. ICE/P2P is still a huge attack surface though. I have seen lots of other tricks being tried.

[0] https://www.youtube.com/watch?v=SqcW8kJAMJg

Re: FFmpeg merges WebRTC support

#48

Post by MrThoughtful » Wed, Jun 04, 2025, 5:36 PM UTC

bastawhiz wrote: post #42

MrThoughtful wrote: post #22

Earlier quoted context omitted.

The problem is that they don't provide the full code that can run in the browser. I have not managed to get the function they show in the first example to run in the browser.

That's just wrong. The example is live: you can run it right there on the page. If the code isn't working when you write it, you're probably importing something incorrectly (or you're not running it in an environment with React, which is where the `use*` functions come from). You can even click on the source of the log lines when the example is running (on the right edge of the Chrome console) to jump into the hot-lo…

I think there is some kind of misunderstanding here.

You say "an environment with React". My environment is the browser.

I don't know how one is supposed to run that nameless function on that page. What I am looking for is a simple, complete example in HTML that can run standalone when opened in the browser. Without any server side processing involved.

Re: FFmpeg merges WebRTC support

#49

Post by MrThoughtful » Wed, Jun 04, 2025, 5:39 PM UTC

bastawhiz wrote: post #46

minimaxir wrote: post #28

Earlier quoted context omitted.

Time is a finite resource, and there's an opportunity cost. If an easy PoC for a complex project can't be created using AI and it would take hours/days to create a PoC organically that may not even be useful, it's better project management to just do something else entirely if it's not part of a critical path.

I can't disagree with this take more vehemently. This isn't an "easy PoC". This is "copy and paste it from the docs"-level effort: https://ffmpegwasm.netlify.app/docs/getting-started/usage/ If you can't be arsed to google the library and read the Usage page and run the _one command_ on the Installation page to come up with a working example (or: tweak the single line of the sample code in the live editor in the docs…

If there is a "copy and paste" way to get that to run in the browser, can you copy and paste it to a jsfiddle and post the link to the fiddle here?

Re: FFmpeg merges WebRTC support

#50

Post by globie » Wed, Jun 04, 2025, 5:39 PM UTC

gruez wrote: post #38

globie wrote: post #29

Earlier quoted context omitted.

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 po…

>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. Like what? I did a quick search and most seem to be stuff like ip leaks and fingerprinting, which isn't relevant in ffmpeg.

Here's a (very) small sample gathered from a search for "webrtc" on cve.org and picking high-severity CVEs affecting browsers:

* CVE-2015-1260

* CVE-2022-4924

* CVE-2023-7010

* CVE-2023-7024

* CVE-2024-3170

* CVE-2024-4764

* CVE-2024-5493

* CVE-2024-10488

Of course, I agree that it's not relevant to ffmpeg. But seeing "WebRTC" triggers the same part of the brain that looks out for unescaped SQL statements. Good opportunity to point out the difference in this implementation.