Comment by cogman10
9 hours ago
Man what a showcase for Opus this is.
Don't get me wrong, this sort of thing is a valuable exercise and we are better off with better encoders for these older codecs. But look at the numbers for Opus on this benchmark. It simply blows all the AAC encoders out of the water even at 64 kbps.
The biggest advantage for having a good AAC encoder isn't efficiency, it's that for nearly the past 2 decades the de facto standard for live streamed video has been RTMP with H.264 video and AAC audio. There is basically no support for any other codecs. If you want to send a video stream to Youtube or Twitch, you will be sending H.264 and AAC. If you want an idea of how ubiquitous this is, I just checked in OBS and it will not even let you select different video and audio codecs in streaming mode, it just (correctly) assumes that anybody who's streaming will be streaming H.264 and AAC.
YouTube actually supports H.265 and VP9 ingest, depending on the streaming protocol. I can actually stream 4K@60 H.265 from my Mac Studio with < 5% CPU usage due to the hardware encoder support in OBS.
https://developers.google.com/youtube/v3/live/guides/ingesti...
Nice, glad some sites are finally trying to move forward. It looks like they only support H.265 video with AAC audio, so this should still be helpful for people who are streaming H.265. https://developers.google.com/youtube/v3/live/guides/hls-ing...
Plus, at 96+ kbps (assuming an Apple-quality AAC-LC encoder) Opus loses its quality advantage. So at higher bitrates, the benefit of choosing Opus is that encoders/decoders are royalty-free.
Am I reading that chart wrong? I see Opus ahead across every bitrate.
1 reply →
The RTMP protocol comes from Adobe Flash which only supported a limited set of codecs, the only still useful ones being H264 and AAC. Nobody published the needed protocol extension "enhanced RTMP" until 2022 and it still isn't supported widely. RTMP is not a generic container for any codec, like Mastroska - RTMP is tightly coupled to the codec.
Also the fact that hardware-accelerated AAC and even full AAC offload is ubiquitous in modern-ish hardware. I think my rice cooker can play AAC audio
No one really offloads AAC, apart from Apple. Opus can be decoded on very cheap microcontrollers entirely in software using the reference library.
2 replies →
Sample accurate editing is with AAC is a pain though. Especially if you also have video, because frame rates are usually incompatible.
If you want flexibility without fully transcoding both audio and video, Opus is your friend
Opus is your friend as long as the software you’re using supports it—besides, Apple’s AAC-LC can beat out Opus in low bitrates scenarios.
Whether you like it or not, AAC is still the standard.
I think often of how all it would have taken was a bomb for the 10 or so people that years ago at some browser vendor consortium out of pure self centeredness went „nah lets fragment“. We could have saved many many collective years, electricity and eyeballs simply watching the most basic content.
At one point in I think 2012 three of us who normally all live in different countries were riding in the same car in Australia. We advised the driver to be extra careful (she was dating one of us, so incentives were aligned).
But it is nice to hear that you have been thinking of us, too.
I think the biggest issue with Opus is the problem with its specification being lacking, see:
https://nothings.org/stb/stb_opus.html
This essentially causes opus to never be used in games or in things in stores that may have issues with specific licenses.
That’s going a bit far. I’m in the games industry and have used opus regularly, it’s a great codec for games, often the hardware decoding is so restricted that we’re using software regardless so we might as well use something like opus.
The licensing restriction is unfortunate, but only restrictive for those with very specific goals, under normal conditions BSD is a wonderful license for game devs since you’re free to use the code and only have to add an acknowledgement somewhere.
I suppose a public domain game might hit the same limitation, though as a non-lawyer I would guess the chance of anyone with standing trying to sue anyone implementing from this spec is realistically zero (though I don’t fault stb for being unwilling to roll those dice!)
> under normal conditions BSD is a wonderful license for game devs since you’re free to use the code and only have to add an acknowledgement somewhere.
And it's not as though libopus is an outlier in using a BSD license. A lot of other commonly used libraries have similar licenses; a few examples that come to mind which are likely to show up in games are zlib, curl, Lua, and SDL.
1 reply →
This essay says it's not possible to make a public-domain implementation of Opus. But it could be released under BSD (as libopus is), which is fine for games, as evidenced by the Licenses section of the credits in many games.
Most games use the sound support that comes with their game engine or choice of sound system, so I don't think the lack of an STB version is an issue. Performance is more of a problem. Audiokinetic, the makers of the popular Wwise audio system, estimate that Opus takes ~3-5x the CPU of Vorbis:
https://www.audiokinetic.com/en/community/blog/a-guide-for-c...
Most of my collection is Opus 256K, the only downside is support. A lot of tools like Bliss/Roon don't support it :(
Choosing a lossy audio codec has become such a no brainer. Either use opus and be done with it or if for some reason opus cannot be used then use aac for compatibility with insane high bitrate for good quality without having to do research on what encoder and mode to pick.
Still having a good quality and default aac encoder is great. Though I don't get why it is mainly CBR.
Eh, I prefer Vorbis mostly because it's still competitive at transparent bitrates (esp. with Aotuv patches) and benefits from a much saner volume normalization spec (simply transfer RG 2.0 tags from the FLAC source): Xiph decided to exclude peak information from Opus' spec while adding that weird thing where album gain is stored in the format header and additional track gain in the metadata.
It also uses less battery on my Rockbox'd Clip+.
For replaygain purposes simply ignore the spec and use RG 2.0 tags? That works with Opus too and hardly any players support Opus R128 gain anyway. For very low spec devices Vorbis would do a bit better though. For legacy devices legacy codecs can be a better fit indeed.
But would you really store new material encoded in Vorbis just to be able to play it on an old device? Vorbis can sound fine, even at lower bitrates like 128k or 96k, but Opus would sound much better. So perhaps then use Vorbis at higher bitrates like +192k? I prefer Vorbis to Aac but at that bitrate minor intricacies of the container format become more important than the codec because audio quality wise they are near indistinguishable.
[flagged]
> Falser words hath never been spoken.
Why? Care to explain?
I have fully switched to opus for lossy since I cannot be bothered to find the sweet spot for aac encoders and bitrate. Opus simply is too good and convenient and has been for ages.
What other lossy codec is better and for what reason? Under what circumstances and use cases? I really need put effort in looking for edge cases to not choose opus.
Aac is good too, but way too many choices to make for storing mass material for the long term and be sure the quality is always good enough.
1 reply →
Since you didn't detail your objection, I assume you're angry at the idea of choosing a lossy codec. Parent comment means that if one is to choose a lossy codec, the choices are simple.
I would like Opus, but I’m using a subsonic client on iOS and my choice has been Flac (Alac?), MP3, or AAC. Opus wouldn’t play (There are some that supported it, but I didn’t like their UX).
You might like Poppy (in beta), which supports all media servers (including OpenSubsonic/Navidrome) and Opus as a first-class music format. https://www.reddit.com/r/PoppyApp/comments/1tiyki0/about_pop...
> Man what a showcase for Opus this is.
I take it you mean this Opus (https://en.wikipedia.org/wiki/Opus_(audio_format)) not that Opus (https://en.wikipedia.org/wiki/Claude_(AI)).
I read almost all the way through your comment thinking there was a decent probability you were saying this new AAC encoder was written with Claude Opus.
I've never been AI guy, and have more fascination with audio. I've long stopped being excited when I read "Opus" on HN. It's refreshing when it turns out to be the audio codec.
To be fair, Opus was never a great name. I always feel the need to specify further when using it outside of a clear context of music codecs (also way before Claude was announced). Love it in every other way though
No, he was talking about the Opus Dei because this code quality can only be reached by God himself /jk