Comment by pornel | Hacker News Reader

Comment by pornel | Hacker News Reader

Parent Full thread

The attempt to provide a second JPEG-XL implementation has stalled. Two independent implementations are the bar for a web standard. AVIF meets it, JPEG-XL does not.

There has been enough 3rd party interest to create multiple AV1/AVIF implementations. JPEG-XL has its original team (doing great work), and then… commenters lamenting, but nobody else invested enough to actually to write the code.

Browsers' goal is not just to have every benchmark-winning format. They also need to minimize attack surface, risk of bug-compatibility (which is why one and only implementation is not sufficient), and watch out for long-term costs of code size, maintenance, and technical debt. New codecs can be added at any time, but can never be removed.

AV1 got in, because video really needed an answer to the looming threat of patented expensive H.265. There was a risk of repeating the pains of H.264 support, and this time without Cisco's licensing loophole. Then AVIF got in, because AV1 was already in. It's that simple.

>The attempt to provide a second JPEG-XL implementation has stalled

What do you mean by "the attempt"? There are at least three independent decoder implementations:

jxl-oxide (Rust): https://github.com/tirr-c/jxl-oxide

J40 (C): https://github.com/lifthrasiir/j40

jxlatte (Java): https://github.com/thebombzen/jxlatte

None of them is feature complete, but it's because each of them is a hobby, single-person project. You're making it sound like some billion-dollar company tried to implement JPEG XL and failed, because it's too complex or something.

However, it should be noted that those independent implementations, despite being hobby projects, helped to iron-out some minor issues in the standard.

>Then AVIF got in, because AV1 was already in.

AVIF uses its own container format that had to be implemented. Implementing AV1 does not give you AVIF support for free.

The point of requiring a second implementation is to prove that the standard is stable and consistent enough that at least two of them can agree on how it works. It doesn't matter who is building the second implementation, it just needs to exist in a feature complete and maintained state. If hobbyist implementations have been uncovering issues in the standard, that just further justifies the "two independent implementations" rule. Bug-for-bug compatibility problems are browser vendors' worst nightmare.

> None of them is feature complete, but it's because each of them is a hobby, single-person project

Which is why they're not considered implementations to meet this bar. You need multiple FULL implementations to ensure that it is actually FULLY viable, otherwise you risk taking on a potentially broken format that you can't remove.

> You're making it sound like some billion-dollar company tried to implement JPEG XL and failed, because it's too complex or something.

I doubt any big company actually tried (or tried very hard). Cost of implementation becomes a kind of implicit test here, because companies like things cheap.

> AVIF uses its own container format that had to be implemented. Implementing AV1 does not give you AVIF support for free.

It gives AVIF support for cheap due to code/algorithm re-use. Companies like things cheap, so that's a big selling point.

To be fair, you don't need a FULL implementation. You just need some safe subset that everyone agreed on. For example, even the old JPEG was never fully implemented in browsers — arithmetic coding is not supported.

> I doubt any big company actually tried (or tried very hard). Cost of implementation becomes a kind of implicit test here, because companies like things cheap.

So if an individual unpaid volunteer spends their time doing a 2nd implementation, <bigco> might consider it for their browser. But they won't pay for a 2nd implementation with their own staff, even if they own a humongous chunk of the browser market (which comes with responsibilities) and even if it is a better algorithm.

Sounds about right.

It's all about incentives. If there's enough incentive for them to do it, they will. "Better" doesn't always have much to do with it.

We make incremental gains as a human race, not necessarily optimal ones.

I was thinking about j40.

It's cool that there's a Rust implementation in progress. If it works out, it will make it much easier for me to support JXL. I've been waiting to RIIR the j40 instead.

AVIF (HEIF) container format is MP4, which browsers already parse for video. There is a bit of extra work to extract image-specific data, but it's minor compared to AV1 implementation. AVIF even contains a completely redundant copy of key AV1 metadata (av1C) to spare implementations from parsing the AV1 payload.

RIIR = rewrite it in Rust

The number of implementations was not considered a criterion for Chrome, or at least they didn't mention it. For WebP, they didn't seem to care much about it. I agree that it's a good criterion, as it is a good way to ensure that a spec is solid and interoperability actually works. So I am happy that there are currently three alternative jxl implementations.

The main thing you want to have though, is a standard that cannot be unilaterally changed in arbitrary ways by a single party. However flawed it may be, ISO does have a long history of standardization, and it has procedures in place to ensure that changes are scrutinized and can only be applied when approved by the national standardization bodies.

Yeah, WebP was forced on other browsers, and never met the bar for a proper standard.

This is just WebSQL story all over again, right? “Go redo it from scratch” is the most ridiculous excuse in the book.

Except they made the right choice with WebSQL. Exposing and securing the entire api surface of sqlite -- from sql syntax to binary compatibility to behavior-altering pragmas -- would have been a compatibility and security nightmare that would make xkcd 1172 look tame by comparison. Exposing a block device instead [1] and layering user-provided sqlite on top of it via WASM [2] is infinitely better than rushing to lock ourselves into a roller coaster that runs straight through the worst compatibility minefield the web has ever seen.

[1]: https://news.ycombinator.com/item?id=35165640 "Firefox 111.0 enabled Origin private file system access"

[2]: https://news.ycombinator.com/item?id=33374402 "SQLite in the browser with WASM/JS"

Reply on news.ycombinator.com