That should make self hosting streams/streaming CDNs way easier. If you know how to use it ffmpeg is such an amazing stand alone/plug and play piece of media software.
It really is, this comic always comes to mind https://xkcd.com/2347/
FFmpeg merges WebRTC support
71–80 of 204 posts
Re: FFmpeg merges WebRTC support
#72Earlier 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.
It could very well be legit, but if you "have not tested its answer yet" the fact that it can generate something that looks plausible doesn't really tell you much. Generating plausible-sounding but incorrect answers is like the #1 most common failure mode for LLMs.
Re: FFmpeg merges WebRTC support
#73Does 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.
Re: FFmpeg merges WebRTC support
#74What 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
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.)
Re: FFmpeg merges WebRTC support
#75Earlier quoted context omitted.
That's just wrong. The example is live: you can run it right there on the page. If the code isn't working when you write it, you're probably importing something incorrectly (or you're not running it in an environment with React, which is where the `use*` functions come from). You can even click on the source of the log lines when the example is running (on the right edge of the Chrome console) to jump into the hot-lo…
I think there is some kind of misunderstanding here. You say "an environment with React". My environment is the browser. I don't know how one is supposed to run that nameless function on that page. What I am looking for is a simple, complete example in HTML that can run standalone when opened in the browser. Without any server side processing involved.
If you want to copy/paste, try taking the first example and asking the llm to refactor the code to run in a browser with no dependencies. It should be able to strip out the react stuff, or at least get it close and you can fix it from there.
Re: FFmpeg merges WebRTC support
#76Earlier quoted context omitted.
Full virtualization. Docker implies a shared kernel attack surface, that's what you want to avoid.
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.
Re: FFmpeg merges WebRTC support
#77Not the SCTP parts! It's implementing WebRTC-HTTP Ingestion Protocol (WHIP), a commonly used low-latency HTTP protocol for talking to a gateway that talks actual WebRTC to peers over WebRTC's SCTP-based protocol. https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html I hope some day we can switch to a QUIC or WebTransport based p2p protocol, rather than use SCTP. QUIC does the SCTP job very well atop existing U…
How would you like to see/use the SCTP parts? I am not sure how to expose them since the WHIP IETF draft makes no mention/suggestion of it. Most 'WHIP Providers' also support DataChannel. But it isn't a standardized thing yet
WebRTC actual's complezity is very high. WHIP seems to be the standard path for most apps to integrate, but it does rely on an exterior service to actually do anything.
Hypothetically ffmpeg could be an ICE server for peer-connecting, do SDP for stream negotiation possibly with a side of WHEP (egress protocol) as well, could do SCTP for actual stream transfer. Such that it could sort of act as a standalone peer, rather than offload that work to a gateway service.
Worth noting that gstreamer & OBS also are WHIP based, rely on an external gateway for their WebRTC support. There's not one clear way to do a bunch of the WebRTC layer cake (albeit WHEP is fairly popular I think at this point?), so WHIP is a good way to support sending videos, without having to make a bunch of other decisions that may or may not jive with how someone wants to implement WebRTC in their system; those decisions are all in the WHIP gateway. It may be better to decouple, not try to do it all, which would require specific opinionative approaches.
Re: FFmpeg merges WebRTC support
#78I 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!
Re: FFmpeg merges WebRTC support
#79Earlier quoted context omitted.
I think there is some kind of misunderstanding here. You say "an environment with React". My environment is the browser. I don't know how one is supposed to run that nameless function on that page. What I am looking for is a simple, complete example in HTML that can run standalone when opened in the browser. Without any server side processing involved.
If you want to copy/paste, try taking the first example and asking the llm to refactor the code to run in a browser with no dependencies. It should be able to strip out the react stuff, or at least get it close and you can fix it from there.
I have tried that a bunch of times and a bunch of ways and did not get ffmpeg to work.
It might have to do with these two strange comments at the top:
// import { FFmpeg } from '@ffmpeg/ffmpeg';
// import { fetchFile, toBlobURL } from '@ffmpeg/util';
Re: FFmpeg merges WebRTC support
#80Earlier quoted context omitted.
If you visit the ffmpeg.wasm documentation, the first example on the Usage page does almost exactly this: https://ffmpegwasm.netlify.app/docs/getting-started/usage It transcodes a webm file to MP4, but making it speed up the video is trivial: just add arguments to `ffmpeg.exec()`. Your lack of success in this task is trusting an LLM to know about cutting-edge libraries and how to use them, not a lack of progress in t…
The problem is that they don't provide the full code that can run in the browser. I have not managed to get the function they show in the first example to run in the browser.
I just threw that prompt into the free ChatGPT, looks like it'll have a few versioning as well as CORS issues...