M4A metadata did not correct indicate VBR

[Xafg]

ffmpeg -i sample.mp3 -acodec libfdk_aac -vbr 3 -ac 2 out.m4a

​https://video.stackexchange.com/questions/32941/ffmpeg-libfdk-aac-vbr-wrong-bitrate-mode

Hello, I have the same problem as in the post from the link, namely libfdk_aac in vbr mode shows in mediainfo that it is constant bandwidth mode, I have seen the problem on several forums but it has not been solved yet

[MasterQuestionable]

͏    See also: ​https://trac.ffmpeg.org/ticket/11303

͏    ----

͏    I guess such may not be considered real bug:
͏    Similar to most PNG encoders wouldn't properly write the exact prediction (pre-filter) method used for the image, in that innocuous meta. [1]
͏    Mostly just per format requirement blindly indicated as "Adaptive" disregard.
͏    See also: ​https://trac.ffmpeg.org/ticket/11002
[ [1]
͏    The data wouldn't be actually used by the decoder. Though required by format...
͏    And likely impossible to really indicate the exact prediction used:
͏    As each scanline may actually use different prediction method...
͏    See also: ​https://www.w3.org/TR/PNG-Filters.html ]

͏    The same situation also occurs for the frame rate meta of various videos:
͏    The claimed FPS in meta typically somewhat mismatches the actual frame display.
͏    In particular for VFR (Variable Frame Rate).

[Xafg]

-c:a libfdk_aac -b:a 128k -vbr 3 with this setting generates variable bitrate to mp4 container, however if I remove -b:a 128k it goes back to constant mode. And I think it applies to every container

[Xafg]

-c:a libfdk_aac -b:a 128k -vbr 3 with this setting generates variable bitrate to mp4 container, however if I remove -b:a 128k it goes back to constant mode. And I think it applies to every container

[Balling]

True constant bitrate is achieved in native encoder with special option.

​https://patchwork.ffmpeg.org/project/ffmpeg/patch/517a57ef18398a39952fcc1d02e51ef423cf80ae.1726262133.git.pav@iki.fi/

"however if I remove -b:a 128k it goes back to constant mode." It does not. This is just metadata issue. Avg_bitrate must be lower than max_bitrate.

[MasterQuestionable]

͏    "I think it applies to every container"
͏    Uncertain.
͏    Probably some don't store alike pointless things outright...

[Xafg]

Gentlemen, I know that this may not be the right place, but I discovered the problem while making a script for vod for a client, I noticed that yt uses a variable data rate. Maybe someone of you knows which codec and what settings yt uses? And can I reproduce the same encoding model that yt has on ffmpeg. Thanks for any help

[MasterQuestionable]

͏    ​https://bugzilla.mozilla.org/show_bug.cgi?id=1892185#c1
͏    Try `yt-dlp -F`.

͏    YouTube primarily uses Opus.
͏    And mostly default tune for most content.

͏    See also:
͏    https://ffmpeg.org/ffmpeg-codecs.html#libopus-1
͏    ​https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio#Encoders
͏    ​https://trac.ffmpeg.org/ticket/10343

͏    ----

͏    Video is typically VP9. (currently also AV1 for certain high-res)
͏    Fallback with H.264.

͏    Exact tune uncertain. But probably not much special.
͏    For reference:
͏    ​https://wiki.x266.mov/docs/encoders/vpxenc#vp9
͏    ​https://old.reddit.com/r/AV1/comments/k7colv/encoder_tuning_part_1_tuning_libvpxvp9_be_more/?sort=old
͏    ​https://www.google.com/search?hl=en&gl=ca&num=100&q=site:reddit.com+intitle:%22Encoder+tuning+Part%22+%22BlueSwordM%22

͏    More on VP9, WebM, Matroska etc.
͏    ​https://trac.ffmpeg.org/ticket/10829#comment:4

[Balling]

I mean this is fixed in 944212acad7c2254d9dc14764b29e0023aaa645a and 46c6ca3ed1651c67faf899776f1922c108093a44, see #11303.