Live data from Hacker News

FFmpeg merges WebRTC support

git.ffmpeg.org

151–160 of 204 posts

Re: FFmpeg merges WebRTC support

#151
Gajim, the XMPP client, has been awaiting this for a long time! Their Audio/Video calling features fell into deprecation, and they've been patiently waiting for FFmpeg to make it much easier for them to add Audio/Video calling features back again.

Re: FFmpeg merges WebRTC support

#152

Can someone ELI5 what this means? i've been using ffmpeg for over a decade.

WebRTC is very, very hard to code for. But if FFmpeg abstracts that complexity away, then WebRTC becomes much easier to add to a software project wishing to benfit from that which WebRTC offers.

Re: FFmpeg merges WebRTC support

#153
post #132
post #119

Earlier quoted context omitted.

Not sure I follow your maths there. If we assumed an average of 6Mb per stream that's 3000 streams, practically speaking a little lower. It's all relative I guess but it's not that high.

Multicast enters the room

Does multicast actually work from a home network to another set of homes over the internet? I thought this traffic would just get dropped by one of the hops along the way if you tried it.

https://networkengineering.stackexchange.com/questions/47994...

Re: FFmpeg merges WebRTC support

#154

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

ffmpeg is high performance code dealing with esoteric codecs and binary formats in C, so don't sweat it.

Re: FFmpeg merges WebRTC support

#155
post #88

Earlier quoted context omitted.

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?

Yes we are :) When OBS merges the PR [0] things are going to get very interesting. Before you needed to run expensive transcoding jobs to be able to support heterogenous clients. Once we get Simulcast the only cost will be bandwidth. With Hetzner I am paying $1 a TB. With AV1 or H265 + Simulcast I am getting 4K for hundreds of users on just a single server. We will have some growing pains, but I am not giving up unti…

Thanks to a post on here a few months ago about Cloudflare R2, I finally felt motivated enough to work on a video platform idea I have. I still don’t understand ffmpeg but my transcoder works!

Now I see this news?! Perfect timing. (:

Re: FFmpeg merges WebRTC support

#156

Earlier quoted context omitted.

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.)

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 bread and butter. So instead, we abuse a _much_ more complicated protocol (WebRTC), because that happens to hit a path that was meant for low-latency videoconferencing.

(I did sub-100ms glass-to-glass streaming with VLC back in the day, so it is eminently possible. But the browser is in your way.)

[1] Much less than that is going to be tricky under non-perfect network conditions, because once you start having any sort of packet drop, you want to go from TCP's retransmission regime and instead start dropping packets, take the artifacts for a little while, and then go on.

Re: FFmpeg merges WebRTC support

#158
post #60

Earlier quoted context omitted.

LLMs really know how to use it incredibly well. You can ask them to do just about any video related task and they can give you an ffmpeg one liner to do it.

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.

"Have not tested its answer yet but on its face it looks legit."

That's LLMs for you

Re: FFmpeg merges WebRTC support

#160

Earlier quoted context omitted.

A twitch 720p stream is only 4 Mbps. 1080p? 6-8 Mbps So if you've got ~18 Gbps of upload bandwidth you're ready for 10,000-20,000 viewers.

With how ubiquitous gigabit symmetric is becoming, I wonder if you could even do P2P nowadays. Assuming a single gigabit symmetric connection could dedicate at most 100mb of upload bandwidth, you'd need one such viewer per each 25 viewers with a worse connection. This feels achievable. You'd have 1 server that broadcasts to at most 10K tier-1 viewers. Tier 2 viewers get 3 tier1 ips for failover, and pre-negotiate a c…

> With how ubiquitous gigabit symmetric is becoming, I wonder if you could even do P2P nowadays.

You don't even need gigabit connections to make p2p work: a video stream is usually between 1-10mbps, with which you can do p2p even with a regular connection.

(I used to work for a start-up doing p2p streaming using WebRTC in the browser, we got up to 90% efficiency on live streaming back in 2015, and 80% for VoD).

I'm still very confused that this technology hasn't become mainstream (there are privacy concerns, but that doesn't usually stop the tech market…).

Post reply on HN