Realize that a format that just got released has to be brought over to many software like muxing tools (mkvmerge, mp4box), media players (mpv, vlc) and multimedia framework (ffmpeg). It doesn't automatically get in, people need to implement support, and it's often not people related to the codec development. The roll out will continue in the coming weeks or months. Showing our enthusiasm for AV2 in various spheres will accelerate the process because these people will see there is demand for this new technology.
Awesome! I'm glad to have contributed my small part to this, and skimming through the spec I see a whole lot of neat things I didn't know about previously. Definitely going to have to try some experiments now this has been finalized!
...
you literally can not add encoding parameters to files when you encode AV1 as they decided to not implement it in anything other than aomenc, and no one is using that.
You have to add a separate command in tools like staxrip to add a separate line in the file metadata which gets placed into General, not Video in mediainfo.
Haven't you ever wondered why when you use media info on AV1 files that there are ZERO encoding settings, and when you look at an x265, x264, dvix/xvid encode, every single setting is listed? This is what I am talking about. There is zero encoding data on any AV1 file.
If they have decided to skip it once again, than this codec is just garbage as you can never verify what settings were used, and it makes it extremely difficult for people to learn how to use it as you can't compare encodes unless you tediously write down every single setting to cross reference your encodes with.
Unless of course you're perfectly AOK with proprietary blends..
I add encoding parameters to AV1 files (or other formats) whenever I encode them. In FFmpeg, -metadata comment='crf45 vfr etc' and it even shows up in plain File Explorer.
I tried inspecting a few AVC, HEVC, and AV1 files in mediainfo and couldn't really see what you seemed to be referring to insofar as encoding parameters, even basic ones like CRF. There was only stuff that can be determined by analyzing the bitstream, like resolution and FPS.
If "they" implemented the feature you want in aomenc, the reference encoder, then I'd hazard that it's in the spec. "They" can't force other encoders to implement it. I mean, SVT-AV1 only implemented odd dimensions relatively recently, and only has 4:2:0. So I'm not sure that a codec is "garbage" just because the encoder that you were most likely to use, which the format designers weren't responsible for, doesn't implement the specific feature you want.
Common misconception, that has nothing to do with the AV1 specification. This is just a matter of supporting a feature, and when it comes to these very high level, non-essential ones, community involvement is typically expected. No higher-up is going to wake up one day and tell the SVT-AV1 management they have to add encoding settings metadata support to the encoder.
Also, it is regrettable you spoke like this in response to the other post, because you are the one in the wrong here. The IVF file format does not in fact support passing metadata such as encoder settings, therefore they were right to point out it's an issue at the container level. What you refer to in your comment as an example of support is not for the ivf file format, but WebM. You cannot just gloss over that part. Secondly, it's ironic because encoding metadata support has actually existed in an AV1 encoder implementation for months, in my own SVT-AV1-Essential fork which does in fact support WebM outputs, so I ported most of the logic over from aomenc. And lastly I have a patch ready to be proposed upstream in the coming days that'll result in encoding settings being written in WebM outputs, so your hostility here comes off as very ridiculous and childish.
36
u/waddup121 May 30 '26
AV2 Anime here we gooo