Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why xHE-AAC is being embraced at Meta

engineering.fb.com

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Why xHE-AAC is being embraced at Meta

#21

Post by Dylan16807 »

charcircuit wrote: post #16
LeoPanthera wrote: post #8

As far as I know, xHE-AAC has no advantages over Opus, however, Opus is free from patent licensing.

>xHE-AAC has no advantages over Opus The main features focused on in this article are loudness management and adaptive bitrate audio. From what I can tell Opus supports neither of those things.

A specific kind of adaptive bitrate where you have pre-encoded "lanes" at different bitrates and you can switch seamlessly at certain points.

I'm not convinced the loudness metadata makes much difference, especially for the entity doing the encoding. Can it do compression at playback time too? That's sort of implied but I'm not sure.

Re: Why xHE-AAC is being embraced at Meta

#22

Post by charcircuit »

Dylan16807 wrote: post #21
charcircuit wrote: post #16

Earlier quoted context omitted.

>xHE-AAC has no advantages over Opus The main features focused on in this article are loudness management and adaptive bitrate audio. From what I can tell Opus supports neither of those things.

A specific kind of adaptive bitrate where you have pre-encoded "lanes" at different bitrates and you can switch seamlessly at certain points. I'm not convinced the loudness metadata makes much difference, especially for the entity doing the encoding. Can it do compression at playback time too? That's sort of implied but I'm not sure.

> Can it do compression at playback time too

Yes, it has dynamic range control too.

Re: Why xHE-AAC is being embraced at Meta

#23

Post by diimdeep »

Looks like xHE-AAC beats opus on Topic: A Session In The Abyss: xHE-AAC vs OPUS at 12, 24 and 32 kbps (voice & music) (Read 16655 times) https://hydrogenaud.io/index.php/topic,120997.0.html

xHE-AAC vs HE-AAC v2 Audio Quality Comparison: War of the Low-Bitrate Codecs https://www.youtube.com/watch?v=74SsKOUHgvo

Re: Why xHE-AAC is being embraced at Meta

#25

Post by jeroenhd »

Teever wrote: post #9
zinekeller wrote: post #6

Earlier quoted context omitted.

Patents. I presume that the Facebook and Instagram apps bundle their own decoder (which Meta paid) but you need to convince other companies (or wait for OS integration for Firefox) to include xHE-AAC.

When I set up my jellyfin server I learned that Firefox doesn't support h.265 and that there's no way to add codecs to the browser. Does anyone know why it isn't possible to add codecs to the browser?

You need to pay for the necessary patents to include an H.265 decoder if you intend to distribute software in countries that care about silly things like software patents.

Mozilla famously relied on Cisco to gain h.264 playback, because the patent included a certain maximum total price you needed to pay after exceeding a certain amount of devices. Cisco exceeded that amount, so any additional devices they supported were practically free, and they released a free h.264 decoder plugin for Firefox. The pricing loophole has been removed out of h.265 so a Mozilla decoder would cost them a lot of money.

In theory you could add codecs to your browser just fine, but Mozilla has already indicated it's not planning on adding h.265 to their browser, focusing on AV1 support instead.

Perhaps Mozilla would welcome patches to allow forwarding h.265 streams to the OS for decoding, like Chrome does, but they're not going to put the effort in themselves. With hardware AV1 decoding finally on the rise, I don't think that's a bad decision necessarily, companies and websites opting for the patent ridden format over the open format knew what they were doing.

Re: Why xHE-AAC is being embraced at Meta

#26

Post by oefrha »

awill wrote: post #3

This codec isn’t supported on the web. So it is Android and iOS only. This post talks about the improved audio quality, but I don’t buy it. This was probably done to reduce storage and bandwidth, not to improve audio quality. Phone speakers aren’t good enough to notice. Also, I wish they had backed opus…

Reduced bandwidth obviously leads to better quality at the same target bit rate. Phone speakers are good enough to reproduce some obvious compression artifacts of, say, 32k/64k HE-AAC, let alone higher end headphones. ABR could definitely help.

Re: Why xHE-AAC is being embraced at Meta

#28

Post by DaleCurtis »

awill wrote: post #3

This codec isn’t supported on the web. So it is Android and iOS only. This post talks about the improved audio quality, but I don’t buy it. This was probably done to reduce storage and bandwidth, not to improve audio quality. Phone speakers aren’t good enough to notice. Also, I wish they had backed opus…

Chrome has supported xHE-AAC since 2020 on Android, 2022 on macOS, and added support on Windows last week.

Re: Why xHE-AAC is being embraced at Meta

#29

Post by weeblewobble »

TedDoesntTalk wrote: post #17
orangepurple wrote: post #11

Earlier quoted context omitted.

Chrome quietly supports h265 decode as of version 107 https://chromestatus.com/feature/5186511939567616

What’s quiet about it? Seems like it was announced.

They didn’t exactly hide it but they certainly didn’t make a big deal about it. Likely because there is no software fallback

Re: Why xHE-AAC is being embraced at Meta

#30

Post by illiarian »

TedDoesntTalk wrote: post #4
awill wrote: post #3

This codec isn’t supported on the web. So it is Android and iOS only. This post talks about the improved audio quality, but I don’t buy it. This was probably done to reduce storage and bandwidth, not to improve audio quality. Phone speakers aren’t good enough to notice. Also, I wish they had backed opus…

Why can’t it be supported in web browsers? Is there a technical limitation or it just hasn’t been done because only Meta uses it?

Because more often than not is has to be implemented on OS level, and no one wants to do that for many many reasons, and patents are probably the least of it.

For example, for most modern formats software-only encoding is very slow, and you really want to have hardware support for it [1]. But to add hardware support to increasingly complex and varied specs is not a decision you make lightly.

[1] Google is forcing companies to support its codecs in hardware on pain of removing Youtube e.g. https://arstechnica.com/gadgets/2021/04/roku-vs-google-part-...

Post reply on HN