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

FFmpeg 9.1's new AAC encoder

hydrogenaudio.org

Post reply on HN
Print view View original

91–100 of 162 posts

Re: FFmpeg 9.1's new AAC encoder

#91

Post by someonebaggy »

ndiddy wrote: post #20
cogman10 wrote: post #16

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 i…

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.

Re: FFmpeg 9.1's new AAC encoder

#92

Post by Aachen »

dang wrote: post #6
ledoge wrote: post #4

Earlier quoted context omitted.

It doesn't let me edit the link, but I'm confused by what even happened here... I posted this from my phone and that wrong link doesn't show up in my clipboard history. Link should be: https://hydrogenaudio.org/index.php/topic,129691.0.html

It's fixed now. Our software follows redirs and somehow we got a 302 to our own IP. Perhaps it is someone's idea of a bot detector?

Unrelated: Hey, I sent hn@ycombinator.com two emails. One was May 6th, the other June 18th (UTC+2). The former's subject is "Broken prev/next links sometimes". In the latter, I've asked to let me know if it arrived. It didn't bounce so your email server has acknowledged receipt, but based on fast responses to previous emails and someone else mentioning randomly that you responded quickly to theirs in iirc early June, I'm starting to assume you're not seeing mine. I don't know how else to reach out than via an off-topic comment or a dummy submission or so. Is there a fallback mechanism to use when your email doesn't?

Re: FFmpeg 9.1's new AAC encoder

#93

Post by ant6n »

JSR_FDED wrote: post #59

It’s fascinating so much of this comes down to the developer’s own ears - disturbing and quite cool at the same time how subjective this is

The table and comparison uses “Google's new Zimtohrli, ViSQOL, and my own hearing”

Re: FFmpeg 9.1's new AAC encoder

#94

Post by someonebaggy »

atoav wrote: post #12
superzazu wrote: post #8

> The encoder was mainly optimized for 48Khz audio. Get over it. It's 2026, resampling is free, 48Khz is the standard. 44.1Khz will work, and so will 96Khz but use 48Khz if you want the best quality. Is 48kHz really the standard nowadays?

More or less. Streaming is often done with 48, video content has ben 48 for a while now, so unless you still produce content for CDs it is the standard. 44100 Hz had reasons no longer really needed (storing audio in 3 samples per line in VHS: 490 lines × 3 samples × 30 GPS = 44100 sample/s). Qualitywise both are more than enough snd 99.99% of people would not be able to tell it apart in a blind test. Higher sample ra…

VHS doesn't store audio in samples nor does it have 490 lines or 30 G(?)PS. NTSC uses 525 lines per frame and PAL uses 625, both with interlacing at 60 fields per second. The VHS system is analog for audio and video, though analog video has discrete lines, and VHS records discrete stripes on the tape which should be one field each.

44100 was chosen for CD, as 20kHz upper limit of human hearing, doubled for Nyquist theorem, plus a 10% guard band so that anti-aliasing filters don't have to be made of magical fairy dust, plus a bit (maybe to make it relatively prime with something else in the system).

Re: FFmpeg 9.1's new AAC encoder

#95

Post by pseudosavant »

I applaud a new/better FFMPEG AAC encoder, but there are two pretty massive caveats that are mentioned in the specifics that need to be called out:

- CBR only

- Only optimized for 48khz sampling

Not being able to do quality-based variable bitrate encoding is a major gap, and since all of the CD audio in the world is at 44.1k sampling, that seems like a huge miss too.

Re: FFmpeg 9.1's new AAC encoder

#96

Post by unethical_ban »

ksncksmckwkf wrote: post #42
jck86 wrote: post #28

Earlier quoted context omitted.

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.

[flagged]

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.

Re: FFmpeg 9.1's new AAC encoder

#97

Post by pezezin »

palmotea wrote: post #21
cogman10 wrote: post #16

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.

> 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.

No, he was talking about the Opus Dei because this code quality can only be reached by God himself /jk

Re: FFmpeg 9.1's new AAC encoder

#98

Post by SideQuark »

ant6n wrote: post #80

This is truly a representative of the old internet: somebody codes up the best AAC encoder ever, and the first response comes from some admin, and it's some bickering about 48Khz vs 44Khz.

It’s not that cynical. The author didn’t test on the most common rate in use, so it would be ludicrous for any serious project to wholesale replace a decades old working pipeline with it. It makes perfect sense to wait till due diligence is done.

Re: FFmpeg 9.1's new AAC encoder

#99

Post by pezezin »

someonebaggy wrote: post #94
atoav wrote: post #12

Earlier quoted context omitted.

More or less. Streaming is often done with 48, video content has ben 48 for a while now, so unless you still produce content for CDs it is the standard. 44100 Hz had reasons no longer really needed (storing audio in 3 samples per line in VHS: 490 lines × 3 samples × 30 GPS = 44100 sample/s). Qualitywise both are more than enough snd 99.99% of people would not be able to tell it apart in a blind test. Higher sample ra…

VHS doesn't store audio in samples nor does it have 490 lines or 30 G(?)PS. NTSC uses 525 lines per frame and PAL uses 625, both with interlacing at 60 fields per second. The VHS system is analog for audio and video, though analog video has discrete lines, and VHS records discrete stripes on the tape which should be one field each. 44100 was chosen for CD, as 20kHz upper limit of human hearing, doubled for Nyquist th…

The parent comment is talking about this: https://en.wikipedia.org/wiki/PCM_adaptor

The first digital audio systems encoded the audio as a black-and-white video signal on video tapes. 44100 HZ was selected at it was the highest sampling rate achievable on both NTSC and PAL video tapes.

Re: FFmpeg 9.1's new AAC encoder

#100

Post by nulld3v »

philistine wrote: post #84
lesscraft wrote: post #52

Earlier quoted context omitted.

No one really offloads AAC, apart from Apple. Opus can be decoded on very cheap microcontrollers entirely in software using the reference library.

On a microcontroller doing nothing else sure. But on a phone, a tablet, a laptop, you absolutely want hardware decode to preserve your battery life.

That's their point though. Basically no modern phone/laptop/tablet other than Apple offloads audio decoding (of any codec) to hardware. You can check this on Android phones by installing the Codec Info app.
Post reply on HN