Alliance for Open Media codecs

[CruNcher]

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. 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.

Huh ?

Image compression

All images are compressed losslessly and over a range of qualities for each codec:

BPG:
lossless: bpgenc -m 8 -f 420 -lossless -o [output] [input(PNG)]
between q=3 and q=45: bpgenc -m 8 -f 420 -q $q -o [output] [input(PNG)]

AV1:
lossless: aomenc --passes=2 --lossless=1 -o [output] [input(Y4M)]
between q=5 and q=63: aomenc --passes=2 --end-usage=q --cq-level=$q -o [output] [input(Y4M)]

Daala:
lossless: encoder_example -v 0 -o [output] [input(Y4M)]
between q=5 and q=85: encoder_example -v $q -o [output] [input(Y4M)]

FLIF:
lossless: flif -Q 100 [input(PNG)] [output]
between q=-329 and q=79, with a step of 12: flif -Q $q [input(PNG)] [output]

JPEG2000:
lossless: kdu_compress -no_info Creversible=yes -slope 0 -o [output] -i [input(PPM)]
between q=38912 and q=45056, with a step of 64: kdu_compress -no_info -slope $q -o [output] -i [input(PPM)]

JPEG XR:
lossless: JxrEncApp -d 1 -q 1 -o [output] -i [input(PPM)]
between q=5 and q=85: JxrEncApp -d 1 -q $q -o [output] -i [input(PPM)]

MozJPEG:
lossless: cjpeg -rgb -quality 100 [input(PNG)] > [output]
between q=5 and q=95: cjpeg -quality $q [input(PNG)] > [output]

WebP:
lossless: cwebp -mt -z 9 -lossless -o [output] [input(PNG)]
between q=5 and q=95: cwebp -mt -q $q -o [output] [input(PNG)]


Indeed if the default ist good it would be not the highest preset as bpg uses i wonder why clare decided this

[Jamaika]

They said that in order to achieve the 50% increase in efficiency over VP9, they are willing to accept a 40% increase in decoding complexity and a 5 to 10 times higher encoding complexity than VP9, see:
You can see increase in efficiency over the codec VP9. Certainly is an interesting alternative to HEVC codecs. In AV1 is less undulation pixels at low bitrate and better views gray. It can develop. Currently, they have time to improve the decoder LAV 10bit. Does not recognize the files AV1. And most important adding new implementations to encoding speed.
https://www.sendspace.com/filegroup/%2B1GIcza3qP6YuKA66f%2FiztpTDNDeyMc9

[dapperdan]

The Alliance for Open Media was also there and gave a presentation on AV1, where they said they are aiming for a 50% increase in efficiency over VP9/H.265 with AV1. They also said that AV1 in it's current state already beats VP9 by 25-30% (with not yet released Google internal tools). They said that in order to achieve the 50% increase in efficiency over VP9, they are willing to accept a 40% increase in decoding complexity and a 5 to 10 times higher encoding complexity than VP9, see:

https://youtu.be/thvSyJN1vsA

:eek:

They also target a release in the first half of 2017 for AV1.

The results on low bitrate VP9 from Netlfix were very interesting. Shows the power of automated testing of quality. Interesting to see what comes of that work. And good that they're offering to do the same with AV1 as part of the development process.

[nevcairiel]

A codec is not the place to lobby for your politics in format choices. If someone can't compress the image they have, then they are going to use another codec.

[nevcairiel]

Where else would that be then?
If they want to use such formats, the codecs exist that can handle all of it. So convince the content providers, its a political debate, not a technical one, and you can't force it on a technical level.

If there is enough demand, then hardware implementations of AV1 will also adopt support for higher chroma. Everything is a matter of demand. If content exists, hardware will come (or content is at least widely planned to roll out).


If you have a 4:2:0 limited range image, you can still encode it in 4:4:4 full range, so what exactly is your point?

That just wastes space and/or degrades quality. An image should be compressed as close to the raw material one has - and if thats 4:2:0 or 4:2:2, which a lot of content is, then don't artifically upscale chroma, just because someone is on a crusade. Cheap upscaling is almost as bad as downscaling in the first place.

[huhn]

3. Drop support for limited range (16-235), i.e. please support full range (0-255) only

RGB -> full range YCbCr conversation will result in overshooting so it is no real option.

[mzso]

RGB -> full range YCbCr conversation will result in overshooting so it is no real option.

What do you mean?

[huhn]

"you can get to big numbers."

which is not possible with limited range.

edit:When performing YCbCr to R ́G ́B ́ con-
version, the resulting R ́G ́B ́ values have a
nominal range of 16–235, with possible occa-
sional excursions into the 0–15 and 236–255
values. This is due to Y and CbCr occasionally
going outside the 16–235 and 16–240 ranges,
respectively, due to video processing and
noise.

http://www.compression.ru/download/articles/color_space/ch03.pdf

full range YCgCo should be fine https://en.wikipedia.org/wiki/YCgCo

[mzso]

"you can get to big numbers."

which is not possible with limited range.

edit:

http://www.compression.ru/download/articles/color_space/ch03.pdf

full range YCgCo should be fine https://en.wikipedia.org/wiki/YCgCo

So basically the gist of it is that a flawed algorithms, from flawed sources produce inferior results. Those outside values are technically invalid, so I don't see why they'd be relevant.

[Nintendo Maniac 64]

Is native YUV support really all that beneficial when using 10bit?

[huhn]

you need to compress the chroma channel more than the luma for proper picture quality bit deep has nothing to do with that.

[GTPVHD]

http://aomedia.org/about-us/

http://www.bbc.co.uk/rd/blog/2016/10/alliance-open-media-video-compression

More and more companies join the Alliance for Open Media.

[nevcairiel]

Is native YUV support really all that beneficial when using 10bit?

You'll always need to split RGB into another scheme for efficient encoding, because RGB has a lot of redundant information. So splitting it into Luma+Chroma makes encoding much more efficient.
On top of that this allows you to compress chroma more then luma, which plays into the nature of our eyes. With pure RGB you couldn't do that - the best you could do is compress one color channel more then the others, but thats not even close to as efficient.

YCbCr (or YUV in other terms) is what we have to do that. Some other approaches have been brought forward, like YCgCo, but they have not been adopted widely because many existing processing pipelines just know how to work with YCbCr, and the advantages of those suggested alternatives were not that great.

If someone can define a groundbreaking new scheme to split Luma and Chroma in a more efficient way (say a significant difference), reducing even more redundant information while being able to (visually) losslessly re-create the original image, I'm sure there would be industry interest eventually. But so far all the needs we had to modify YCbCr could be done with different transfer matrices to increase the colorspace.

[mzso]

http://aomedia.org/about-us/

http://www.bbc.co.uk/rd/blog/2016/10/alliance-open-media-video-compression

More and more companies join the Alliance for Open Media.

BBC is a good addition. They did research and released papers on what framerate requirements (with what "shutter time" ) are necessary for "perfect" motion representation...
So their input for HFR might be really useful.

[CruNcher]

Not only that think about Dirac VC2 Open Broadcast :)

And they're still standing a lot more on the doorstep waiting to get in ;)

[Motenai Yoda]

BBC is a good addition. They did research and released papers on what framerate requirements (with what "shutter time" ) are necessary for "perfect" motion representation...
So their input for HFR might be really useful.

NHK did it too and found 120fps (over 100) and 240Hz shutter time to be the right values
http://informationdisplay.org/IDArchive/2012/NovemberDecember/FrontlineTechnologySuperHiVisionasNextGen.aspx

[mzso]

NHK did it too and found 120fps (over 100) and 240Hz shutter time to be the right values
http://informationdisplay.org/IDArchive/2012/NovemberDecember/FrontlineTechnologySuperHiVisionasNextGen.aspx

I remember 250-300 fps. (DVB Scene #44, Richard Salmon (https://www.dvb.org/resources/public/scene/dvb-scene44.pdf))

According to "The Application of Sampling Theory to Television Frame Rate Requirements (http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP282.pdf)" the hard limit is at ~700fps. But that might not take into account BFI trickery.

I'd be interested to know if anyone did research which includes interpolation algorithms. It might be that something like 100 interpolated to 300 + BFI would totally fool human perception and would appear completely realistic.

[CruNcher]

Interesting you would need to look into the FRC SOA :)

This part is really interesting for HVS tuning and reducing the bandwith requirements efficiently

There are, however, two forms of un-trackable motion which the brain still does not interpret as smooth, resulting in either the perception of judder, or of multiple imaging.
The eye is unable to track rotating motion, such as the juggling clubs seen in Figure 2, nor can it track multiple motions at the same time.
Thus if in a football match the eye is following the ball, the background behind it may be seen to judder.

But i guess nothing of this is really new especially as everyone of us already experienced these effects (especially the background judder effect following an object in High Motion, it always makes me crazy in subjective frametime analysis thinking latency is to high and something failing) but it could help improve some misconceptions of "motionblur helps everywhere" :)

We have some really interesting things going on like Asynchrounous Space Warping for VR :)

And i think VR is the future for this Research to be improved significantly :)

https://www.youtube.com/watch?v=xpQQmu7vquE

I can now max out setting and super sample 1.5. I was sensitive to VR sickness and this has 100% removed it even in things like 360 videos that don't have the ability to move your head in all directions properly.

And it has much major impact then ever before latency becomes so a high issue that it will transform surely also hardware architectures in becoming much much more efficient to avoid nausea efficiently.

And surely we also have to rethink about efficiency costs and energy consumption.

But if i think about HFR in total i get big headaches of the Discussion in certain areas like Cinema especially with a decade old Hollywood trained LFR crowed ;)

And im pretty sure there isn't even yet a HFR Production existing from Hollywood that would adhere to Scientific grounds and rethink how todo it from Ground up right and different in the whole production chain, it will still take years before that will work out at all.

[Jamaika]

No. X264 and BPG suport YCgCo, but BPG's old codec.
VPX/AOM only suport:
--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

[Phanton_13]

I found this comparison betwen beta of AV1, HEVC and AVC by the Fraunhofer Heinrich Hertz Institute:

http://iphome.hhi.de/marpe/download/Preprint-Performance-Comparison-AV1-HEVC-AVC-PCS2016.pdf

The result is somewat surprising but not much if we think who did it and the development status of AV1, after reading it I also find it of poor quality and with various possibilities for errors plus it's potentially in conflict with other studies.

[dapperdan]

Not read it yet, but that appears to be the same group that put out a very early analysis of VP9, they took a copy of the git master branch the day that the format was finalized and talked about it as if it was released code. I think it was over a year later before there was an official VP9 release.

edit: the previous work I refer to: http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf

[CruNcher]

Not sure what's so surprising the coding tools are not that efficient yet (but in case of AV1 also not fully finalized and frozen yet) but therefore also the complexity is not as high and overall lower nothing unexpected to other studies also that the RC from the HEVC Reference is pretty damn weak compared to the reference VP9 encoder so their decission to look at the raw fixed Q performance is understandable especially seeing, that this is the area where they mostly contributed themselves to MPEG/AVC/HEVC :D

Though it's raw complexity which isn't the whole truth at all and H.266 will show that they know it very well themselves, we have arrived in diminishing returns space partly already no more energy to suck of the universe from ;)

[easyfab]

I just made a little test (latest git for all codec) with Kimono1_1920x1080_24.y4m @2500kbits :

x264 veryslow 3.00 Mo : ssim All:0.938488 (12.110405) psnr average:38.967018
x265 slower 2.87 Mo : ssim All:0.945886 (12.666905) psnr average:40.059902
vp9 cpu-used=2 2.82 Mo :ssim All:0.946726 (12.734856) psnr average:39.988449
and
av1 cpu-used=2 2.77 Mo : ssim All:0.947562 (12.803542) psnr average:40.220836

So AV1 is better than VP9 and x265 for this clip ( and slower ). And I don't build aomenc with experimental flag that should give even better ( and even slower) result .

[Clare]

I just made a little test (latest git for all codec) with Kimono1_1920x1080_24.y4m @2500kbits :

x264 veryslow 3.00 Mo : ssim All:0.938488 (12.110405) psnr average:38.967018
x265 slower 2.87 Mo : ssim All:0.945886 (12.666905) psnr average:40.059902
vp9 cpu-used=2 2.82 Mo :ssim All:0.946726 (12.734856) psnr average:39.988449
and
av1 cpu-used=2 2.77 Mo : ssim All:0.947562 (12.803542) psnr average:40.220836

So AV1 is better than VP9 and x265 for this clip ( and slower ). And I don't build aomenc with experimental flag that should give even better ( and even slower) result .

What speed did you get for AV1? I'm trying to encode a small clip but I get less than 1 frame per minute! This is impossible to encode anything with such a slow speed.

[easyfab]

What speed did you get for AV1? I'm trying to encode a small clip but I get less than 1 frame per minute! This is impossible to encode anything with such a slow speed.

I used -t 8 --good --cpu-used=2 --tile-columns=4 and get 2-3 fps, but under 30% cpu usage, I hope better multithreading in future.
I have not tested better settings cpu-used=1 or --best because it's too slow under 1fps

[Clare]

At constant quality (measured by VMAF and PSNR-HVS on 30 short clips), I've got some impressive 33% reduction in size compared to x264, whereas with x265, I only achieved 5-10% at best. I'm gonna test it again in 10Bit and see if there is more room for improvement.

edit: I have --enable-dering experimental flag enabled to test. With PVQ enabled, computing was too slow.

[Clare]

Kinda disappointed by experimental settings on pictures (dering + clpf):

http://i.imgur.com/hx95zuv.jpg

[CruNcher]

Are you kinda disappointed about the Graph result or does it mirror also your HVS MOS ;) ?
Are you gonna to include the preview results in the main image compare database at the different bpp/size targets ?

[Jamaika]

@Clare Can you present a graph of results VMAF for Daala?

[Clare]

Are you kinda disappointed about the Graph result or does it mirror also your HVS MOS ;) ?
Are you gonna to include the preview results in the main image compare database at the different bpp/size targets ?

Visually, there is indeed less ringing around the edges, but some details are phased out.

I'm not gonna touch the comparison tools.

@Jamaika: Graphs with Daala are included in the website in my signature/

[MoSal]

@Clare

Don't dering and clpf have similar functionalities?

You should try dering alone if you have the time. It's supposed to be better, especially at low bitrates.

[Jamaika]

@Clare @Mosal Give some commands {apps}. What are the most beneficial for vmaf?
usage: vmaf app fmt ref dis w h
apps:
adm, ansnr, motion, vif, all
How do the best on ffmpeg?
ffmpeg.exe -loglevel verbose -i "input_yuv.mp4" -an -f yuv4mpegpipe -vf scale=1920:1080,format=yuv420p - |
vmaf_main.exe ??? yuv420p - output.yuv 1920 1080 --output json
aomenc.exe --codec=av1 --good --threads=4 --cpu-used=4 --target-bitrate=6000 --kf-max-dist=60 --auto-alt-ref=1 --frame-boost=1 --aq-mode=0 --color-space=bt709 --verbose --pass=1 --passes=1 --output=output.webm output.yuv

[Clare]

@Clare

Don't dering and clpf have similar functionalities?

You should try dering alone if you have the time. It's supposed to be better, especially at low bitrates.
They re supposed to work together in the final product, I've even seen a patch a while back where they reversed the order of their execution because it was giving better metrics.

[Clare]

@Clare @Mosal Give some commands {apps}. What are the most beneficial for vmaf?
usage: vmaf app fmt ref dis w h
apps:
adm, ansnr, motion, vif, all
How do the best on ffmpeg?
ffmpeg.exe -loglevel verbose -i "input_yuv.mp4" -an -f yuv4mpegpipe -vf scale=1920:1080,format=yuv420p - |
vmaf_main.exe ??? yuv420p - output.yuv 1920 1080 --output json
aomenc.exe --codec=av1 --good --threads=4 --cpu-used=4 --target-bitrate=6000 --kf-max-dist=60 --auto-alt-ref=1 --frame-boost=1 --aq-mode=0 --color-space=bt709 --verbose --pass=1 --passes=1 --output=output.webm output.yuv

I don't know what you're doing. I don't know what is your "vmaf_main.exe". The executable to use is vmafossexec.

Just build it like that:
git clone https://github.com/Netflix/vmaf
cd vmaf
make

The executable "vmafossexec" is then available in the wrapper directory.

Usage: ./wrapper/vmafossexec <pix_fmt> <width> <height> <ref_path> <dis_path> <model_path>

The model path to use is "resource/model/nflxall_vmafv4.pkl"

[MoSal]

They re supposed to work together in the final product,


I don't know about that.

I would still use one of the two if the results i'm getting are too smooth.

[leonccyiu]

Does anyone have any idea as to how much longer it'll take for the av1 format to be frozen and how much work still needs to be done?

[Clare]

Does anyone have any idea as to how much longer it'll take for the av1 format to be frozen and how much work still needs to be done?

When will the codec ship? The group is aiming to freeze the bitstream sometime between the end of the 2016 and March 2017. Expect to see browser-based support soon thereafter, with the first hardware support within 12 months after that.
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/A-Progress-Report-The-Alliance-for-Open-Media-and-the-AV1-Codec-110383.aspx

Although I'm personally skeptical about these delays.

[mzso]

Does anyone have any idea as to how much longer it'll take for the av1 format to be frozen and how much work still needs to be done?

Doubt that anyone will give anything other then guesses. They don't provide any information whatsoever on their progress or state of the codec.

So only someone within could give any information. I don't think there's anyone on this forum besides jmvalin who has any sort of attachment to AV1.

[Mr.Radar]

Does anyone have any idea as to how much longer it'll take for the av1 format to be frozen and how much work still needs to be done?

The last public update on AV1 I'm aware of is from Netflix's forum on royalty-free video codecs (https://youtu.be/thvSyJN1vsA?t=42m38s) back in October which mentioned a target of "H1 2017 (https://youtu.be/thvSyJN1vsA?t=51m20s)" for freezing the bitstream. A talk giving a new status update on AV1 is scheduled (https://fosdem.org/2017/schedule/event/om_av1/) for FOSDEM in early February which should hopefully provide a bit more detail.

[VincAlastor]

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.

:thanks:

for easier testing with logs and statistics i want to use a GUI. Is there already a GUI for aomenc.exe?

[Selur]

@VincAlastor: I plan to add support for av1 to Hybrid shortly after I can playback such files in MPC-HC. :)
(got the general support working, but can't verify that everything is okay, since I can't decode the created files)

[VincAlastor]

@VincAlastor: I plan to add support for av1 to Hybrid shortly after I can playback such files in MPC-HC. :)
(got the general support working, but can't verify that everything is okay, since I can't decode the created files)

Thank you very much :)

i use the patched lavfilters as external filters in mpc-hc and seems to work very well, but not tested much for now.

[Selur]

I'll probably wait till it makes it into a nightly build of mpc-hc.

[easyfab]

Not as good as a gui but I create a batch file for my AV1 testing.

here the code if someone is interested ( only cpu-used and bitrate can be set ) :

for the encoder, you can drag and drop the file on the .bat icon or drag and drop when the bat is running. change the path to ffmpeg and aomenc if needed.


@echo off
Set file="%1"
if "%1"=="" Set /p file="enter file to encode (or drag and drop ) = "
FOR /F %%I IN ("%file%") DO SET filename=%%~nI

set /p bitrate="bitrate ( enter = default 250K ) without the"K" = "
if "%bitrate%"=="" set /a bitrate=250

set /p preset_AV1="AV1 Cpu-used (enter = 2) = "
if "%preset_AV1%"=="" set preset_AV1=2

ffmpeg -i "%file%" -f yuv4mpegpipe - | aomenc - --target-bitrate=%bitrate% -t 8 --good --cpu-used=%preset_AV1% --tile-columns=4 --passes=2 --pass=1 --fpf="%filename%.fpf" -o "%filename%_av1.webm"

ffmpeg -i "%file%" -f yuv4mpegpipe - | aomenc - --target-bitrate=%bitrate% -t 8 --good --cpu-used=%preset_AV1% --tile-columns=4 --passes=2 --pass=2 --fpf="%filename%.fpf" -o "%filename%_av1.webm"

and for the decoder with mpv ( you can change to ffplay )
change the path to aomdec and mpv if needed.


:start
Set file=%1
if "%1"=="" Set /p file="file to decode(drag and drop ) = "
aomdec "%file%" -o - | mpv.exe - --fs
goto start

[littlepox]

It's simply too early to take a serious look at AV1 now. My own estimation would be 3 years, before it surpasses x264 for general ripping use-case. This includes decent playback support (perfect in PC platform and good enough for mobile), excellent visual quality(with comprehensive psy optimization, tuning, on a wide spectrum of bit-rate target) and affordable performance (including different levels of performance presets)

Even x265 is not completely there arguably.

[nevcairiel]

I'll probably wait till it makes it into a nightly build of mpc-hc.

Which won't happen until av1 is officially finalized (ie. stable bitstream), and releases of libaom are made instead of just having Git master, sometime later this year, hopefully.

[hajj_3]

It's simply too early to take a serious look at AV1 now. My own estimation would be 3 years, before it surpasses x264 for general ripping use-case. This includes decent playback support (perfect in PC platform and good enough for mobile), excellent visual quality(with comprehensive psy optimization, tuning, on a wide spectrum of bit-rate target) and affordable performance (including different levels of performance presets)

Even x265 is not completely there arguably.

3yrs? pffft. Google and lots of other companies are working on this, development will be much faster than x265 has been. Hardware decoders for mobile will likely be ready in early 2018 and hardware decoders for pc in late 2018. I expect that in early 2019 the encoder will be good enough to replace x264, x265 and vp9.

[CruNcher]

Yeah the next GPU Cycle should show a first introduction as well before that we might see Hybrid solutions already, with Volta there will be definitely some kind of Decoding support 100% on Nvidias side and it could be going straight to first Hardware without any Hybrid step this time at all :)

[littlepox]

Playback compatibility is not a issue, as long as it remains open and hardware giants are evolved.
What the real challenge for ripping use-case is the visual quality optimization in transparent level, i.e, very high quality.
Optimization for benchmark is easy, for human eyes you really need to put in a lot of effort.
It takes 3 years for x265 to be there with x265 v2.0 as the milestone.

But still up to now, hardware support for HEVC main10 is poor and limited, and the tuning for x265 is incomplete. Majority still prefer x264 and I don't expect it changes within one year.

Let's see how AV1 progresses. Now it's still a lovely baby, may it grow up healthily.

[wiak]

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.

It can and is based on the codec vp10, just don't know it or not version a few months ago.
VP10 is the basis for AV1, but then they retrofitted daala/thor stuff into it, i suspect AOMedia AV2 will be a more daala lapping based codec. but thats for another time and place

TL;DR: VP10 + small parts of daala/thor = AV1