Hacker News Reader

Comment by calpaterson | Hacker News Reader

The trouble is that images are a large fraction of the page size even for well optimised websites. Using smaller images via changing format often makes a significant difference in the page load time.

It's also relatively easy for new formats to be adopted - the html picture tag makes it really easy to serve the same image in multiple formats to allow for backward compatibility.

And of course image decoders are easily distributed - JXL's encoder/decoder are open source.

The combination of those two factors probably means that this will never be a settled area now. It's fairly easy for websites to adopt a new format and there are strong reasons to. Means, motive and opportunity.

I reckon Chrome will cave in eventually. The pressure on browser performance is intense. Unless they want to see Safari faster in benchmarks of image heavy pages they will have to adopt it.

View on HN

> The trouble is that images are a large fraction of the page size even for well optimised websites. Using smaller images via changing format often makes a significant difference in the page load time.

That's true, but even savvy people don't seem to care much about this. For example, (open) podcasts are still universally MP3-based even though it's been possible for many years to halve their size using modern, ubiquitous audio formats.

> I reckon Chrome will cave in eventually. The pressure on browser performance is intense. Unless they want to see Safari faster in benchmarks of image heavy pages they will have to adopt it.

What's curious about this to me is why Apple is single-handedly saving JPEG-XL from obscurity when AV1 is also a fine substitute for mainstream image compression use cases.

The podcast (and audio in general) thing annoys me way more than it should. FFS, just use Opus, it is supported on virtually all devices out there and is massively smaller

last I checked the iPhone podcasts app doesn't play opus. Have things changed?

it's not just the podcasts app. ios itself doesn't support opus. i've run into this problem with plenty of other apps in ios.

Well then fuck iOS

I didn't know that about podcasts and audio formats. What format would you recommend? It would need to be well-supported by podcast players.

Opus

Opus is pretty widely supported (still some holes though, for example very few Adobe products support Opus), and it can sound better than MP3 at less than half the bitrate.

> What format would you recommend? It would need to be well-supported by podcast players.

HE-AAC. Support for HE-AAC and HE-AAC v2 has been universal on modern media platforms and operating systems for well over a decade.¹

  • All versions of Android support HE-AAC v2 playback²
    - Google also added encoders in Android 4.1 (2012)
  • iOS introduced support for HE-AAC v2 playback in iOS 4 (released 2010)
  • macOS introduced support for HE-AAC v2 playback with iTunes 9.2 (released 2010)
  • I'm not sure when Windows added support, but it was available in Windows 8
  • All open source players support HE-AAC v2 playback via FAAD2

FWIW, I distributed a reasonably-popular podcast (1.2M downloads over its lifetime) using HE-AAC v2 several years ago, and never received a complaint, or found a player it didn't work on.

¹ I read the other comments recommending Opus before responding, and although Opus is very nice, it's not as efficient or as ubiquitous as HE-AAC.

² https://developer.android.com/guide/topics/media/media-forma...

FAAD2 is in non-free repositories; for open source, it presents a problem with distribution outside of freeworld.

Neither Opus nor mp3 have this problem. So to maximize compatibility, mp3 is still the best choice, due to the attitude to Opus and other free codecs that Apple has.

> FAAD2 is in non-free repositories; for open source, it presents a problem with distribution outside of freeworld.

I may be misspeaking about FAAD2, but I've never run into an open-source player (like VLC) or library (like ffmpeg) which hasn't supported at least HE-AAC decode for a decade or more. If that's wrong, I'd love to be corrected in the most detailed way possible.

FFmpeg is exactly the kind of application, that in non-pruned configuration (i.e. with codecs like AAC) distributions cannot distribute binaries legally in some countries.

E.g. for Fedora, it is in rpmfusion repository and not in the distribution proper. Other distributions have similar arrangement for license-os-ok-but-patents-are-problem situation. These servers are outside US (or other countries that recognize software patents), and for the US users, the issue of obtaining the license is up to them.

The situation is so bad, that Fedora stopped shipping support for hardware acceleration of patented codecs (i.e. not complete codecs, but support to use the implementation in hardware, for example in your GPU), because they could be sued for contributory infringement.

Also note, that binaries for VLC or ffmpeg for Windows or Mac are similarly distributed from non-US servers, so basically the same situation as rpmfusion.

although Opus is very nice, it's not as efficient ... as HE-AAC

Uh, no, this is not correct. If you try to find a source, you'll easily find the opposite is very well established.

Here's a "Quality vs Bitrate" chart from opus-codec.org, the home of Opus: https://opus-codec.org/static/comparison/quality.svg

Note how AAC has effectively the same efficiency as Opus? HE-AAC and HE-AACv2 are notably better in comparison, and are usable at lower bitrates than AAC.

In cases where "the opposite is very well established", they're talking about AAC-LC. Citations that show otherwise are welcome! In any case, HE-AAC's universality is really beaten only by MP3 (which it trounces).

I assuming you are using HE-AAC at below 96kbps? Because above AAC-LC should perform better.

Normally aac and opus are used.

My guess is the fact that existing jpeg images can be transcoded to jpeg-xl losslessly is the driving feature. This gives an easy migration path for existing sites that don't have high resolution masters that can be re-encoded into AV1 or webp.

Also think of 20+ years of jpg digital camera photos that can now be transcoded to save space. For Apple that is also a huge win.

MP3 is also good enough. Modern compressors are on par with Opus, AAC or whatever is in fashion now. The format is sane, patents have expired, it run everywhere.

It's not worth the trouble.

Opus you'd get away with half the bitrate, or less, than MP3 for a podcast. Gets to be somewhat significant given the length of many podcasts, those 64kbps or so that you save add up over time.

Though I agree, the "works everywhere" aspect is really the overriding factor: everyone can play it, all the services will accept it, etc. I think the only way you'd see it get used significantly is if a major service was transcoding to it, but I don't know that podcast bandwidth is a sufficient cost for anyone to bother.

HE-AAC is a bit better than Opus, plus has the benefit of MP3's "works everywhere" experience. I posted more detail elsewhere in the thread if you're interested.

xHE-AAC from 2016 (also known as USAC) yes. The older HE-AAC from 2003 and HE-AACv2 are not. Codecs have similar names, but they are different and released at different times.

> What's curious about this to me is why Apple is single-handedly saving JPEG-XL from obscurity when AV1 is also a fine substitute for mainstream image compression use cases.

Apple does whatever they want. If they think something is better, they will go ahead and use it, the rest of the market be damned.

Tangentially related, some clients don't handle variable encodings well, putting another limit on efficiency improvements

indeed a pity progress is so slow even in these easier cases of widely available improvements

> The trouble is that images are a large fraction of the page size even for well optimised websites. Using smaller images via changing format often makes a significant difference in the page load time.

Pepperidge farm remembers Google heavily pushing for WebP for this reason. Look how much smaller it is! and Lighthouse giving demerits for every non-WebP image. Which, of course, is totally true, WebP images were almost always quite a bit smaller. They all looked like shit, too, of course.

Reply on news.ycombinator.com