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

111–120 of 204 posts

Re: FFmpeg merges WebRTC support

#111

Post by ninkendo »

okdood64 wrote: post #74
bigfishrunning wrote: post #5

Earlier quoted context omitted.

It means that programs that use the FFmpeg libraries (looks like libavformat specifically) can consume webrtc streams

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

My guess is you could more easily build an open source client for whatever video conferencing system you want that uses WebRTC (most services like teams, discord, zoom, etc seem to use WebRTC as a fallback for browsers, if not using it wholesale for everything, although there may be countermeasures to block unofficial clients.)

Re: FFmpeg merges WebRTC support

#112

Post by bryancoxwell »

Sean-Der wrote: post #90
echelon wrote: 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…

I just want to say I am loving your enthusiasm

Re: FFmpeg merges WebRTC support

#113

Post by xxpor »

mschuster91 wrote: post #87
ta1243 wrote: post #76

Earlier quoted context omitted.

It's layers. Docker is better than nothing, but a VM is better still, and even better is docker on a dedicated VM on dedicated hardware on a dedicated network segment.

That's sacrificing an awful lot of latency cost for each transcode job though.

Firecracker says it can start a VM in 125 ms, for most transcode jobs that seems like it'd be a trivial cost.

Re: FFmpeg merges WebRTC support

#114

Post by Sean-Der »

rmoriz wrote: post #108
Sean-Der wrote: post #20

I am so incredibly excited for WebRTC broadcasting. I wrote up some reasons in the Broadcast Box[0] README and the OBS PR [1] Now that GStreamer, OBS and FFmpeg all have WHIP support we finally have a ubiquitous protocol for video broadcasting for all platforms (Mobile, Web, Embedded, Broadcasting Software etc...) I have been working on Open Source + WebRTC Broadcasting for years now. This is a huge milestone :) [0]…

Any plans to add multipath/failover-bonding support? e.g. mobile streaming unit connected with several 5G modems. Some people use a modified SRT to send H.265 over multiple links.

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.

Re: FFmpeg merges WebRTC support

#115

Post by Sean-Der »

dark-star wrote: post #93
bigfishrunning wrote: post #5

Earlier quoted context omitted.

It means that programs that use the FFmpeg libraries (looks like libavformat specifically) can consume webrtc streams

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?

Twitch supports WHIP today. Lots of WebRTC services support WHIP (Cloudflare, LiveKit, Dolby...)

webrtcHacks has an article on it[0] kind of old, but captures the spirit of it!

[0] https://webrtchacks.com/tag/simulcast/

Re: FFmpeg merges WebRTC support

#117

Post by spartanatreyu »

quantadev wrote: post #116

Public Service Announcement: There's a reddit topic for WebRTC, that doesn't get enough action imo! Get in there ya'll... https://www.reddit.com/r/WebRTC

No.

Reddit lost their own community's trust when the CEO ejected the community's moderators.

Information posted there is now far less likely to be qualitative compared to other places, so what's the point of going there?

Re: FFmpeg merges WebRTC support

#118

Post by miki123211 »

michaelt wrote: post #107
matt-p wrote: post #103

Earlier quoted context omitted.

I have found it's hard to get past ~18Gbps on commodity servers and ~90Gbps on high spec, carefully specced servers. I presume you find the same?

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 connection with them, e.g. through STUn, to get sub-second failovers in case their primary source quits the stream. A central control plane load balances these.

With something like 15s of buffer (acceptable for a gaming stream, not so much for sports, where your neighbors might be watching on satellite and cheer), this feels achievable.

Re: FFmpeg merges WebRTC support

#119

Post by matt-p »

michaelt wrote: post #107
matt-p wrote: post #103

Earlier quoted context omitted.

I have found it's hard to get past ~18Gbps on commodity servers and ~90Gbps on high spec, carefully specced servers. I presume you find the same?

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.

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.

Re: FFmpeg merges WebRTC support

#120

Post by matt-p »

miki123211 wrote: post #118
michaelt wrote: post #107

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…

In theory I think you're right, but you do need a really smart control plane. Just because a connection is fast doesn't mean it's not metered (let's say fast 5G, starlink, rural fiber) and so on.

Are all of the issues P2P brings really worth it?

I'd say this definitely opens up streaming from your desktop with 1 CPU core handling a SFU for say 100 viewers = 500Mb or from a $5/month VPS if you've not got the capacity at home. That's pretty awesome, for most people no need to use P2P.

Post reply on HN