Alliance for Open Media codecs

[mzso]

But I'd expect it'd take a couple of years before we have AV1 encoders that would match performance @ quality of today's best HEVC encoders.

And that's not even getting into rate control and psychovisual optimization, which can also take several years to get to a reasonable baseline, and keep on getting refined for the usage life of the codec. We are still seeing significant improvements in MPEG-2 encoders 20+ years in.

I hope not. These many large corporations should have lots of bodies to throw at optimizing, improving the encoder.

[benwaggoner]

I hope not. These many large corporations should have lots of bodies to throw at optimizing, improving the encoder.



That was true of HEVC, H.264, and MPEG-2. It always takes a couple of years from an essentially complete bitstream design to commercial grade encoders.


Sent from my iPhone using Tapatalk

[bstrobl]

That was true of HEVC, H.264, and MPEG-2. It always takes a couple of years from an essentially complete bitstream design to commercial grade encoders.


Sent from my iPhone using Tapatalk

It gets worse once you factor the insane amount of coding tools that can be used in a myriad of combinations. Simply getting all of the heuristics to figure that out is insane work.

I do expect the default encoder and decoder to be pretty decent with good support however. OPUS is doing a decent job with its default tools.

[benwaggoner]

It gets worse once you factor the insane amount of coding tools that can be used in a myriad of combinations. Simply getting all of the heuristics to figure that out is insane work.
Yeah, exactly my point. The efficiency gains of new codecs largely comes from the variety of new tools available, so getting the quality gains requires

I do expect the default encoder and decoder to be pretty decent with good support however. OPUS is doing a decent job with its default tools.
Decoders are way easier than encoders, thankfully. They work, or they don’t. And unlike VP9, we actually have some Profile/Level specs so we know what a particular decoder is required to do and thus what our encoders can be allowed to do.

I’m not sure how you’d define “pretty decent” - I would think it wouldn’t before end of year that AV1 has solutions that clearly outperform even x264 for high-volume scenarios. But yeah, desktop file-to-file conversion will work, and will produce good looking video. Speed is far from practical yet, but getting it to the ballpark of x265 speed at x264 quality is a reasonable 2018 goal.

Also, Opus is an audio codec: only one dimension! Audio codec optimization is important, but we’re talking 1-2 orders of magnitude less effort to get to a production-grade encoder than with a video codec. And we actually have good audio quality perceptually correlated metrics, which makes automated tuning and testing much more feasible and useful.

[mzso]

That was true of HEVC, H.264, and MPEG-2. It always takes a couple of years from an essentially complete bitstream design to commercial grade encoders.


Sent from my iPhone using Tapatalk

It seems like to me that HEVC and AVC mostly had patent trolls. Who were only interested in filling their pockets.

[benwaggoner]

It seems like to me that HEVC and AVC mostly had patent trolls. Who were only interested in filling their pockets.


DEFINITELY not mostly. Companies that really wanted to contribute to it so they could use the technology most joined the reasonable MPEG-LA pool.



Sent from my iPhone using Tapatalk

[IgorC]

And we actually have good audio quality perceptually correlated metrics, which makes automated tuning and testing much more feasible and useful.
Audio metrics are no better than any video metrics.
Both have flaws.

Final quality verification tests of absolutely every meaningful audio standard were made by testing ... on humans.

[Clare]

Experimental AV1 encoder in Rust: https://github.com/xiph/rav1e

I'll be adding new data to my comparator with a AV1 snapshot from 20180222, next week or so. I've changed the encoder parameters for more speed so I need to recalculate the old snapshots to have comparable data.

Also I added the PIK image format.

I also plan to do an actual video comparaison based on 30 short clips, VMAF metrics, AV1, X264, X265, and VP9. Gonna take a long while as I haven't written a single line of code yet and the encoding itself will be long.

Maybe AV1 will be bitstream freezed then. Latest estimate are: "AOM: Bitstream maybe March, maybe announce at NAB (early April)"
(https://www.nabshow.com/ from April 7th to April 12th)

[hajj_3]

I also plan to do an actual video comparaison based on 30 short clips, VMAF metrics, AV1, X264, X265, and VP9.

I hope you do comparisons at many resolutions e.g: 360p, 480p, 576p, 720p, 1080p, 1440p, uhd. A lot of the benchmarks shown so far comparing av1 to x264, x265 and vp9 either just show the overall difference or they show 360p, 720p and 1080p. I am more interested in the improvement of 360p-720p as x265 doesn't have that much improvement over x264 at those resolutions.

[Clare]

I hope you do comparisons at many resolutions e.g: 360p, 480p, 576p, 720p, 1080p, 1440p, uhd. A lot of the benchmarks shown so far comparing av1 to x264, x265 and vp9 either just show the overall difference or they show 360p, 720p and 1080p. I am more interested in the improvement of 360p-720p as x265 doesn't have that much improvement over x264 at those resolutions.

I plan to use objective1-fast https://people.xiph.org/~tdaede/sets/objective-1-fast/
It's a mix of 360p, 720p and 1080p. I don't have any 1440p or UHD content and I doubt my computer would be able to process it in a reasonable time. But I plan to release the Python scripts I use on Github so it will be usable on any dataset, like I did for images (https://github.com/WyohKnott/image-comparison-sources).

Or I need to buy a Threadripper… when I have lots of money and no taxes to pay.

[Clare]

objective2-slow https://people.xiph.org/~tdaede/sets/objective-2-slow/ has UHD content. Might be useful.

[LigH]

New upload: AOM v0.1.0-8231-gcb4622dee

[Tommy Carrot]

I'll be adding new data to my comparator with a AV1 snapshot from 20180222, next week or so. I've changed the encoder parameters for more speed so I need to recalculate the old snapshots to have comparable data.

Also I added the PIK image format.

Thanks for the comparisons.

The new AV1 blurs even more than the older ones. I know it's primarily a video encoder, so it's not really tuned for still images, but in its current form it's not really doing a good job as an image encoder.

However, PIK is really interesting. It basically behaves like a much more efficient JPEG. It has blocking and ringing artifacts, but preserves much more details than the other encoders. I sure prefer it over the artifactless, but sterile looking and blurry AV1 or HEVC images.

[Clare]

Thanks for the comparisons.

The new AV1 blurs even more than the older ones. I know it's primarily a video encoder, so it's not really tuned for still images, but in its current form it's not really doing a good job as an image encoder.

However, PIK is really interesting. It basically behaves like a much more efficient JPEG. It has blocking and ringing artifacts, but preserves much more details than the other encoders. I sure prefer it over the artifactless, but sterile looking and blurry AV1 or HEVC images.

I've just stumble onto that on Github: https://aomediacodec.github.io/av1-avif/

AV1 Still Image File Format (AVIF)

Overview

AVIF is a file format wrapping compressed images based on the Alliance for Open Media AV1 intra-frame encoding toolkit. AVIF supports High Dynamic Range (HDR) and wide color gamut (WCG) images as well as standard dynamic range (SDR). Only the intra-frame encoding toolkit is used in AVIF version 1.0. Using the intra-frame encoding mechanism from an existing video codec standard has a precedent in WebP: VP8, and HEIF: HEVC. This document describes at a high level a proposal on the structure of AVIF version 1.0.

The initial version of AVIF seeks to be simple, with just enough structure to allow the distribution of images based on the AV1 intra-frame coding toolset. At its core, AVIF 1.0 will allow for one or more images plus all supporting data needed to correctly reconstruct and display the images to be conveyed in a file. The ability to embed a thumbnail image will also be provided. An image sequence with suggested playback timing may be defined.

[bstrobl]

I've just stumble onto that on Github: https://aomediacodec.github.io/av1-avif/

The part where it says:

An AVIF file should be a simplified and conformant version of an [HEIF] file.

would imply this is basically HEIF with AV1 as still image codec, which is a sensible choice.


Not a big fan of the ringing artefacts in PIK, those bother me quite a lot more.

[mzso]

Thanks for the comparisons.

The new AV1 blurs even more than the older ones. I know it's primarily a video encoder, so it's not really tuned for still images, but in its current form it's not really doing a good job as an image encoder.

However, PIK is really interesting. It basically behaves like a much more efficient JPEG. It has blocking and ringing artifacts, but preserves much more details than the other encoders. I sure prefer it over the artifactless, but sterile looking and blurry AV1 or HEVC images.

I wonder why they bother with HEIF/ISOBMFF when AV1 is already webm/matroska centric.

[TD-Linux]

The new AV1 blurs even more than the older ones. I know it's primarily a video encoder, so it's not really tuned for still images, but in its current form it's not really doing a good job as an image encoder.


If you want to experiment, you can build an encoder with -DCONFIG_DIST_8X8=1 and then specify --tune=cdef-dist or --tune=daala-dist. These will optimize away from blurring and towards ringing.

[bstrobl]

Here is the buglist for the bitstream:

https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=Hotlist%3DAV1-Normative&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids

Presumably once all of those have been fixed the bitstream can be frozen.


Looks like everyone is working on weekends to get this thing done.

[hajj_3]

Here is the buglist for the bitstream:

https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=Hotlist%3DAV1-Normative&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids

Presumably once all of those have been fixed the bitstream can be frozen.


Looks like everyone is working on weekends to get this thing done.
not sure, I have been following this list: https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&sort=priority&num=100&start=0

It is down to 75 bugs, 2.5 weeks ago it was at 215 bugs so probably another 1-2 weeks or so until it is ratified.

[Clare]

I also plan to do an actual video comparaison based on 30 short clips, VMAF metrics, AV1, X264, X265, and VP9. Gonna take a long while as I haven't written a single line of code yet and the encoding itself will be long

I plan to use objective1-fast https://people.xiph.org/~tdaede/sets/objective-1-fast/
It's a mix of 360p, 720p and 1080p. I don't have any 1440p or UHD content and I doubt my computer would be able to process it in a reasonable time. But I plan to release the Python scripts I use on Github so it will be usable on any dataset, like I did for images (https://github.com/WyohKnott/image-comparison-sources).

So it was easier to code than I thought, with few changes from the image comparison.

It's up there: https://wyohknott.github.io/video-formats-comparison/

I haven't added AV1 yet, I'm waiting for the bitstream freeze.

Let me know what you think would be good to add. I put most of the graph I thouqgt would be useful. I wish I could addsome examples videos to plày side by side but I don't know how to do that.

[Jamaika]

Each Y4M videos is exported to 4:2:0 10 bits Y4M with FFMPEG:

ffmpeg -y -i [input] -pix_fmt yuv420p10le -strict -1 [output]
Video compression
All videos are compressed over a range of qualities for each encoder:
•AV1:
◦between q=12 and q=60, with a step of 4:

aomenc --cpu-used=2 --tile-columns=4 --passes=2 --pass=1 --bit-depth=10 --input-bit-depth=10 --end-usage=q --cq-level=$q --fpf=[output].log -o [output] [input(Y4M_10bits)]

aomenc --cpu-used=2 --tile-columns=4 --passes=2 --pass=2 --bit-depth=10 --input-bit-depth=10 --end-usage=q --cq-level=$q --fpf=[output].log -o [output] [input(Y4M_10bits)]

•VP9:
◦between q=12 and q=60, with a step of 4:

vpxenc --tile-columns=4 --row-mt=1 --passes=2 --cpu-used=2 --bit-depth=10 --input-bit-depth=10 --profile=2 --end-usage=q --cq-level=$ -o [output] [input(Y4M_10bits)]

•x264:
◦between q=12 and q=40, with a step of 2:


x264 --profile high10 --preset slower --input-depth=10 --output-depth=10 --crf $q -o [output] [input(Y4M_10bits)]

•x265:
◦between q=12 and q=40, with a step of 2:


x265 --profile main10 --preset slower --input-depth=10 --output-depth=10 --crf $q -o [output] [input(Y4M_10bits)]
My ideas:
ffmpeg.exe -loglevel verbose -i "[input(your_colorspace).raw]" -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=full:out_color_matrix=bt2020_ncl:out_range=full,format=yuv422p10le -strict -1 -
ffmpeg.exe -loglevel verbose -i "[input(your_colorspace).y4m]" -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=S_gamut3:in_range=full:out_color_matrix=bt2020_ncl:out_range=full,format=yuv422p10le,lutyuv=val:val:val -strict -1 -
aomenc.exe --bit-depth=10 --input-bit-depth=10 --i4?? --codec=av1 --good --threads=? --cpu-used=? --profile=3 --drop-frame=(0 or 100 depends on fps) --end-usage=q --cq-level=48 --target-bitrate=0 --min-q=?(the problem bitrate of the first frame)
--kf-max-dist=GOP --auto-alt-ref=? --frame-boost=? --aq-mode=0 --color-space=bt2020 --verbose --debug --pass=? --passes=? --output="xxx.webm" - (where is range full?)

x264.exe --demuxer y4m --input-csp i4?? --input-depth 10 --input-range pc --output-csp i4?? --threads ? --preset slow --tune grain --crf 28 --fps ??.??? --keyint 60 --nal-hrd none --vbv-bufsize 40000 --vbv-maxrate 40000(use for web or don't use)
--colormatrix bt2020nc --colorprim bt2020 --transfer bt2020-10 --range pc --output "xxx.h264" -

[o-l-a-v]

It's up there: https://wyohknott.github.io/video-formats-comparison/
You are linking to PIKs github page for x265.

"x265: https://github.com/google/pik. The version used is built from GIT revision 3cf3839f82bb177c43449ab10792c184c4485d8b"

[Tommy Carrot]

So it was easier to code than I thought, with few changes from the image comparison.

It's up there: https://wyohknott.github.io/video-formats-comparison/

I haven't added AV1 yet, I'm waiting for the bitstream freeze.

Let me know what you think would be good to add. I put most of the graph I thouqgt would be useful. I wish I could addsome examples videos to plày side by side but I don't know how to do that.
Nice.

I think XVC encoder could be interesting to see. I know it's a proprietary codec, but quality-wise, in my experience, it competes quite well with x265 and AV1.

[clsid]

Does anyone have a link to a sample file that was encoded by a recent build?

[LigH]

Just for you :o ... I created a "samples" subdirectory in my AOM (https://www.mediafire.com/?21254ingvippg) MediaFire folder; it contains a WebM clip of "foreman" in PAL CIF resolution (https://www.mediafire.com/file/byqa843j4im70s4/foreman_cif_AV1_0.1.0-8300-g088217b2e.webm), encoded with AOM encoder v0.1.0-8300-g088217b2e (http://www.mediafire.com/file/3b7n762y852rxvh/aom_v0.1.0-8300-g088217b2e.7z) (built Feb. 27, I hope that's recent enough) with '--cpu-used 8' (supposed to be a faster preset). Encoding took 3/4 hour on this aged PC with AMD Phenom-II (max. SSE2).

Tomorrow I could try a newer one with faster hardware.

[LigH]

A few more uploads: AOM v0.1.0-8449-g6471e8bd7 and samples with "--cpu-used [8..4]" to compare speeds (encoded on an AMD FX-6300). Disillusioning... :(

Pass 2/2 frame 300/300 469809B 12528b/f 313206b/s 769973 ms (0.39 fps)
Pass 2/2 frame 300/300 460022B 12267b/f 306681b/s 841144 ms (0.36 fps)
Pass 2/2 frame 300/300 449454B 11985b/f 299636b/s 921242 ms (0.33 fps)
Pass 2/2 frame 300/300 448798B 11967b/f 299198b/s 1044732 ms (0.29 fps)
Pass 2/2 frame 300/300 448035B 11947b/f 298690b/s 1214326 ms (0.25 fps)

Reminding you, PAL CIF resolution (352×288). Due to the small video, only 1 thread was active.

[hbbs]

Sorry, I am fairly new to this.

But which player are you using to play this samples?

I have tried the latest vlc stable to no avail.

Couldn't play the codec "av01" (AOMedia's AV1 Video)

[clsid]

Thanks LigH.

The AV1 format has not been finalized yet. Once that is done, you can expect players to quickly adopt it.

[LigH]

There is probably no player available yet. You can only use aomdec to decode to Y4M and play this decoded raw video, AFAIK.

[Tommy Carrot]

Thanks for the new build.

Despite all the SIMD optimizations and other improvements, this build is actually even slower than build #8039. The quality seems visually very similar, the metrics as well. I was curious what AV1 is capable of with all the compression tools enabled, so i tried --cpu-used=0 on a 50 frames long, 720*288 video. It took almost 6 hours to encode. :)

[clsid]

I have a patch for MPC-HC/LAV/FFmpeg but it is not fully working yet. Libaom outputs YUV420P for your sample video, but using a 16 bit framebuffer, which is normally only used for higher bitdepths.

[nevcairiel]

Work on support for libaom in FFmpeg is already underway, but it won't really be made available until the bitstream freeze.

[easyfab]

Firefox and chrome should also have the decoder in quickly After final bitstream

[Dope]

50 frames long, 720*288 video. It took almost 6 hours to encode.

Bloody hell.. Can someone make a realistic prediction as to how long it will take an optimized AV1 to encode exactly that sequence?
Thank you.

[2160p]

Bloody hell.. Can someone make a realistic prediction as to how long it will take an optimized AV1 to encode exactly that sequence?
Thank you.

What is the multi-core CPU distribution/load?

[dapperdan]

I think they were aiming for it to take longer than HEVC/VP9 but I'm not sure they let themselves get pinned down to anything more specific than "reasonable increases" in encoding time. I think Netflix said they'd roll it out internally once it was less than 5x HEVC encoding time, so I guess that's an upper bound.

[Dope]

What is the multi-core CPU distribution/load?

I'm running an i5 3570K@ 4500Mhz. I run all of my 1080p x265 encodes at no less than 1 FPS. This is with my lil bit customized "placebo" preset.
I just can't comprehend how a processor like this would encode some 50 360p frames even during 1 hour, let alone 6. This is insane.

[LigH]

There is a little cosmetical issue I reported (https://bugs.chromium.org/p/aomedia/issues/detail?id=1517) (aomenc displays ANSI escape sequences for cursor control, vpxenc does not).

:o I have never seen developers so speechless... :rolleyes:

[MoSal]

There is a little cosmetical issue I reported (https://bugs.chromium.org/p/aomedia/issues/detail?id=1517) (aomenc displays ANSI escape sequences for cursor control, vpxenc does not).

:o I have never seen developers so speechless... :rolleyes:

lol. Wait until they discover there is no byte sequence they can use to get this functionality in Windows cmd.

[clsid]

A sneak peek of the future...

http://i68.tinypic.com/15eeb5s.png

Before anyone asks, this isn't available until the bitstream specification is finalized.

[bstrobl]

not sure, I have been following this list: https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&sort=priority&num=100&start=0

It is down to 75 bugs, 2.5 weeks ago it was at 215 bugs so probably another 1-2 weeks or so until it is ratified.

That list contains all bugs for all parts including those not affecting the bitstream(stuff in the encoder/decoder themselves).

If you search in Monorail for "Hotlist=AV1-Normative", only bitstream bugs will be shown.

The codec is a bit rushed, hopefully no major or even minor bugs are left. Might have to use it for a very long time if it catches on and no major progress in codecs is being made :scared:

[bstrobl]

A sneak peek of the future...

http://i68.tinypic.com/15eeb5s.png

Before anyone asks, this isn't available until the bitstream specification is finalized.

320 x 240 ought to be enough for everyone :D. Although I am curious about low resolution performance. Countries with poor internet could massively benefit from receiving even tiny videos.

[mzso]

The codec is a bit rushed, hopefully no major or even minor bugs are left. Might have to use it for a very long time if it catches on and no major progress in codecs is being made :scared:

Let's hope they go down the deep end with novel and exotic ideas.

[bstrobl]

Let's hope they go down the deep end with novel and exotic ideas.

My guess is they will have to do that. Only so many gains can be made by increasing block sizes and motion direction etc. The next codec will probably be 10 years down the line so that should give enough time to rip out the old plumbing or simply start from scratch for a more radical new architecture. The Alliance will hopefully stay together for that period of time. A 50% efficiency gain on top of AV1 would be pretty nice, which would mean going from e.g. 800MB (MPEG2) -> 400MB (H264) -> 200MB (AV1) -> 100MB (AV2?) file sizes :)

[LigH]

@bstrobl:

PAL CIF = 352×288 (a common "Video CD" resolution). And ... I really don't understand how people still get so excited about miracolous bitrate reductions from one generation to the next, but for low resolution video; and even the subjective threshold how much loss of quality appears tolerable changed over the last decade (I doubt you would accept today what was acceptable in the VCD era, today you would complain about "retina cancer" with the same amount of artifacts).

Don't be afraid of available bandwidth. "Countries with poor internet" ... did you know that Estonia has better rural broadband coverage than Germany? UHD over the Web will be the future, globally – because its availability makes profit. Forget about CIF.

[Selur]

@all: Is there some documentation about the command line parametes of aomenc somewhere?
Looking at the output of 'aomenc --help' there a quite a few option without explanations about min/max values of the arguments or what the default argument is.
Usage: aomenc.exe <options> -o dst_filename src_filename

Options:
--help Show usage options and exit
-c <arg>, --cfg=<arg> Config file to use
-D, --debug Debug mode (makes output deterministic)
-o <arg>, --output=<arg> Output filename
--codec=<arg> Codec to use
-p <arg>, --passes=<arg> Number of passes (1/2)
--pass=<arg> Pass to execute (1/2)
--fpf=<arg> First pass statistics file name
--limit=<arg> Stop encoding after n input frames
--skip=<arg> Skip the first n input frames
--good Use Good Quality Deadline
-q, --quiet Do not print encode progress
-v, --verbose Show encoder parameters
--psnr Show PSNR in status line
--webm Output WebM (default when WebM IO is enabled)
--ivf Output IVF
--obu Output OBU
-P, --output-partitions Makes encoder output partitions. Requires IVF output!
--q-hist=<arg> Show quantizer histogram (n-buckets)
--rate-hist=<arg> Show rate histogram (n-buckets)
--disable-warnings Disable warnings about potentially incorrect encode settings.
-y, --disable-warning-prompt Display warnings, but do not prompt user to continue.
--test-decode=<arg> Test encode/decode mismatch
off, fatal, warn

Encoder Global Options:
--yv12 Input file is YV12
--i420 Input file is I420 (default)
--i422 Input file is I422
--i444 Input file is I444
--i440 Input file is I440
-u <arg>, --usage=<arg> Usage profile number to use
-t <arg>, --threads=<arg> Max number of threads to use
--profile=<arg> Bitstream profile number to use
-w <arg>, --width=<arg> Frame width
-h <arg>, --height=<arg> Frame height
--forced_max_frame_width Maximum frame width value to force
--forced_max_frame_height Maximum frame height value to force
--stereo-mode=<arg> Stereo 3D video format
mono, left-right, bottom-top, top-bottom, right-left
--timebase=<arg> Output timestamp precision (fractional seconds)
--fps=<arg> Stream frame rate (rate/scale)
--error-resilient=<arg> Enable error resiliency features
-b <arg>, --bit-depth=<arg> Bit depth for codec (8 for version <=1, 10 or 12 for version 2)
8, 10, 12
--lag-in-frames=<arg> Max number of frames to lag
--large-scale-tile=<arg> Large scale tile coding (0: off (default), 1: on)
--monochrome Monochrome video (no chroma planes)

Rate Control Options:
--drop-frame=<arg> Temporal resampling threshold (buf %)
--resize-mode=<arg> Frame resize mode
--resize-denominator=<arg> Frame resize denominator
--resize-kf-denominator=<ar Frame resize keyframe denominator
--superres-mode=<arg> Frame super-resolution mode
--superres-denominator=<arg Frame super-resolution denominator
--superres-kf-denominator=< Frame super-resolution keyframe denominator
--superres-qthresh=<arg> Frame super-resolution qindex threshold
--superres-kf-qthresh=<arg> Frame super-resolution keyframe qindex threshold
--end-usage=<arg> Rate control mode
vbr, cbr, cq, q
--target-bitrate=<arg> Bitrate (kbps)
--min-q=<arg> Minimum (best) quantizer
--max-q=<arg> Maximum (worst) quantizer
--undershoot-pct=<arg> Datarate undershoot (min) target (%)
--overshoot-pct=<arg> Datarate overshoot (max) target (%)
--buf-sz=<arg> Client buffer size (ms)
--buf-initial-sz=<arg> Client initial buffer size (ms)
--buf-optimal-sz=<arg> Client optimal buffer size (ms)

Twopass Rate Control Options:
--bias-pct=<arg> CBR/VBR bias (0=CBR, 100=VBR)
--minsection-pct=<arg> GOP min bitrate (% of target)
--maxsection-pct=<arg> GOP max bitrate (% of target)

Keyframe Placement Options:
--kf-min-dist=<arg> Minimum keyframe interval (frames)
--kf-max-dist=<arg> Maximum keyframe interval (frames)
--disable-kf Disable keyframe placement

AV1 Specific Options:
--cpu-used=<arg> CPU Used (0..8)
--dev-sf=<arg> Dev Speed (0..255)
--auto-alt-ref=<arg> Enable automatic alt reference frames
--sharpness=<arg> Loop filter sharpness (0..7)
--static-thresh=<arg> Motion detection threshold
--single-tile-decoding=<arg Single tile decoding (0: off (default), 1: on)
--tile-columns=<arg> Number of tile columns to use, log2
--tile-rows=<arg> Number of tile rows to use, log2 (set to 0 while threads > 1)
--tile-loopfilter-v=<arg> Enable loop filter across vertical tile boundary
--tile-loopfilter-h=<arg> Enable loop filter across horizontal tile boundary
--arnr-maxframes=<arg> AltRef max frames (0..15)
--arnr-strength=<arg> AltRef filter strength (0..6)
--tune=<arg> Distortion metric tuned with
psnr, ssim, cdef-dist, daala-dist
--cq-level=<arg> Constant/Constrained Quality level
--max-intra-rate=<arg> Max I-frame bitrate (pct)
--max-inter-rate=<arg> Max P-frame bitrate (pct)
--gf-cbr-boost=<arg> Boost for Golden Frame in CBR mode (pct)
--lossless=<arg> Lossless mode (0: false (default), 1: true)
--enable-cdef=<arg> Enable the constrained directional enhancement filter (0: false, 1: true (default))
--enable-restoration=<arg> Enable the loop restoration filter (0: false, 1: true (default))
--enable-qm=<arg> Enable quantisation matrices (0: false (default), 1: true)
--qm-min=<arg> Min quant matrix flatness (0..15), default is 8
--qm-max=<arg> Max quant matrix flatness (0..15), default is 15
--enable-dist-8x8=<arg> Enable dist-8x8 (0: false (default), 1: true)
--frame-parallel=<arg> Enable frame parallel decodability features (0: false (default), 1: true)
--aq-mode=<arg> Adaptive quantization mode (0: off (default), 1: variance 2: complexity, 3: cyclic refresh)
--deltaq-mode=<arg> Delta qindex mode (0: off (default), 1: deltaq 2: deltaq + deltalf)
--frame-boost=<arg> Enable frame periodic boost (0: off (default), 1: on)
--noise-sensitivity=<arg> Noise sensitivity (frames to blur)
--tune-content=<arg> Tune content type
default, screen
--cdf-update-mode=<arg> CDF update mode for entropy coding (0: no CDF update; 1: update CDF on all frames(default); 2: selectively update CDF on some frames
--color-primaries=<arg> Color primaries (CICP) of input content:
bt709, unspecified, bt601, bt470m, bt470bg, smpte240, film, bt2020, xyz, smpte431, smpte432, ebu3213
--transfer-characteristics= Transfer characteristics (CICP) of input content:
unspecified, bt709, bt470m, bt470bg, bt601, smpte240, lin, log100, log100sq10, iec61966, bt1361, srgb, bt2020-10bit, bt2020-12bit, smpte2084, hlg, smpte428
--matrix-coefficients=<arg> Matrix coefficients (CICP) of input content:
identity, bt709, unspecified, fcc73, bt470bg, bt601, smpte240, ycgco, bt2020ncl, bt2020cl, smpte2085, chromncl, chromcl, ictcp
--chroma-sample-position=<a The chroma sample position when chroma 4:2:0 is signaled:
unknown, vertical, colocated
--min-gf-interval=<arg> min gf/arf frame interval (default 0, indicating in-built behavior)
--max-gf-interval=<arg> max gf/arf frame interval (default 0, indicating in-built behavior)
--sb-size=<arg> Superblock size to use
dynamic, 64, 128
--num-tile-groups=<arg> Maximum number of tile groups, default is 1
--mtu-size=<arg> MTU size for a tile group, default is 0 (no MTU targeting), overrides maximum number of tile groups
--timing-info=<arg> Signal timing info in the bitstream:
unspecified, constant
--disable-tempmv=<arg> Disable temporal mv prediction (default is 0)
-b <arg>, --bit-depth=<arg> Bit depth for codec (8 for version <=1, 10 or 12 for version 2)
8, 10, 12
--input-bit-depth=<arg> Bit depth of input

Stream timebase (--timebase):
The desired precision of timestamps in the output, expressed
in fractional seconds. Default is 1/1000.

Included encoders:

av1 - AOMedia Project AV1 Encoder 0.1.0-8663-gaf35e318e (default)

Use --codec to switch to a non-default encoder.

So I'm wondering is there some documentation somewhere what all those parameters are for and what their values are?
Or is this simply still to early to expect a bit more detailed documentation?
Seeing that a few folks did some tests here I wonder how they chose the settings they used. (some parameters are kept from vpx, but quite a few are new)

Cu Selur

[LigH]

AOM v0.1.0-8698-gba7b8fe27

[colinhunt]

Thank you LigH for providing binaries. I did a little test yesterday, and noticed that it would take 4 hours to encode 1 second of 1080p60 footage. Am I guessing correctly there's no multithreading in the encoder yet? I noticed the -t parameter for number of threads, but setting it to 8-12 had no effect; aomenc kept running on a single core.

[LigH]

I only tested it with a tiny resolution so far, and blamed the low resolution for the lack of threading. If it doesn't use threading for larger resolutions either ... then it's not yet implemented, I guess. :o

[colinhunt]

^ Okay... might it be possible that -t parameter is referring to something else besides multithreading? Just trying to figure out if I messed something up.