4 ms·

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

by pornel 4y ago

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.

hypothesis 4y ago
This is just WebSQL story all over again, right? “Go redo it from scratch” is the most ridiculous excuse in the book.
- infogulch 4y ago
  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 https://news.ycombinator.com/item?id=35165640 "Firefox 111.0 enabled Origin private file system access" [2]: https://news.ycombinator.com/item?id=33374402 https://news.ycombinator.com/item?id=33374402 "SQLite in the browser with WASM/JS"
peppermint_gum 4y ago
>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 https://github.com/tirr-c/jxl-oxide J40 (C): https://github.com/lifthrasiir/j40 https://github.com/lifthrasiir/j40 jxlatte (Java): https://github.com/thebombzen/jxlatte 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.
- infogulch 4y ago
  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.
- kstenerud 4y ago
  > 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.
jonsneyers 4y ago
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.
- pornel 4y ago
  Yeah, WebP was forced on other browsers, and never met the bar for a proper standard.

by pornel 4y ago

hypothesis 4y ago

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

infogulch 4y ago
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 https://news.ycombinator.com/item?id=35165640 "Firefox 111.0 enabled Origin private file system access" [2]: https://news.ycombinator.com/item?id=33374402 https://news.ycombinator.com/item?id=33374402 "SQLite in the browser with WASM/JS"

peppermint_gum 4y ago

>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 https://github.com/tirr-c/jxl-oxide J40 (C): https://github.com/lifthrasiir/j40 https://github.com/lifthrasiir/j40 jxlatte (Java): https://github.com/thebombzen/jxlatte 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.

infogulch 4y ago
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.
kstenerud 4y ago
> 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.

jonsneyers 4y ago

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.

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