It's pronounced vanilla-gee | Author of Mediabunny and Marble Blast Web. Love working on technically challenging projects that bring the best out of the web.
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:
Almost... done... just a hundred lines of bug reports left.
My brain is fried. But the robustness and correctness improvements from this bug hunt are enourmous. 354 accepted changes so far!!
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!
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!
https://t.co/p30wR0PHYo
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
@videospan Mediabunny can do this already, it streams both ways (reading and writing). If you process faster than the network, it'll send a single network request. Otherwise, it'll stop the current requests and resume later with a range request.
Also, I just read your fetch() streaming post again today! The fact that duplex: 'full' does not exist/work is still quite interesting to me! I do see how it's niche usage, but I also don't see how it would violate HTTP.
Not sure if I'm tripping, but didn't you make an HTTP 203 with @DasSurma where you showed just this? It's been years!