21–30 of 204 posts
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.
Especially with Simulcast it will make it SO cheap/easy for people.
I made https://github.com/Glimesh/broadcast-box in a hope to make self-hosting + WebRTC a lot easier :)
I know there are JavaScript ports of FFmpeg and I would love to use them. But so far, I never got it working. I tried it with AI and this prompt: Make a simple example of speeding up an mp4 video in the browser using a version of ffmpeg that runs in the browser. Don't use any server side tech like node. Make it a single html file. But so far every LLM I tried failed to come up with a working solution.
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…
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
This implementation is very small. I feel 100% confident we are giving users the best thing possible.
I know there are JavaScript ports of FFmpeg and I would love to use them. But so far, I never got it working. I tried it with AI and this prompt: Make a simple example of speeding up an mp4 video in the browser using a version of ffmpeg that runs in the browser. Don't use any server side tech like node. Make it a single html file. But so far every LLM I tried failed to come up with a working solution.
Entered the same prompt with Sonnet 4. Just needed to paste the two errors in the console (trying to load the CDN which won't work since it uses a web worker, and hallucinated an ffmpegWasm function) and it output an HTML file that worked.
Not 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…
Most 'WHIP Providers' also support DataChannel. But it isn't a standardized thing yet
I know there are JavaScript ports of FFmpeg and I would love to use them. But so far, I never got it working. I tried it with AI and this prompt: Make a simple example of speeding up an mp4 video in the browser using a version of ffmpeg that runs in the browser. Don't use any server side tech like node. Make it a single html file. But so far every LLM I tried failed to come up with a working solution.
Earlier 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 know there are JavaScript ports of FFmpeg and I would love to use them. But so far, I never got it working. I tried it with AI and this prompt: Make a simple example of speeding up an mp4 video in the browser using a version of ffmpeg that runs in the browser. Don't use any server side tech like node. Make it a single html file. But so far every LLM I tried failed to come up with a working solution.
I'm sorry, but if you give up on something you would "love to use" just because LLMs are unable to oneshot it then you might be a bit too dependent on AI.
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.
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 portion of WebRTC, and anyone processing user input through ffmpeg is hopefully compiling a version enabling only the features they use, or at least "--disable-muxer=whip" and others at configure time. Or, you know, you could specify everything explicitly at runtime so ffmpeg won't load features based on variable user input.
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