Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg merges WebRTC support

git.ffmpeg.org

Post reply on HN
Print view View original

201–204 of 204 posts

Re: FFmpeg merges WebRTC support

#201

Post by raymond_goo »

Sesse__ wrote: post #156
darkvertex wrote: post #131

Earlier quoted context omitted.

WebRTC excels at sub-second latency peer to peer, so you can do near-realtime video, so anywhere that is useful. Say you wanted to do a virtual portal installation connecting views from two different cities with live audio, you could have ffmpeg feed off a professional cinema or DSLR camera device with a clean audio feed and stream that over WebRTC into a webpage-based live viewer. Or say you wanna do a webpage that…

The irony is that you don't _actually_ need WebRTC to get subsecond latency; you can fairly reliably get ~100–200ms (plus network latency) with a completely normal TCP stream.[1] But since browsers have effectively standardized on HLS, whose design is completely antithetical to low-latency (you _can_ do low-latency HLS, but only with heroic efforts), low-latency streaming video has never really been part of their bre…

Explanation: HTTP Live Streaming slices the bitstream into “segments” (traditionally 6–10 s each) and only starts playing after it has downloaded several of them. Out of the box that means 30–60 s of startup and live-edge latency—fine for linear TV, terrible for anything interactive.

Apple’s LL-HLS spec shrinks those segments into “partial segments” and uses CMAF to let the player start decoding while a chunk is still arriving. With careful encoder tuning, HTTP/2/3 push, CDN support, and a compatible player you can reach 2–5 s, sometimes a bit lower—but every link in the chain has to cooperate, so implementations are still called “heroic” for a reason.

Safari plays HLS natively and on other browsers you can bolt on hls.js via Media Source Extensions. DASH, RTMP, SRT, etc. all need extra code or plugins, so HLS became the “safe default” for on-demand and broadcast-style streaming even though it isn’t low-latency friendly.

Re: FFmpeg merges WebRTC support

#202

Post by rietta »

sahilagarwal wrote: post #199
rietta wrote: post #168

Earlier quoted context omitted.

I never found bash scripting disagreeable. I have thousands of scripts for both work and my everyday computer usage. I keep a ~/bin folder in my path where I place useful scripts that I have written for my own use. One thing that keeps me using bash for this purpose over Python or Ruby (which I use for serious programming) is that I can take a command line invocation that I manually constructed and tested and put it…

Me too! I am a data engineer so whenever I have pipeline jobs running, I have a script that monitors them. When the jobs finish, an audio plays stating the job has finished and its status. Thats just one convenient script out of dozens. Makes life much more easier when I can play video games or read books without having to check status every 20 mins. Though I haven't created as many as you have. Would you mind sharin…

Thousands is probably hyperbole, but there are many, many!

One that I find regular use for when copy+paste does not work because I am either connected to a terminal emulation, vm, or something of the like is typeitforme. It takes the contents of a text file and sends them through the keyboard buffer after a few second delay (that allows me time to switch focus to the window I want the typing done).

I currently have it as a entry in my ~/.bash_aliasas file.

alias typeitforme='sleep 3 && xdotool type --file '

This works in stock Ubuntu Linux. You can check out the xdotool documentation for ideas how to refine it to do more.

Re: FFmpeg merges WebRTC support

#203

Post by globie »

therealpygon wrote: post #176
globie wrote: post #50

Earlier quoted context omitted.

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

So you searched “WebRTC”, and then took the extraordinary step of… not actually reading any of them while simultaneous using them as supposed points? Quick question since you seem to know a lot about these CVEs and have spent a fair amount of time understanding them: how many of those were browser implementation issue? This is like searching CVE for “node” and then claiming Node is terrible because some node packages…

When writing this inflammatory post, you seem to have forgot the bigger picture of the thread you are flaming.

We're discussing whether it's right to take a second look from a security standpoint when a software implements WebRTC. In this case, it's nuanced, and the implementation in FFmpeg is very different than the more complete implementations you find in browsers. And when browsers have implemented WebRTC, many vulnerabilities have followed.

So the double-take is justified here, even if only in principle. No one is saying WebRTC is insecure, or FFmpeg, or node, or Linux..........

I did a cursory read of each CVE. Wherever you got the idea I did not, you must have forgot to include it in your post. Just now, I picked one from random. It reports "Multiple WebRTC threads could have claimed a newly connected audio input leading to use-after-free."

Does that exactly qualify as an "implementation bug"? I don't know, and I don't care, because how you taxonomize a CVE has nothing to do with whether it's a vulnerability that was introduced when implementing WebRTC. And it is.

Re: FFmpeg merges WebRTC support

#204

Post by therealpygon »

globie wrote: post #203
therealpygon wrote: post #176

Earlier quoted context omitted.

So you searched “WebRTC”, and then took the extraordinary step of… not actually reading any of them while simultaneous using them as supposed points? Quick question since you seem to know a lot about these CVEs and have spent a fair amount of time understanding them: how many of those were browser implementation issue? This is like searching CVE for “node” and then claiming Node is terrible because some node packages…

When writing this inflammatory post, you seem to have forgot the bigger picture of the thread you are flaming. We're discussing whether it's right to take a second look from a security standpoint when a software implements WebRTC. In this case, it's nuanced, and the implementation in FFmpeg is very different than the more complete implementations you find in browsers. And when browsers have implemented WebRTC, many v…

I forgot nothing, but you seemed to forget whose comment you were attempting to bolster. I “flamed” the useless injection of CVEs that attempt to legitimize someone’s point about the insecurity of a protocol, when that tiny amount of CVEs for a technology the world uses quite heavily almost unanimously point to poor implementation-specific issues, none of which inform the security or risk of the protocol itself, adding useless data that doesn’t further a conversation on security.

“No one is saying webrtc is insecure”? That is literally what the comment was doing, which you attempted to legitimize by listing browser-specific CVEs.

Someone pointed to a car fire and said gasoline caused the fire, and you posted pictures of car fires. There is a reason a Fire Investigator (like a security researcher would) considers the difference between what started a fire and an accellerant. WebRTC was not the cause of these vulnerabilities like you are trying to imply and like the opinion you attempted to legitimize.

“I don’t care” — clearly, if you couldn’t take the time to understand the difference, I’m not surprised.

Post reply on HN