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

191–200 of 204 posts

Re: FFmpeg merges WebRTC support

#191

Post by NicuCalcea »

dedosk wrote: post #185
esbeeb wrote: post #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.

Gajim and XMPP is still used out there? I miss the days when I could use pidgin for chat apps. Now it is all wallet garden/app-per-service.

I'm quite happy with Beeper, it still has some bugs and isn't open source, but it saves me from remembering where different contacts live.

Re: FFmpeg merges WebRTC support

#192

Post by marxisttemp »

dylan604 wrote: post #58
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

is this something that one could compile with a --without-whip type of argument if you don't want/need? that would an ideal thing.

Yes, pretty much every bit of ffmpeg can be enabled or disabled when compiling.

Re: FFmpeg merges WebRTC support

#193

Post by marxisttemp »

cranberryturkey wrote: post #181
esbeeb wrote: post #152

Earlier quoted context omitted.

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.

I guess I still don't understand. You don't really "code" with ffmpeg. It just is used to transform media formats or publish to a public streaming endpoint.

All of ffmpeg’s functionality is accessible from C (and transitively most other programming languages) via libavformat, libavcodec etc. FFmpeg supporting WebRTC means that projects using these libraries gain support for WebRTC in code.

Re: FFmpeg merges WebRTC support

#194

Post by rw_grim »

dedosk wrote: post #185
esbeeb wrote: post #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.

Gajim and XMPP is still used out there? I miss the days when I could use pidgin for chat apps. Now it is all wallet garden/app-per-service.

There's plugins for most of the modern stuff at https://pidgin.im/plugins

Re: FFmpeg merges WebRTC support

#195

Post by Sesse__ »

Sean-Der wrote: post #173
Sesse__ wrote: post #156

Earlier quoted context omitted.

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…

I saw this also. WebRTC just is the path of least resistance/highest adoption at this point. We could go make a better/simpler standard for video streaming that is TCP. What a giant battle though that would never seen adoption . I have accepted/embraced the challenge of making WebRTC as accessible as possible. Stuff like WebRTC for the Curious in hopes of making it less painful for everyone dealing with the complexit…

> We could go make a better/simpler standard for video streaming that is TCP. What a giant battle though that would never seen adoption .

What do you mean? in HTTP against a stream works, you don't need a new standard. But it's not a low-latency path (you cannot control the buffer).

Re: FFmpeg merges WebRTC support

#196

Post by spartanatreyu »

_flux wrote: post #169
Sean-Der wrote: post #138

Earlier quoted context omitted.

Broadcast Box has a discord https://discord.gg/An5jjhNUE3 You could also join the Pion one https://pion.ly/discord Other place is video-dev Slack https://www.video-dev.org/ X also has a great community of hackers!

Are now Discord, Slack and X now better options than Reddit? Too bad nobody is using open forums (e.g. Discourse, Matrix, Mastodon).

Discord is better for ephemeral style questions. Mastodon is better for sharing experimentations and explorations.

Re: FFmpeg merges WebRTC support

#197

Post by Spivak »

actionfromafar wrote: post #161
chompychop wrote: post #159

I have a beginner question - Can WebRTC be used as an alternative to sending base64-encoded images to a backend server for image processing? Is this approach recommended?

Now I have the question - when does one send base64-encoded images to a backend server?

The OpenAI API is a pretty high-profile example of this existing in the real world. You use it in their conversations interface when you want to include images in the conversation. Discord also uses it for attachments https://discord.com/developers/docs/reference#image-data. More generally it's when you want to send image data as part of a larger JSON blob.

Re: FFmpeg merges WebRTC support

#198

Post by ablob »

Evidlo wrote: post #153
ablob wrote: post #132

Earlier quoted context omitted.

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

I think it never took off and is not supported by many if not most routers. However, it is an efficient solution for sending live-stream data over the web. I think eventually the pressure to not send packets for each consumer but at most once per port will take over and force providers to implement this or a better solution.

Re: FFmpeg merges WebRTC support

#199

Post by sahilagarwal »

rietta wrote: post #168
refulgentis wrote: post #110

Earlier quoted context omitted.

It's amazing --- I cut my teeth in software engineering with ffmpeg-related work 15 years ago, LLMs generating CLI commands with filters etc. is right up there with "bash scripts" as things LLMs turned from "theoratically possible, but no thanks unless you're paying me" into fun, easy, and regular. Yesterday I asked it for a command to take a 14 minute video, play the first 10 seconds in realtime, and rest at 10x spe…

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 sharing some of them??

Re: FFmpeg merges WebRTC support

#200

Post by messe »

chaz6 wrote: post #182
messe wrote: post #150

Earlier quoted context omitted.

> With how ubiquitous gigabit symmetric is becoming, I wonder if you could even do P2P nowadays. CGNAT is going to make that a hassle.

Ideally any ISP resorting to CGN would be providing IPv6 support, but Tailscale shows that nat hole-punching can work well [1]. I'm not sure if that's feasible to implement in a web browser though. [1] https://tailscale.com/blog/how-nat-traversal-works

It can work okay, but still not perfectly. Before I asked my ISP for a static address, tailscale connections between my place and my partner's only managed to maintain a direct connection half the time. The other half of the time, they required a relay.
Post reply on HN