Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
![]() |
|
Thread Tools | Search this Thread | Display Modes |
![]() |
#1 | Link |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Definitive link for AOM AV1 encoder parameter documentation?
I spent some time trying to find the definitive link for description of what the myriad AV1 encoder options do. Most seem to be common across implementations.
I found https://github.com/master-of-zen/Av1...ders/aomenc.md and https://ffmpeg.org/ffmpeg-codecs.html#librav1e. But where is the definitive kept-current source of that information? |
![]() |
![]() |
![]() |
#2 | Link |
Registered User
Join Date: Aug 2019
Posts: 16
|
Best I could find is the SVT-AV1 encoder guide. Might be relevant to aomenc too, since SVT-AV1 and aomenc share many setting.
|
![]() |
![]() |
![]() |
#3 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
I hope someday there will be an AV1 equivalent of https://x265.readthedocs.io/en/master/cli.html. Which is the best encoder documentation that I've not written myself ![]() |
|
![]() |
![]() |
![]() |
#4 | Link | |
Registered User
Join Date: May 2009
Posts: 331
|
Quote:
|
|
![]() |
![]() |
![]() |
#5 | Link | |
Huba Huba
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
|
Quote:
https://www.reddit.com/r/AV1/comment...thesis_how_it/ https://www.reddit.com/r/AV1/comment...cav1libaomav1/
__________________
"The innocent have nothing to fear" :stupid: |
|
![]() |
![]() |
![]() |
#6 | Link |
Registered User
Join Date: May 2009
Posts: 331
|
And still no documention as to why AV1 doesn't respect --threads. No matter what I do I can not get it to use more than 1 thread.. I would love to use the encoder, but there is still too much "magic" or "try settings and figure it out yourself" and when it's single threaded (because I can't get --threads to work on any builds, maybe I'm cursed!), that takes far, FAR too long. Maybe I'm spoiled because of the awesome documentation that x265 and x264 had.
|
![]() |
![]() |
![]() |
#7 | Link |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
I suppose it is the Modern Way of Things, but I really appreciate a description of what parameters do with input from the people who implemented it. "Read the source" is gallows humor, not an actual plan
![]() Although only Media Cleaner Pro's manuals and the x265 readthedocs have really met that bar in the last 25 years. And those projects happened because the project leaders personally took responsibility to write a lot of the documentation themselves. The CEO of Terran Interactive (who made Media Cleaner Pro) liked to do product planning by writing the manual for the new version and having the developers implement that. |
![]() |
![]() |
![]() |
#8 | Link |
Registered User
Join Date: May 2009
Posts: 331
|
Yes. I think it is pretty stupid that all these companies want to make this the next big codec, but are refusing to explain to people how to use it. I guess it's just more proof that AV1 was never intended for the masses, and was just a way for the media cartels to stop paying royalties, like Disney is attempting to do with authors.
|
![]() |
![]() |
![]() |
#9 | Link | ||
Huba Huba
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
|
Quote:
Quote:
__________________
"The innocent have nothing to fear" :stupid: |
||
![]() |
![]() |
![]() |
#10 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
|
|
![]() |
![]() |
![]() |
#11 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
There's no doubt that, with a good Film Grain Synthesis implementation, AV1 can outperform HEVC for grainy content at lower bitrates. But that's really the only case where I've seen a reliable reduction in bitrate versus HEVC when compared at the same bitrate and encoding time. And the FGS implementations aren't quite to the point where they can be used automatically, but that's orthogonal to codec bitstream itself, and I believe will be continuously improved. Of course, the FGS being orthogonal, decoders which support it with AV1 could easily support FGS for HEVC and VVC too. I quite like the AV1 FGS implementation, and is probably technology that will be reused in other contexts. It's certainly much better than the H.264 FGS model that was available with HD-DVD players (although never used in any actual discs AFAIK). |
|
![]() |
![]() |
![]() |
#12 | Link | |
Registered User
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
|
Quote:
|
|
![]() |
![]() |
![]() |
#13 | Link | |
Registered User
Join Date: May 2009
Posts: 331
|
Quote:
Thank you. |
|
![]() |
![]() |
![]() |
#14 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
And I imagine some implementations would add frame-level or other kinds of threading. With a single definitive resources for aomenc, other encoders could explain their changes relative to that so we could actually track what's happening. Self-documenting code is a myth, and doubly so in compression. |
|
![]() |
![]() |
![]() |
#16 | Link |
Registered User
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
|
I agree with the problem statement. I just don't think it's easily solved. I try to help with individual questions as I did here, but anything more than that would probably require much more effort than I'm willing to put into it... Libaom lacks the activist/enthusiastic volunteer contributor community that x264 had back in the day.
--tile-columns=N means exp2(N) tile columns, and --tile-rows=M means exp2(M) tile rows. So, values of 0,1,2,3,4 for either one would imply 0,2,4,8,16 tile columns or rows. The total number of tiles in a file is equal to tile_rows * tile_columns, so to get 4 tiles, you can use 2 tile columns and 2 tile rows (--tile-columns=1 --tile-rows=1), or 4 tile columns and 1 tile row (--tile-columns=2 --tile-rows=0), or 1 tile column and 4 tile rows (--tile-columns=0 --tile-rows=2). |
![]() |
![]() |
![]() |
#17 | Link |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
The readthedocs.io system that is used for x265 documentation looks reasonably simple to get an outline in and fill out as needed. It used to allow user editing, which would be appropriate here.
https://x265.readthedocs.io/en/master/ It didn't start anything close to as comprehensive as that. |
![]() |
![]() |
![]() |
#18 | Link | |
amd & h.264 fanboy
Join Date: Jun 2002
Location: NTSC
Posts: 420
|
Quote:
give it time, however. x264 didn't have great documentation within the first couple of years, either, IIRC. Last edited by plonk420; 25th June 2021 at 18:58. |
|
![]() |
![]() |
![]() |
#19 | Link | ||
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Too much codec documentation, including AV1's, is largely just restating the name of the parameter. What's really useful is to explain the qualitative and quantitative impact of a giving setting or its parameters. Stuff like "increases encoding time by 10-25% and reduces bitrate 1-3% for content with lots of sharp edges, like text and cel animation. Has little impact on natural image film and video content. Parameter X and Y also are helpful with similar content" I can read the documentation and guess what it might have been done. But each feature is in there based on testing and tuning, and sharing the results of that is very helpful. And also indicating features and parameter ranges that haven't been tested well. The linked posts on film grain synthesis and general recommendations are great reading, and would make lovely deep-dive essays as part of documentation. But each parameter deserves a few hundred of words about it specifically. For an example from the ffmpeg documentaiton Quote:
Just reading that, my first guess would be "2x keyint for optimal VoD quality" but that could be wildly wrong. And I don't know if that would increase compute or memory use by 10x or 10%. |
||
![]() |
![]() |
![]() |
#20 | Link | |
Registered User
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
|
Quote:
However, on the flip-side, this is used for adaptive/predictive encoding decision making, i.e. better quality and/or better quality/speed ratio (see "tpl" in various parts of the codebase, which means "temporal"). At minimum, this should be a few frames larger than the max. alt-ref frame group size (32? I think), but larger will be better (with diminishing returns). For real-time/low-latency coding, you can set this to 1, but it means no out-of-order frame coding. |
|
![]() |
![]() |
![]() |
|
|