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

91–100 of 204 posts

Re: FFmpeg merges WebRTC support

#91

Post by Sean-Der »

maxmcd wrote: post #37
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]…

Thanks for all your work Sean! It's been a delight to use your webrtc libs and see your impact across a broad range of technical efforts.

Thank you :)

When are you coming back to the WebRTC space, lots more cool stuff you could b doing :) I really loved [0] it's so cool that a user can access a server behind a firewall/NAT without setting up a VPN or having SSH constantly listening.

[0] https://github.com/maxmcd/webtty

Re: FFmpeg merges WebRTC support

#92

Post by Sean-Der »

shmerl wrote: post #73

Does it allow more realtime streaming than SRT on LAN? I'm still waiting for ffmpeg CLI tool to merge pipewire + xdg-desktop-portal support. You still can't record a screen or window on Wayland with it.

With WebRTC you can expect ~100ms with zero optimizations on your LAN.

With bitwhip[0] I got it way lower then that even.

[0] https://github.com/bitwhip/bitwhip

Re: FFmpeg merges WebRTC support

#93

Post by dark-star »

bigfishrunning wrote: post #5
qwertox wrote: post #2

What does this mean? That websites could connect directly to an FFmpeg instance and receive an audio- and/or video-stream? Phoronix has a somewhat more informative page: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

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?

Re: FFmpeg merges WebRTC support

#94

Post by afiori »

ta1243 wrote: post #76
afiori wrote: post #63

Earlier quoted context omitted.

Kernel level exploits are more dangerous but also way less common, for a lot of places docker is sorta okay as a security boundary

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.

To make a bit of a strawman of what you are saying even better still would be an unplugged power cable as a turned off machine is (mostly) unhackable.

To be more serious seurity is often in conflict with simplicity, efficiency, usability, and many other good things.

A baseline level of security (and avoidance of insecurities) should be expected everywhere, docker allows many places to easily reach it and is often a good enough tradeoff for many realities.

Re: FFmpeg merges WebRTC support

#95

Post by shmerl »

Sean-Der wrote: post #92
shmerl wrote: post #73

Does it allow more realtime streaming than SRT on LAN? I'm still waiting for ffmpeg CLI tool to merge pipewire + xdg-desktop-portal support. You still can't record a screen or window on Wayland with it.

With WebRTC you can expect ~100ms with zero optimizations on your LAN. With bitwhip[0] I got it way lower then that even. [0] https://github.com/bitwhip/bitwhip

That's nice. I had hard time getting low latency with SRT, but managed to get within the range of roughly slightly less than one second using gpu-screen-recorder on one end and ffplay on the other end with flags for low latency.

Re: FFmpeg merges WebRTC support

#96

Post by endre »

ta1243 wrote: post #76
afiori wrote: post #63

Earlier quoted context omitted.

Kernel level exploits are more dangerous but also way less common, for a lot of places docker is sorta okay as a security boundary

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 escalated quickly.

but I agree.

Re: FFmpeg merges WebRTC support

#97

Post by codedokode »

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.

Leaking local IP addresses?

Re: FFmpeg merges WebRTC support

#98

Post by Mofpofjis »

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.

Re: FFmpeg merges WebRTC support

#100

Post by leland-takamine »

_Manch wrote: post #86
leland-takamine wrote: post #84

Anyone been able to successfully build ffmpeg from source to include whip support? Struggling to figure out the right ./configure options

You need --enable-muxer=whip and --enable-openssl

Seems work but fails with 500 when streaming to cloudflare stream though: https://gist.github.com/Leland-Takamine/1a13f31c7521d0223624...
Post reply on HN