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

141–150 of 204 posts

Re: FFmpeg merges WebRTC support

#141

Post by shmerl »

WhyNotHugo wrote: post #61
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]…

Are there any video players which can play a webrtc stream? Last I checked, VLC and other popular tools still don’t support it.

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

Re: FFmpeg merges WebRTC support

#142

Post by esseph »

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…

It's not nearly as "ubiquitous" as you may think

Re: FFmpeg merges WebRTC support

#143

Post by esseph »

ablob wrote: post #132
matt-p wrote: 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

Finally

Re: FFmpeg merges WebRTC support

#145

Post by athrun »

1oooqooq wrote: post #78
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]…

i was using vnc for remote dosbox gaming on the phone. now i can sink infinite amount of time trying to do a input handler webapp and using this+obs instead! thanks!

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.

Re: FFmpeg merges WebRTC support

#146

Post by fc417fc802 »

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.

> stuff like ip leaks and fingerprinting, which isn't relevant in ffmpeg.

If ffmpeg implements WHEP in the future then I'd certainly be concerned about both of those things when viewing a stream. Probably less so for serving a stream up, particularly via a gateway (the current implementation IIUC).

Re: FFmpeg merges WebRTC support

#147

Post by fc417fc802 »

jpk wrote: post #134
Mofpofjis wrote: post #98

A commit that was "co-authored-by" 6+ people and has three thousand lines of code: this is a total wreck of a development workflow. This feature should have been implemented with a series of about 20 patches. Awful.

I mean, it probably was a branch that several people contributed commits to that was squashed prior to merge into mainline. Folks sometimes have thoughts about whether there's value in squashing or not, but it's a pretty common and sensible workflow.

> common and sensible

Perhaps "common and technically works" would be a better way to put that (similarly for rebase). I suspect people would stop squashing if git gained the ability to tag groups of commits with topics in either a nested or overlapping manner.

Re: FFmpeg merges WebRTC support

#149

Post by oskenso »

RedShift1 wrote: post #62
WhyNotHugo wrote: post #61

Earlier quoted context omitted.

Are there any video players which can play a webrtc stream? Last I checked, VLC and other popular tools still don’t support it.

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

I wish vlc supported usf, 2sf and minigsf

Re: FFmpeg merges WebRTC support

#150

Post by messe »

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…

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

CGNAT is going to make that a hassle.

Post reply on HN