Alliance for Open Media codecs

[dapperdan]

VP10 is not AV1. AV1 is built only in part on VP10, at least it's supposed to be. How much of it is from Daala or Thor or whatever I can't say.

I think it's fair to say that AV1 is VP10 at the moment. As tech or patents or coding contributions come from other parties now then it may grow to be something different, but as a starting point it was and mostly still is the libvpx VP10 codebase. At what percentage of code or ideas it stops being VP10 is of course debatable, and they certainly want to be a collaborative project going forward, but yeah, I don't think it's a misleading shorthand to say AV1 is VP10.

[Jamaika]

I think it's fair to say that AV1 is VP10 at the moment.
There was such a suggestion. Codec AOM replaces VP10, Daala, Thor, HEVC. Anyway what for they did to the alliance. VP10 disappears. I see that these are two paths of development, ie said Clare.
The AOM (Alliance of Open Media) codec is based upon VP10 (which is still in heavy development as a separate branch), but they will use any useful technology which their members have access to, for example if you look at the AOM branch, there are Daala features being added:

https://chromium-review.googlesource.com/#/q/project:webm/aom

I don't know if VP10 will actually materialise as a separate stable codec release or if it will be decprecated as it is the base of the AOM codec (depends on how long it will take to develop I guess).
It can and is based on the codec vp10, just don't know it or not version a few months ago.

[Quikee]

VP10 is not AV1. AV1 is built only in part on VP10, at least it's supposed to be. How much of it is from Daala or Thor or whatever I can't say.

Some things from daala and thor is in AV1 AFAICS - mainly the deringing filter (daala) and CLP filters (thor) are and multi-symbol entropy coder from daala (which might be replaced by rANS as it is faster and has similar efficiency) PVQ is still a WIP to integrate into AV1 - which might be quite interesting..

[Quikee]

Not sure how they are going to achieve a doubling of efficiency when compared to HEVC by 2017 however.

It may possibly be that they won't double the efficiency but just be marginally worse or better. It is much more important that they release a codec "soon" so they establish a base and offer a viable alternative to HEVC.

[mzso]

Some things from daala and thor is in AV1 AFAICS - mainly the deringing filter (daala) and CLP filters (thor) are and multi-symbol entropy coder from daala (which might be replaced by rANS as it is faster and has similar efficiency) PVQ is still a WIP to integrate into AV1 - which might be quite interesting..

So, no chance for lapped transformation from daala?

[mandarinka]

Some things from daala and thor is in AV1 AFAICS - mainly the deringing filter (daala) and CLP filters (thor) are and multi-symbol entropy coder from daala (which might be replaced by rANS as it is faster and has similar efficiency) PVQ is still a WIP to integrate into AV1 - which might be quite interesting..

I'm not sure Daala stuff is integrated in the sense that it is definitely going to land in the final format. They adapted it or are adapting it into the same codebase so that it can be evaluated at all. The tools will have to prove their worth and/or fight their way into it in the committees/politics/visions clashes :) Lots of stuff currently in the codebase will be dropped from the final format, likely.

If On2/Google has main say in development, they might hamper adoption of stuff from Mozilla/Xiph because NIH mentality. (Well, let's hope such pety things will be kept in check there, but people often tend to behave like that sadly.)

[mzso]

I'm not sure Daala stuff is integrated in the sense that it is definitely going to land in the final format. They adapted it or are adapting it into the same codebase so that it can be evaluated at all. The tools will have to prove their worth and/or fight their way into it in the committees/politics/visions clashes :) Lots of stuff currently in the codebase will be dropped from the final format, likely.

But, how will they finalize the format by 2017 like this?

[Quikee]

I'm not sure Daala stuff is integrated in the sense that it is definitely going to land in the final format. They adapted it or are adapting it into the same codebase so that it can be evaluated at all. The tools will have to prove their worth and/or fight their way into it in the committees/politics/visions clashes :) Lots of stuff currently in the codebase will be dropped from the final format, likely.

I never said any of it will be final in AV1 format - just that it currently is or isn't part of the AV1 codebase yet. Of course things that won't show gains (or show gains but increase complex too much) will probably be dropped.

If On2/Google has main say in development, they might hamper adoption of stuff from Mozilla/Xiph because NIH mentality. (Well, let's hope such pety things will be kept in check there, but people often tend to behave like that sadly.)

If they want inclusive development this won't happen. If there are two tools that have similar gain they will together decide which one to keep and which to drop (that's why they have regular meetings). IPR and what hardware vendors say would be a big factor in such a decision.

[Quikee]

So, no chance for lapped transformation from daala?

No, lapped transform is too invasive - they would need to change almost everything, which would not make sense to select VP10 as the base.

[wiak]

if anyone is interested i have a compiled win64 version here
https://awesome.nwgat.ninja/aomedia/av1-daf841b-win64.7z

[Jamaika]

:thanks:
Test hier (http://forum.doom9.org/showthread.php?p=1773771#post1773771)

[wiak]

another fresh build
https://f001.backblaze.com/file/nwgat-aom/av1-git-1195a39-win64.7z

[Jamaika]

The problem with dropframe (CBR) (http://forum.doom9.org/showthread.php?p=1774553#post1774553). This is a test version so I close my eye.;)

PS Will there be a link to all versions? ;)

[Jamaika]

Interesting article: disadvantages / advantages
vp9 vs av1 vs hevc

A view on VP9 and AV1 part 1: specifications (http://www.gpac-licensing.com/2016/07/12/vp9-av1-bitstream-format/)

PS Could gpac interested in the introduction of the codec google to the container mp4?

•There is no such thing as VP9 or AV1 File Format (AVC/HEVC has raw, Annex B, and canonical/MP4). One needs to use the IVF File Format or WebM.
There is no such thing as VP9 or AV1 because it must be given the name of the codec. IVF isn't a container. It is a labor saving by decoder. You can use the MOV container.
mkvextract.exe tracks vp9/av1.webm 0:output.ivf

[Nintendo Maniac 64]

There is in fact such a thing as a raw VP9 - that's what YouTube uses, but they still end in a .webm extension. The biggest difference I notice is that some programs just give visual garbage when playing back raw VP9 files yet work perfectly file with a "proper" VP9/WebM video - Avidemux and VLC come to mind.

[blurred]

There is a Wikipedia article:

https://en.wikipedia.org/wiki/AOMedia_Video_1

[wiak]

fresh build
https://f001.backblaze.com/file/nwgat-aom/av1-git-4c46278-win64.7z

[Jamaika]

Anyone can tell me what is aq-mode equator360?

[wiak]

Anyone can tell me what is aq-mode equator360?
something do do with youtube 3d mode? meybe a MVC competitor, dunno

PS: just asked on irc, lets see if i get a answer

[Blue_MiSfit]

Nice simple CLI.


aomenc --best --end-usage=vbr --target-bitrate=1000 --kf-max-dist=96 --width=1920 --height=1080 -o monkeys_1080p_1000.webm monkeys.yv12


This triggers an automated 2 pass encode.

Wow this is slow :D. The first pass ran at ~21fps on my 3.4 GHz quad core Skylake. The second pass is doing 18 fpm / .3 fps. No word on quality yet. I've got awhile to go :)

Threading seems to kind of work, it's getting 50% CPU usage on my box.

I'm willing to bet that the equator360 thing is related to equirectangular panoramas, which are used to deliver 360 video. It's an optical projection that lets you smash 360 degrees of video into a standard 2 dimensional frame.

If anyone knows how to optimize this sucker for perceptual quality, please share! I'm guessing turning variance AQ on will be a good idea for visual tests but not for metrics. Is this a useful feature?

[Blue_MiSfit]

For the lazy, here's the CLI reference:


Usage: aomenc <options> -o dst_filename src_filename

Options:
-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
-d <arg>, --deadline=<arg> Deadline per frame (usec)
--best Use Best Quality Deadline
--good Use Good Quality Deadline
--rt Use Realtime 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
-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
--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
--lag-in-frames=<arg> Max number of frames to lag

Rate Control Options:
--drop-frame=<arg> Temporal resampling threshold (buf %)
--resize-allowed=<arg> Spatial resampling enabled (bool)
--resize-width=<arg> Width of encoded frame
--resize-height=<arg> Height of encoded frame
--resize-up=<arg> Upscale threshold (buf %)
--resize-down=<arg> Downscale threshold (buf %)
--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 (-8..8)
--auto-alt-ref=<arg> Enable automatic alt reference frames
--sharpness=<arg> Loop filter sharpness (0..7)
--static-thresh=<arg> Motion detection threshold
--tile-columns=<arg> Number of tile columns to use, log2
--tile-rows=<arg> Number of tile rows to use, log2
--arnr-maxframes=<arg> AltRef max frames (0..15)
--arnr-strength=<arg> AltRef filter strength (0..6)
--arnr-type=<arg> AltRef type
--tune=<arg> Material to favor
psnr, ssim
--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)
--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, 4: equator360)
--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
--color-space=<arg> The color space of input content:
unknown, bt601, bt709, smpte170, smpte240, bt2020, reserved, sRGB
--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)

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 v0.1.0 (default)

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

[Jamaika]

If anyone knows how to optimize this sucker for perceptual quality, please share! I'm guessing turning variance AQ on will be a good idea for visual tests but not for metrics. Is this a useful feature?
Well colleague worked hard. ;)
Firstly, it isn't known how long the source you applied. If this is the first 100 frames that each test is preposterous. Too much distortion bitrate.
You have not entered the framerate. I guess after the GOP, it was 48fps or 24fps.
You mentioned about changing the functions aqmode to variance. All beautifully, it is to improve because bitrate does not make the setpoint and is 1.5 times greater.
I am an advocate for the conversion of vbr to cbr and boost 300. Otherwise they are too sharp edges.
The most important. How to excite, as there is no player.

[Motenai Yoda]

@Blue_MiSfit IIRC the devs suggest to use good and cpu-used 1 as it give roughtly the same quality as best (at least on vp9/10)
also on vp9 using aq degrade quality a bit (maybe overweighted?)

maybe auto-alt-ref and lag-in-frames will help.

[wiak]

another build
av1-git-d847070-win64.7z (https://f001.backblaze.com/file/nwgat-aom/av1-git-d847070-win64.7z)

:stupid:

[easyfab]

I didn't test recently, but I don't see alot of new things to test according to the commits, I hope until the release of AV1 ( december 2016 to march 2017 ) there will be some .

@wiak is your build with default settings or did you include some experimental settings ? the list (https://aomedia.googlesource.com/aom/+/master/configure#248)

[wiak]

I didn't test recently, but I don't see alot of new things to test according to the commits, I hope until the release of AV1 ( december 2016 to march 2017 ) there will be some .

@wiak is your build with default settings or did you include some experimental settings ? the list (https://aomedia.googlesource.com/aom/+/master/configure#248)
default compile settings i just run ./configure

[Jamaika]

Codec AV1-git-d847070 is still underdeveloped. Problems or inconsistencies resulting from the explanation of some functions.

The problem of different bitrates.
aomenc.exe -v --threads=4 --width=1920 --height=1080 --i420 --profile=0 --fps=30000/1001 --best --codec=av1 --cpu-used=0 --passes=2 --pass=2 --fpf=aom.pass --drop-frame=100 --kf-max-dist=60 --target-bitrate=3500 --frame-boost=1 --end-usage=cbr --gf-cbr-boost=300 --max-intra-rate=110 --bias-pct=50 --maxsection-pct=3000 --aq-mode=1 --kf-max-dist=60 --color-space=bt709
or
aomenc.exe -v --threads=4 --width=1920 --height=1080 --i420 --profile=0 --fps=30000/1001 --best --codec=av1 --cpu-used=0 --passes=2 --pass=2 --fpf=aom.pass --drop-frame=100 --kf-max-dist=60 --target-bitrate=0 --cq-level=34 --frame-boost=1 --end-usage=q --bias-pct=50 --gf-cbr-boost=200 --max-inter-rate=130 --maxsection-pct=2000 --aq-mode=1 --kf-max-dist=60 --color-space=bt709

The loss of video quality at the bitrate of 3500kbps, in fact 4000-4300kbps depending on the mode aq-mode.
For mode VBR (default) is a significant drop in compression frame {about 400KB for PNG} in relation to the original. It is synonymous with a decrease in quality. The biggest issue is slightly rough surfaces that lose their roughness and are sharp edges ex. subtitles. For the X265 {veryslow} is the order of 300kb, which is less lost data and has set value bitrate for 2pass.

Overview the functions:
"drop-frame" is correct display frame rates for movies about XX000/1001 fps. Not the task of this function is that the value fps is overvalued and is a little greater, eg. 30.033. In fact, the codec itself should adapt dropframe without the user's knowledge, but it is not. For mode CBR function "drop-frame" is with errors.
"gf-cbr-boost" mode golden frame (P or B). The construction of this frame is mysterious and complex. These frames aren't displayed and retain data for the P-frame depend on the function "auto-alt-ref". The best setting codec when turned off "auto-alt-ref". To try to match the quality of CBR to VBR is to raise bitrate golden frame by 300%. The value of the frame I by 110%. Note: Do not turn on the "frame-boost". This function is only for mode "end-usage=q".
"bias-pct" is a hash of two modes frames VBR and CBR. How not to set the best variant is 50% to 50%. Otherwise, the film is visibly pale.
"color-space" bt2020. It is now fiction. As you know ffmpeg converter converts the bt601 and then to the set. In addition, the codec is 8 bit.
"maxsection-pct" as not to describe it is a dead function. Change the value with 2000% to 3000% doesn't contribute to improving the quality of frames???

[06_taro]

Vanilla nightly builds for Win64, with high bit depth enabled. Should be able to output 8 / 10 / 12 bit av1. Encoder consumes too much RAM, so no 32bit build.
http://tmod.nmm-hd.org/aom/

Built daily if there are new commits. Old builds will be removed occasionally.

Also added av1 decoding (8/10/12 bit) for LAVFilters in http://tmod.nmm-hd.org/LAVFilters/ with latest libaom, thanks to Libav patches #61173 (https://patches.libav.org/patch/61173/) and #61174 (https://patches.libav.org/patch/61174/) and VFR-maniac's patch (https://github.com/VFR-maniac/LAVFilters/commit/690bf3ad551788789a5a08239d3d6e2e3b4839ae) for LAVFilters. Both were somewhat modified and placed in patches folder.

BTW, the encoder seems not stable enough that 4K encoding usually causes crashes on windows, and even 720p 10-bit encoding results in abort trap 6 on OS X. Decoding with LAVFilters seems to be fine now, but further test is still needed.

[Jamaika]

Vanilla nightly builds for Win64, with high bit depth enabled. Should be able to output 8 / 10 / 12 bit av1. Encoder consumes too much RAM, so no 32bit build.
I should be here more explanation of how it works new codec AV1.
--test-16bit-internal Force use of 16 bit internal buffer
--bit-depth=<arg> Bit depth for codec (8 for version <=1, 10 or 12 for version 2)
8, 10, 12
http://codecs.multimedia.cx/wp-content/uploads/2016/02/Diagram1.png

What does the function 'test-16bit-internal' and what kind has application? Is it a function input of 16bit RGB? How to create command output colormatrix 16bit sRGB? Is there a mode full range?
I also understand that the bit-depth means the quality of a signal quantization of the processing stage, eg. in the preview.
Also added av1 decoding (8/10/12 bit) for LAVFilters
Great, but the decoder must be registered in Windows. Otherwise player MPC-HC crashes. And a pity that there is no decoder Daala.;)

[ls1dreams]

When does everyone think we'll get hardware decoding from intel chips?

I'm really frustrated with my laptops getting super hot just playing the most simple videos, google hangouts, etc.

For example, VP9 came out in 2013, and even today, 3 years later, we still don't have a chip that does full hardware decoding (only partial). Kaby Lake will resolve this, but it will have been 4 years. The same goes for HEVC.

Having a slightly smaller stream hardly matters to me if it means my cpu is spinning up to 50% utilization or higher.

AV1 seems to have everyone on board, but when will we get an igpu (macbooks/etc) that supports it? Kaby Lake is obviously out. Cannon Lake too soon?

I'm overdue for upgrading my laptop, but don't really want to wait 2 more years for this! I just want to play 4k videos on a macbook retina without the machine overheating. (Hell, even 720p or 1080p).

[mzso]

When does everyone think we'll get hardware decoding from intel chips?

I'm really frustrated with my laptops getting super hot just playing the most simple videos, google hangouts, etc.

For example, VP9 came out in 2013, and even today, 3 years later, we still don't have a chip that does full hardware decoding (only partial). Kaby Lake will resolve this, but it will have been 4 years. The same goes for HEVC.

Having a slightly smaller stream hardly matters to me if it means my cpu is spinning up to 50% utilization or higher.

AV1 seems to have everyone on board, but when will we get an igpu (macbooks/etc) that supports it? Kaby Lake is obviously out. Cannon Lake too soon?

I'm overdue for upgrading my laptop, but don't really want to wait 2 more years for this! I just want to play 4k videos on a macbook retina without the machine overheating. (Hell, even 720p or 1080p).

The solution is simple. Don't buy an intel based computer, if you want stuff supported.

[mandarinka]

Make sure you are using FFVP9 decoder. Chrome uses the libvpx instead (bad, inefficient). I think Firefox adopted FFVP9, but I have no idea if it is used on the Apple OS X.

No idea if the Intel drivers that implement the partial acceleration even work/are available on the platform (or Linux). If they don't, you could try under Windows and see if the partial acceleration works under 4K - not sure there.

[IgorC]

I have tried https://media.xiph.org/video/derf/webm/Netflix_Aerial_4096x2160_60fps_10bit_420.webm chrome was the fastest.


The solution is simple. Don't buy an intel based computer, if you want stuff supported.
Intel was first to support VP9 decoding (at least hybrid). Anyway I don't see anyone doing better. "not buying Intel" doesn't solve anything.

[hajj_3]

When does everyone think we'll get hardware decoding from intel chips?

I think the AV1 codec is supposed to have hardware decoding available starting at the end of 2017 iirc. That will likely be from ARM and Qualcomm i suspect. Hardware decoding is way more important for those companies than it is for laptops and desktops. I suspect that by mid-2018 all intel and amd apus will have it and all amd and nvidia gpus.

[wiak]

I think the AV1 codec is supposed to have hardware decoding available starting at the end of 2017 iirc. That will likely be from ARM and Qualcomm i suspect. Hardware decoding is way more important for those companies than it is for laptops and desktops. I suspect that by mid-2018 all intel and amd apus will have it and all amd and nvidia gpus.
i suspect amd navi and nvidia voltra will support it and chips based on them (it takes 2-3 years from planning to release of a new gpu)
if you want to play modern codecs, you should get a proper pc not some underpowered laptop
laptop are made to be portable and low power
:stupid:

[Nintendo Maniac 64]

Since AMD's Zen cores are intended to scale all the way down to power consumption levels that are similar to their Jaguar cores, it's theoretically possible that AMD will be more proactive in implementing AV1 hardware decoding in their Zen APUs since it'll be much more important for such low-power form-factors.

http://forum.doom9.org/attachment.php?attachmentid=15553

[mzso]

Since AMD's Zen cores are intended to scale all the way down to power consumption levels that are similar to their Jaguar cores, it's theoretically possible that AMD will be more proactive in implementing AV1 hardware decoding in their Zen APUs since it'll be much more important for such low-power form-factors.

http://forum.doom9.org/attachment.php?attachmentid=15553

Yeah... That attachment will probably never be approved. :)

[hajj_3]

Since AMD's Zen cores are intended to scale all the way down to power consumption levels that are similar to their Jaguar cores, it's theoretically possible that AMD will be more proactive in implementing AV1 hardware decoding in their Zen APUs since it'll be much more important for such low-power form-factors.

http://forum.doom9.org/attachment.php?attachmentid=15553

zen apus are supposed to be out in mid 2017, can't see av1 hardware decoding being available in zen apus, possibly hybrid decoding if you are lucky. Zen+ will likely have it though.

[Nintendo Maniac 64]

Some presentations from VideoLAN Dev Days 2016 that may or may not be relevant:

VideoLAN Dev Days 2016: Daala (https://www.youtube.com/watch?v=AOssZFJ0EdI)

VideoLAN Dev Days 2016: Update on VPX (https://www.youtube.com/watch?v=peS2I14w8ow)

Yeah... That attachment will probably never be approved. :)

Then stand back and watch as I cheat the system! :p

http://i.imgur.com/6uS6Ab9.png

[dapperdan]

Another related video talk, on the Eve VP9 encoder:

https://www.youtube.com/watch?v=t_z52-CBut0

[littlepox]

I'd guess AMD spend half of their R&D budget on PPT design.
Really, I'd be interested to buy some templates from them for my own use.

[Jamaika]

New web codec AOM. Codec VP10 turned into to AV1.
https://chromium.googlesource.com/webm/libvpx/+/nextgenv2
https://github.com/mbebenita/aomanalyzer
Websites obsolete:
https://github.com/jmvalin/aom
https://github.com/smarter/aom

[Clare]

I do hope they will rework the encoder completely instead of relying on the current libvpx one because that encoder is way too slow.

[sneaker_ger]

What problem? Error message?
Please stop filling AV1/Daala/VP9 threads with your ffmpeg and color troubles. Make new threads in the newbie section.

[Jamaika]

Problem with conversion
https://www.sendspace.com/file/2qnw7j

[Jamaika]

Test Clare codec AV1 vs X165 is underestimated because preset is good, bpg has veryslow.
Preset for X265 is:
0.ultrafast
1.superfast
2.veryfast
3.faster
4.fast
5.medium (default)
6.slow
7.slower
8.veryslow
9.placebo
Preset for VPX/AOM is:
0. rt + 37% quality
5. good (default) + 50% quality
9. best + max.63% quality
I associate it mistakenly with the parameter VPX "cq-level". So you could set for veryslow quality VPX best + max.63%.
http://i64.tinypic.com/331hpmr.jpg
No one probably doesn't know what effect it has value of quality "min-q". The first frame is always a big mistake for added value for codec VPX and AV1.

Interesting is also why each encoder VPX&AOM has a different parameter of quality.
FFmpeg has CRF.
What possesses Adobe plugin 1.003? Must enter function "cq-level". Changing the value of quality means a change bitrate and the number of frames P. 37% is 2frames, 50% is 4 frames, 63% is 6 frames. It is a pity that libvpx isn't such fuction. I could make a mistake because I did not use the same function {--tile-columns=4 --arnr-maxframes=7 --arnr-strength=5}.
Approached by a characteristic size of the frame to the X265. Changing good to best doesn't change the size of the bitrate, only the number of reference vectors in frame.
Edit: The function pass 2 is a falsification. There is no dynamic frame B. Analyzer video Elecard doesn't show that it has been implemented.

[benwaggoner]

No one probably doesn't know what effect it has value of quality "min-q". The first frame is always a big mistake for added value for codec VPX and AV1.

In the VPx series, "min-q" always set the minimum quality. No frame would be encoded with a quality less than that IIRC, depending on other settings, this could lead to either dropped frames or increased bitrate (historically there wasn't a VPx "VBV" to violate, but that is changing with AOM).

[Jamaika]

I didn't notice dropped frames. However, the bitrate of the first frame I is 2x larger or less than others frames I. It depends on the aspect ratio video. Why is it like that? Only the creator knows.
(historically there wasn't a VPx "VBV" to violate, but that is changing with AOM).
We'll see how Elecard release free analyzer. It is only known that the AOM is based on VP9

[benwaggoner]

I didn't notice dropped frames. However, the bitrate of the first frame I is 2x larger or less than others frames I. It depends on the aspect ratio video. Why is it like that? Only the creator knows.
Bigger perhaps due to initial buffer fullness assumptions. This was a VPx parameter.

Why it would depend on aspect ratios is baffling. Was this different content aspect ratios in square pixel, or different SARs? If you have a repro-able bug, it should get passed on to the AOM folks.

[Jamaika]

Thanks for hints. Indeed AOM fixed problem first frame I. No need to to use min-q for the FullHD. To test this, I used the analyzer mkvinfo.
mkvinfo -s av1.webm >> av1.txt
Unfortunately, I can't create (profile 3) movies 4K. Encoder requires 16MB RAM. I've got too old for computer. :(
Track 1: video, codec ID: V_AV1, mkvmerge/mkvextract track ID: 0, pixel width: 2048, pixel height: 1152, yuv422p10le (profile 3), min-q=0
I frame, track 1, timecode 0 (00:00:00.000), size 166818, adler 0x00b4b52f
...
I frame, track 1, timecode 2000 (00:00:02.000), size 151294, adler 0x7c901f15
...
I frame, track 1, timecode 4000 (00:00:04.000), size 153129, adler 0xf2b726d9
...
I frame, track 1, timecode 6000 (00:00:06.000), size 163401, adler 0xb73093d4
...
I frame, track 1, timecode 8000 (00:00:08.000), size 184388, adler 0x19ddc916
Track 1: video, codec ID: V_AV1, mkvmerge/mkvextract track ID: 0, pixel width: 3840, pixel height: 2160, yuv420p10le (profile 2), min-q=0
I frame, track 1, timecode 0 (00:00:00.000), size 483939, adler 0x9517be61
...
I frame, track 1, timecode 2000 (00:00:02.000), size 379716, adler 0x3066620a
...
I frame, track 1, timecode 4000 (00:00:04.000), size 385909, adler 0x409e46ec
...
I frame, track 1, timecode 6000 (00:00:06.000), size 402404, adler 0xfe265630
...
I frame, track 1, timecode 8000 (00:00:08.000), size 380221, adler 0x36dd028a
...
I frame, track 1, timecode 10000 (00:00:10.000), size 498620, adler 0x16fbcc9d
...
I frame, track 1, timecode 12000 (00:00:12.000), size 414623, adler 0xa940b1b2
Track 1: video, codec ID: V_AV1, mkvmerge/mkvextract track ID: 0, pixel width: 3840, pixel height: 2160, yuv420p10le (profile 2), min-q=5
I frame, track 1, timecode 0 (00:00:00.000), size 346569, adler 0x2f11e1bc
...
I frame, track 1, timecode 2000 (00:00:02.000), size 340183, adler 0x2be6ca69
...
I frame, track 1, timecode 4000 (00:00:04.000), size 341161, adler 0xcdc0e26d
...
I frame, track 1, timecode 6000 (00:00:06.000), size 356605, adler 0x8767bc55
...
I frame, track 1, timecode 8000 (00:00:08.000), size 369449, adler 0xa6319ee4
...
I frame, track 1, timecode 10000 (00:00:10.000), size 369914, adler 0xb9adbcbc