Mediabunny 1.42.0 is now out, adding THE most requested feature: full read/write support for HLS! 🚀
It's truly a game changer for client-side media processing. Here, I'm creating 5 renditions from a 40-second video in ~10 seconds, fully client-side, without a transcode server:
The niche bugs never stop coming. It turned out that my ProRes decoder (TurboRes) was interpreting pixel aspect ratio information incorrectly. This is easy to miss when reading the spec, but values 2 and 3 correspond to an IMAGE with a 4:3 and 16:9 aspect ratio. IMAGE! I treated it as the pixel aspect ratio instead.
Thankfully, nobody ever hits this case, because encoders typically don't set this value to anything but 0 (not even FFmpeg handles this field), but for somebody trying to create 100% bug-free software, everything must be patched!
3
30
1,301
The funny thing is that ever since starting this bug hunt, 100% of all user-reported bugs have already been found ahead of time! (Just not fixed yet, since I'm fixing them all at once)
This does give me the confidence that this is an effective way to make software robust
I try to make the highest quality software I can, and so I've been intrigued by LLMs' abilities to bring us closer to writing truly perfect, fault-free software.
I gave Claude Opus 5.5 the task of finding every remaining bug in Mediabunny that it could, and it came back and claimed to have found and fixed 360 bugs! And that's despite Mediabunny already being incredibly stable and battletested.
Of course, I'm now going through and reviewing and cleaning up every line it changed, and it's gonna take a while. But if you have the tokens available, there's basically no downside to doing something like this. The bogus bug fixes you can just discard, and what you're left with is better software.
The idea that we could have virtually bug-free software excites me. I know it's quite the idealistic goal, but I think it's worth pursuing!
Disappointing: ONLY Chromium handles backpressure for fetch() correctly (where the client consumes the response body at a slower rate than the server produces it), and even there it only kicks in after 60 MB buffered (8 MB when the server sends no-store)
In Firefox and Safari, they just receive the response body as fast as possible and never throttle. If the client doesn't consume it, the tab just dies from OOM after a while.
This is such a shame; the ability to throttle servers to send their responses more slowly is huge. This happens already when the connection is slow, but not when the consumer is slow. Mediabunny could use this feature for example to stream videos over the network by keeping a single request open and pulling more data from it when needed.
Since it does work for Chrome tho, I think I'll implement it for it
In case you missed it, I recently wrote a new blog post about how audio/video sync in Mediabunny (and in the wider web) has been subtly broken for years, and how I finally fixed it!
mediabunny.dev/blog/project-…
Reviewing this is taking forever. I'm at 116 verified bug fixes so far! Planning on doing 50-100 per day, I think that's manageable.
I try to make the highest quality software I can, and so I've been intrigued by LLMs' abilities to bring us closer to writing truly perfect, fault-free software.
I gave Claude Opus 5.5 the task of finding every remaining bug in Mediabunny that it could, and it came back and claimed to have found and fixed 360 bugs! And that's despite Mediabunny already being incredibly stable and battletested.
Of course, I'm now going through and reviewing and cleaning up every line it changed, and it's gonna take a while. But if you have the tokens available, there's basically no downside to doing something like this. The bogus bug fixes you can just discard, and what you're left with is better software.
The idea that we could have virtually bug-free software excites me. I know it's quite the idealistic goal, but I think it's worth pursuing!
3
33
2,058
I think this is cool, more performant software is always better.
Although I do feel like we need more voices in the space talking about how insanely performant and lean you can make web apps too (even WITH Electron)!!
The grass is surprisingly green once you drop React 😌
We've been early adopters of Rust since 2018 and a lot of our infra, voice tech, and even some of the current client is already Rust, the holy grail was getting the whole client there. That means Electron goes away, and so does React Native, mobile keeps native UI but shares app code with desktop via Rust. We hope to get it into testing with users soon™. (And it's not Tauri, it's GPUI, so good guess everyone.)
Alright, back to staring at the WoW Forever login screen.
12
90
3,750
Just realized my lovely OpenGraph metadata never had any chance to shine because the embed isn't shown when the tweet goes over 280 characters in length 🥲
ripppp
The audio in almost every video created with WebCodecs in the last 5 years has been subtly out of sync - you just can’t hear it!
I went down the rabbit hole to fix this once and for all, and Mediabunny now delivers sample-perfect AV sync.
Read about the journey to get there:
mediabunny.dev/blog/project-…
1
12
925
The audio in almost every video created with WebCodecs in the last 5 years has been subtly out of sync - you just can’t hear it!
I went down the rabbit hole to fix this once and for all, and Mediabunny now delivers sample-perfect AV sync.
Read about the journey to get there:
mediabunny.dev/blog/project-…
I try to make the highest quality software I can, and so I've been intrigued by LLMs' abilities to bring us closer to writing truly perfect, fault-free software.
I gave Claude Opus 5.5 the task of finding every remaining bug in Mediabunny that it could, and it came back and claimed to have found and fixed 360 bugs! And that's despite Mediabunny already being incredibly stable and battletested.
Of course, I'm now going through and reviewing and cleaning up every line it changed, and it's gonna take a while. But if you have the tokens available, there's basically no downside to doing something like this. The bogus bug fixes you can just discard, and what you're left with is better software.
The idea that we could have virtually bug-free software excites me. I know it's quite the idealistic goal, but I think it's worth pursuing!
I've had dinner with these folks!!
Mark my words. The next documentary will be about David and Media Bunny. @vanilagy is the GOAT.
youtu.be/gCZEKiP3h44
20
1,031
I don't get the hate for this, running a service on a single machine is sufficient for the VAST amount of apps out there. If the service is non-critical, 5-10 minute of announced downtime every couple of months is a non-issue in my mind.
Any system built to support zero-downtime restarts/updates is vastly more complex architecturally. Now you need multiple nodes with load balancers, and even your database must be replicated to 2+ machines so you can forward all writes to one while the other reboots.
Ofc a way around this is to use some sort of managed cloud abstraction, but not everyone is interested in that.
Note: Tuta will be down for ~10 minutes
We need to restart the servers for updating them with a non-critical security patch. This will lead to a downtime of approx. ten minutes. You can check the availability of Tuta here: status.tuta.com
We apologize for the inconvenience and we try to keep the downtime as short as possible. Emails that arrive during the downtime will be queued and delivered later to your mailbox.










