6 ms·

Google Chrome Is Already Preparing to Deprecate JPEG-XL

62 points by smitop 4y ago

anonova 4y ago
I wouldn't be surprised if this is more a legal issue since Microsoft was granted a patent on rANS encoding, which is used in JPEG-XL: https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/
- Upstart4973 4y ago
- jonsneyers 4y ago
  I doubt it's related to that. That patent is too recent to affect JPEG XL.
- JyrkiAlakuijala 4y ago
  didn't read it, but someone told on a forum that Microsoft's patent is about dynamically updated rANS probabilities during decoding -- JPEG XL is about static rANS codes, the codes are never changed/updated during decoding, they are context modeled and already clustered at encoding time, which makes it faster to decode than dynamically updated codes
ksec 4y ago
Like I said before, For Video, H.266 / VVC is just technically superior in every single way. For Images, JPEG XL is the best for 95%+ of use cases. For audio, we have a AAC-LC, literally as ubiquitous as MP3, truly patent free, and at 128 or 160+kbps, it is within 10% Bitrate difference compared to state of the art codec. And yet we end up in a world where the only accepted choice is AV1 for video, AVIF for images and Opus for Audio.
- Jasper_ 4y ago
  The only open-source AAC-LC encoder I'm aware of is ffmpeg's, which is pretty awful for quality and featureset. LAME beats the quality of ffmpeg's AAC-LLC encoder at similar bitrates, from what I've tried. That's a condemnation of ffmpeg and not AAC-LC, of course, but why care when libopus is right there and beats AAC-LC in a good percentage of cases. H.265/HEVC has barely gotten off the ground in adoption due to the double patent pool situation, and VVC seems unlikely to continue. VVC is a fine spec but it's too expensive to ship products with right now. JPEG-XL was never a good spec, tbh, having looked at the drafts. I don't have a copy of the ISO spec, but the draft I looked at lacked the rigor I would expect out of a modern compression system & file format -- some parts had Pi and trigonometric functions in the equations without precision bounds. It felt academic to me.
  - CharlesW 4y ago
    > H.265/HEVC has barely gotten off the ground in adoption due to the double patent pool situation… H.265/HEVC is ubiquitous on video-focused devices. It's used in every streaming service's encoding ladder. It's used for OTA DTV. It's used for Blu-ray. It's very popular for torrents. Apple devices capture to H.265. AV1 will be (deservedly) considered wildly successful when it reaches current H.265 adoption levels, several years from now.
  - kasabali 4y ago
    > The only open-source AAC-LC encoder I'm aware of is ffmpeg's, which is pretty awful for quality and featureset FDK is open source and decent. https://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC https://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_A...
    - mroche 4y ago
      FDK-AAC's license is regarded in the FOSS community as open-source, but patent encumbered. So it's up to the party shipping to the codec to determine where they fall on the spectrum of shipping patent encumbered software. In Fedora, for example, a modified version of fdk-aac is shipped, stripping out the features and functionality restricted by patents, in the fdk-aac-free package, with the more complete package shipped in RPM Fusion.
- mroche 4y ago
  You said this on the HEVC for Chrome thread, and even now I still don't fully agree with it. While some of these solutions may be technically superior in certain aspects, that doesn't mean everyone will drop what they're doing and implement support in hardware and software today because the folks managing these codecs (aka the patent pools) make life miserable for anyone trying to do so. Why bother with vague terms, definitions, royalties, and risk of lawsuit when you can have a solution that works nearly or just as well without all those problems? AV1 is a great video codec and when paired with a modern software toolset (like SVT-AV1) or, for today, latest gen hardware it's not really an issue. The age of the ecosystem is really the only practical drawback, with a lack of generally efficient software and widespread hardware support that other codecs like HEVC have had for several years. Opus is also a great audio codec that has seen successful adoption across streaming platforms and the vast majority of people wouldn't be able to tell the difference between Opus, AAC-LC, and MP3 without blatant artifacting. I have no problems with the technologies you mentioned themselves, they are all amazingly advanced and can open a lot of doors for high quality, efficient data transfer and media consumption. But the tech is only half the story; if you have people acting as ridiculous gatekeepers then there's no use complaining about the lack of adoption as it's falling on the ears of people who only care about one thing: money. The patent pools are looking to make money, the implementers are looking to save money. Take a guess which one end-user consumers are going to end up with most of the time?
pornel 4y ago
With AV1 video and AVIF browsers got buy-1-get-1-free deal. The video codec was a necessity, and decoding one frame from a slightly different flavor of MP4 container is a relatively minor addition. AVIF is not as good as JPEG XL, but it's good enough to the point JXL is a nice to have rather than a burning need. For the same reason I don't expect WebP2 to go anywhere unless Google is willing to make it a compatibility headache for other vendors.
- hypothesis 4y ago
  I might be incorrect here, but I thought that AVIF is using same/similar container format as MP4/HEIF. Is there clarity on patent situation for container formats? Wikipedia article briefly mentions patents for HEIF and it does not inspire much confidence there. [0] https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_Format https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_F...
  - pornel 4y ago
    HEIF has a ton of issues when you use it with H.256 (HEIC). But basic usage of it is almost identical to any MP4 video file, it just has a few bits of metadata saying "I'm an image". That's too trivial to be patentable.
- jonsneyers 4y ago
  In terms of burning needs you could argue that AVIF and WebP also don't really fill those, since they are not _that_ much better than JPEG with a good encoder while they lack progressive decode.
  - pornel 4y ago
    There was no good format for wide gamut and HDR. JPEG XT didn't catch on. If only WebP had been based on VP9 instead of VP8, it may have been good enough to stop AVIF too. You should propose JXL as intra frames in AV2. Seriously. Browsers got a video-derived image format twice in a row now, and without video there may never be a strong-enough motivation ever again.
Scaevolus 4y ago
As funny as this is, I don't think this is true. I _think_ for policy reasons all of Chromes experimental flags have deprecation deadlines to ensure they it doesn't accumulate endless flags that eventually break. These deadlines can be moved. Just search the jxl issue for "expiry", they've bumped it a few times already: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
- lifthrasiir 4y ago
  All past bumps however were only done by updating flag-metadata.json (this includes the most recent bump to M115 as well). Changing the user-facing message is new, and it doesn't help that the commit author is Vignesh Venkatasubramanian, who developed AVIF muxer for FFmpeg in the past. M115 therefore might be the final deadline this time.

62 points by smitop 4y ago

I wouldn't be surprised if this is more a legal issue since Microsoft was granted a patent on rANS encoding, which is used in JPEG-XL: https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/

Upstart4973 4y ago
jonsneyers 4y ago
I doubt it's related to that. That patent is too recent to affect JPEG XL.
JyrkiAlakuijala 4y ago
didn't read it, but someone told on a forum that Microsoft's patent is about dynamically updated rANS probabilities during decoding -- JPEG XL is about static rANS codes, the codes are never changed/updated during decoding, they are context modeled and already clustered at encoding time, which makes it faster to decode than dynamically updated codes

ksec 4y ago

Like I said before, For Video, H.266 / VVC is just technically superior in every single way. For Images, JPEG XL is the best for 95%+ of use cases. For audio, we have a AAC-LC, literally as ubiquitous as MP3, truly patent free, and at 128 or 160+kbps, it is within 10% Bitrate difference compared to state of the art codec. And yet we end up in a world where the only accepted choice is AV1 for video, AVIF for images and Opus for Audio.

Jasper_ 4y ago
The only open-source AAC-LC encoder I'm aware of is ffmpeg's, which is pretty awful for quality and featureset. LAME beats the quality of ffmpeg's AAC-LLC encoder at similar bitrates, from what I've tried. That's a condemnation of ffmpeg and not AAC-LC, of course, but why care when libopus is right there and beats AAC-LC in a good percentage of cases. H.265/HEVC has barely gotten off the ground in adoption due to the double patent pool situation, and VVC seems unlikely to continue. VVC is a fine spec but it's too expensive to ship products with right now. JPEG-XL was never a good spec, tbh, having looked at the drafts. I don't have a copy of the ISO spec, but the draft I looked at lacked the rigor I would expect out of a modern compression system & file format -- some parts had Pi and trigonometric functions in the equations without precision bounds. It felt academic to me.
- CharlesW 4y ago
  > H.265/HEVC has barely gotten off the ground in adoption due to the double patent pool situation… H.265/HEVC is ubiquitous on video-focused devices. It's used in every streaming service's encoding ladder. It's used for OTA DTV. It's used for Blu-ray. It's very popular for torrents. Apple devices capture to H.265. AV1 will be (deservedly) considered wildly successful when it reaches current H.265 adoption levels, several years from now.
- kasabali 4y ago
  > The only open-source AAC-LC encoder I'm aware of is ffmpeg's, which is pretty awful for quality and featureset FDK is open source and decent. https://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC https://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_A...
  - mroche 4y ago
    FDK-AAC's license is regarded in the FOSS community as open-source, but patent encumbered. So it's up to the party shipping to the codec to determine where they fall on the spectrum of shipping patent encumbered software. In Fedora, for example, a modified version of fdk-aac is shipped, stripping out the features and functionality restricted by patents, in the fdk-aac-free package, with the more complete package shipped in RPM Fusion.
mroche 4y ago
You said this on the HEVC for Chrome thread, and even now I still don't fully agree with it. While some of these solutions may be technically superior in certain aspects, that doesn't mean everyone will drop what they're doing and implement support in hardware and software today because the folks managing these codecs (aka the patent pools) make life miserable for anyone trying to do so. Why bother with vague terms, definitions, royalties, and risk of lawsuit when you can have a solution that works nearly or just as well without all those problems? AV1 is a great video codec and when paired with a modern software toolset (like SVT-AV1) or, for today, latest gen hardware it's not really an issue. The age of the ecosystem is really the only practical drawback, with a lack of generally efficient software and widespread hardware support that other codecs like HEVC have had for several years. Opus is also a great audio codec that has seen successful adoption across streaming platforms and the vast majority of people wouldn't be able to tell the difference between Opus, AAC-LC, and MP3 without blatant artifacting. I have no problems with the technologies you mentioned themselves, they are all amazingly advanced and can open a lot of doors for high quality, efficient data transfer and media consumption. But the tech is only half the story; if you have people acting as ridiculous gatekeepers then there's no use complaining about the lack of adoption as it's falling on the ears of people who only care about one thing: money. The patent pools are looking to make money, the implementers are looking to save money. Take a guess which one end-user consumers are going to end up with most of the time?

pornel 4y ago

With AV1 video and AVIF browsers got buy-1-get-1-free deal. The video codec was a necessity, and decoding one frame from a slightly different flavor of MP4 container is a relatively minor addition. AVIF is not as good as JPEG XL, but it's good enough to the point JXL is a nice to have rather than a burning need. For the same reason I don't expect WebP2 to go anywhere unless Google is willing to make it a compatibility headache for other vendors.

hypothesis 4y ago
I might be incorrect here, but I thought that AVIF is using same/similar container format as MP4/HEIF. Is there clarity on patent situation for container formats? Wikipedia article briefly mentions patents for HEIF and it does not inspire much confidence there. [0] https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_Format https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_F...
- pornel 4y ago
  HEIF has a ton of issues when you use it with H.256 (HEIC). But basic usage of it is almost identical to any MP4 video file, it just has a few bits of metadata saying "I'm an image". That's too trivial to be patentable.
jonsneyers 4y ago
In terms of burning needs you could argue that AVIF and WebP also don't really fill those, since they are not _that_ much better than JPEG with a good encoder while they lack progressive decode.
- pornel 4y ago
  There was no good format for wide gamut and HDR. JPEG XT didn't catch on. If only WebP had been based on VP9 instead of VP8, it may have been good enough to stop AVIF too. You should propose JXL as intra frames in AV2. Seriously. Browsers got a video-derived image format twice in a row now, and without video there may never be a strong-enough motivation ever again.

Scaevolus 4y ago

As funny as this is, I don't think this is true. I _think_ for policy reasons all of Chromes experimental flags have deprecation deadlines to ensure they it doesn't accumulate endless flags that eventually break. These deadlines can be moved. Just search the jxl issue for "expiry", they've bumped it a few times already: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

lifthrasiir 4y ago
All past bumps however were only done by updating flag-metadata.json (this includes the most recent bump to M115 as well). Changing the user-facing message is new, and it doesn't help that the commit author is Vignesh Venkatasubramanian, who developed AVIF muxer for FFmpeg in the past. M115 therefore might be the final deadline this time.