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.
If you want flexibility without fully transcoding both audio and video, Opus is your friend
Whether you like it or not, AAC is still the standard.
Everyone I've seen complaining about slow choppy playback in DaVinci Resolve appears to be using long-GOP codecs which require a massive amount of processing to decode. It's something like playing out two seconds of video to access every single frame.
On Opus vs. AAC specifically, there's a long history of studies like https://www.researchgate.net/publication/301428302_Perceived... to help answer that question. (There are interesting charts at the top of page 1175.)
Yes, but not for high-bitrate music applications.¹ For example, Opus 1.2 really improved the quality of music encoding at 32–48 kbps. Opus doesn't have to be great at everything to be great at what it does, just like AAC-LC doesn't have to be. (¹Opus 1.6's experimental Opus HD looks very promising for this!)
Apple's and Fraunhofer's closed-source AAC-LC encoders have seen regular, minor quality tuning, and they benefit from the research and engineering work that have been done for the AAC family of encoders (HE-AAC for bitrates down to ~48 kbps, HE-AAC v2 to 32 kbps, xHE-AAC below that).
Not only is the new AAC Encoder also royalty-free, the AAC-LC codec itself has been declared by Redhat as patent free ( all patent expired ).
If the OS/platform doesn't use it that could be another thing, but those chips do offer audio coded decoding, including aac
Seems like Nvidia doesn’t support JPEG in NVDEC.
I’m not in this space anymore but as of Android 5-6 era aac and bt is offloaded to hexagon dsp on qualcomm device.
Traditionally Bluetooth audio meant decoding and reencoding it into a crappier codec before transmission. So it's an efficiency and quality win.
I think some Google Pixel Bud Pro earphones do this for Opus but that is rarer (there's a few other codecs that have been done like this over the years by different manufacturers).
But it is nice to hear that you have been thinking of us, too.
https://developers.google.com/youtube/v3/live/guides/ingesti...
YouTube serves vp9 but it always re-encodes my videos as AV1. Annoying.
(I would upload as AV1 but the encoder is slooooooooow.)
If you're using libaom, try switching to libsvtav1. It's still slow, but it's slooow instead of slooooooooow.
Still having a good quality and default aac encoder is great. Though I don't get why it is mainly CBR.
It also uses less battery on my Rockbox'd Clip+.
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.
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.
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!)
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.
https://www.audiokinetic.com/en/community/blog/a-guide-for-c...
The intent of the legal language in that spec is pretty clearly that you have to use the BSD license if you copy that code, but if you merely read it to understand the spec then you don't.
>Clean-room design is usually employed as best practice, but not strictly required by law.
As the article points out, if this was actually true then we could change the licensing on code examples found in RFCs to fix the issue, but there doesn't seem to be any actual issue here. Imagine a world where simply reading some code caused licensing issues...
Been around a lot longer than Claude Opus.
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.
You don’t need to be in the audio codec dev space to have heard of one of the most widespread audio codecs of the last decade (used by YouTube, WhatsApp, SoundCloud and added to WebM in 2013).
It just feels wrong when HN commenters downvote comments that try to clear up legitimate confusion.