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:
Mediabunny v1.66.0 is out, and it includes a ridiculous 400 fixes and improvements across the entire library! 🚀
It's the result of a multi-week LLM-assisted bug hunt to find and squash every last bug hiding in Mediabunny, from large to small, and before anybody runs into them.
Mediabunny has over 20 million monthly downloads at this point, and I feel it's my responsibility to make it as robust and reliable as I can make it. My aspiration is that it has literally zero bugs. I want it to "just work" no matter what people throw at it.
Releasing this later today.
But, what's been crazy: basically all issues I've gotten since starting this I was able to close with "Thanks, already fixed." I wonder for how long it'll be like that.
The bughunt is DONE!! Finally. Almost 400 fixes and improvements to Mediabunny.
Took absolutely forever to review and refine all this, but I think it was worth it.
Whoever hits an actual Mediabunny bug in production after I release this update gets some sort of prize from me 😂
Haha thanks for the glazing!! Appreciate it. I totally agree with you on frontend, I feel like AI has basically solved UI coding. There isn't a crazy amount of wiggle room with how something is implemented, and if the UI works, it works. I'd probably still instruct the AI to extract shared components into shared files, so it doesn't end up implementing slightly different buttons everywhere.
The bughunt is DONE!! Finally. Almost 400 fixes and improvements to Mediabunny.
Took absolutely forever to review and refine all this, but I think it was worth it.
Whoever hits an actual Mediabunny bug in production after I release this update gets some sort of prize from me 😂
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!!
@reelsnmags Wait, TRUE!! I don't support resumable downloads right now actually. I'll totally add that! Thanks for pointing it out.
I think it's fine to generate a zip on the server if it's small. But for this, streaming was just so neat.
I run the custom level sharing site for Marble Blast (called Marbleland, I built it in 2021), and probably my favorite feature of the whole app is its streaming ZIP download to enable bulk level download.
The naive way to do ZIP downloads on a server is to either generate them ahead of time (wastes storage) or to generate them in full first when requested, and then to download them. That second approach is way too slow and would require storing an temporary 8 GB .zip file on the server.
Instead, the .zip just... gets built as you download it. It includes almost 8000 levels, over 100,000+ files, and the server uses like maybe 20 MB of RAM maximum while sending it all to you. The ZIP generation runs at ~500 MB/s output speed, so the network speed is the only bottleneck.
The result is that you can download any arbitrary subset of levels with zero delay. It even computes the exact .zip's size before it starts streaming it so that the server can set Content-Length on the response and the user gets a download progress bar.
It's so neat!!
Here, this just happened. It generated the code in the screenshot. It adds an instanceof check, and this now means that IsobmffOutputFormat is always imported if anybody muxes HLS. Mediabunny is explicitly tree-shakable, and this completely breaks tree shaking, because now anybody who writes HLS also needs to bundle the entire ISOBMFF muxer with it.
Of course, I can tell it this and ask it to remember it, but there are countless other cases like this that I haven't told it about yet because I'll only know them when I see them. That's why it's so important to read the output.
Blind trust would've been horrible. I think had I realized from the first 10, 20, 50 issues that I usually agreed with what Opus did, I wouldn't have been so thorough with reviewing all of them.
Hard to put exact number on it. I would say a third of the fixes went in unchanges, usually smaller ones. A bunch left ugly/bloated/repeated/inefficient code, and many made wrong architectural assumptions, design decisions, or fixed the bug at the wrong level.
And even if you look beyond the implementation of the fix, the very decision of what even counts as a bug and how the system is supposed to behave is only something I can add, since I dictate the direction of the project. There were lots of points that Opus flagged but didn't fix, because it required inspection from my part.
That's not to say that Opus 5.5 isn't wicked smart, it absolutely is. One thing I mostly trust it blindly with is the tests. They're pretty constrained anyway (they have to fail on main and pass in the fix branch), so that leaves little room for error.
If you want to see all of the manual correction, you can check the commits that happened on the PR: https://t.co/fkal9WasvX
The first was the initial pass, everything below that resulted from the manual review. That should give you a good idea of how much code wasn't up to standard.
@Narretz Yes, correct! Mediabunny already handles this properly. Think video that's really 4:3 under the hood but wants to be stretched to 16:9. Then each pixel has an aspect ratio of 4:3. (because (4*4)/(3*3) = 16/9)
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!
I've seen a sharp rise in "speculative fixes" lately in Mediabunny. People raise issues they never even had, and that usually can't even occur.
This is different from people fixing random bugs that they themselves didn't encounter, I don't mean that.
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!!