Alliance for Open Media codecs

[hajj_3]

DAV1D 0.2.0 final is out: https://code.videolan.org/videolan/dav1d/tags

Hopefully a new vlc player will be released soon with this integrated.

[utack]

Originally Posted by hajj_3

DAV1D 0.2.0 final is out: https://code.videolan.org/videolan/dav1d/tags

Hopefully a new vlc player will be released soon with this integrated.

Not yet
You can check here
https://git.videolan.org/?p=vlc.git;...es.mak;hb=HEAD
http://downloads.videolan.org/pub/videolan/dav1d/

[hin12]

Is 480p the highest quality option for all AV1 videos on YouTube? I'm seeing that a lot of popular videos are being encoded to AV1, but only at the 144p, 240p, 360p and 480p resolutions.

[HolyWu]

Originally Posted by hin12

Is 480p the highest quality option for all AV1 videos on YouTube? I'm seeing that a lot of popular videos are being encoded to AV1, but only at the 144p, 240p, 360p and 480p resolutions.

I can get AV1 encoded videos for more than 480p after choosing "Always Prefer AV1" at https://www.youtube.com/testtube.

[sneaker_ger]

Yeah. But even Gangnam Style (3.3 Billion views) is only available in 720p with AV1 (1080p is H.264+VP9 only.), Despacito (6 Billion views) is limited to 480p AV1. On the AV1 beta playlist it seems 1080p is max for AV1, 1440p and 2160p are reserved for VP9.

[dapperdan]

When VP9 rolled out they talked about how delivering video to people with decent spec machines but terrible connectivity was a sweet spot where VP9 increased the amount of video watched. I'd guess they've run the numbers and they get more benefit from encoding the lower sizes in AV1 so that's what they prioritize.

[lvqcl]

Some time ago I was able to download "Childish Gambino - Feels Like Summer" (https://www.youtube.com/watch?v=F1B9Fk_SgI0) in 1080p AV1 format; now its max. available resolution for AV1 is 720p.

Maybe 1080p AV1 is just too heavy to decode.

[sneaker_ger]

Or maybe they are re-encoding with new encoder version/settings and it will take some weeks before it's finished.

[benwaggoner]

Originally Posted by lvqcl

Some time ago I was able to download "Childish Gambino - Feels Like Summer" (https://www.youtube.com/watch?v=F1B9Fk_SgI0) in 1080p AV1 format; now its max. available resolution for AV1 is 720p.

Maybe 1080p AV1 is just too heavy to decode.

It would have been in many cases. Perhaps it'll come back when Chrome has a highly optimized decoder.

Also, the CPU requirements for encoding 1080p are 2.5.x that for 720p. Perhaps quality compromises were made to get publishing time to be reasonable that reduced competitiveness, or there were limits on available encoder capacity?

A 1080p H.264 encode takes >>100x less compute than a 1080p AV1. Even Google only has so much free CPU capacity in a day.

Encoder performance improvements plus better quality/speed tradeoff modes will change things dramatically. With continued strong development at the current pace, we could potentially have encoders that can provide better quality than x264 at the same bitrate and encoding time by late 2020. That encoder wouldn't even try to do 99.9% of the stuff that libaom tries to do, but real encoders don't try exhaustive searches, but use lots of heuristics and early exits.

[mandarinka]

I ran a new test of Rav1e on the same source as in this past post last year: https://forum.doom9.org/showpost.php...&postcount=882
(the motivation was a claim that Rav1e supposedly started to beat x264 "at any bitrate" so I thought I could as well repeat my highly specific test - note that this is by no means supposed to be authoritative. Unless you care about this type of content which I do.)

I used the last Rav1e release available at the time, at quality 20 and speed 0, tune psy. There are no other tuning options, so I could not do any tweaks - not my fault, that's the developers' policy. Resulting bitrate was 14526kbps. Encoding speed was 0.005 fps on Ryzen 3 2200G (~1 core used).

My x264 commandline is kind of tuned for this content - I copied what I last used on a similar bluray (but I dropped --qpmax which probably worsens efficiency). Note that three pass was used to get closer to Rav1e's bitrate but due to the short length probably, x264 still undershot (14337 kbps). Using three pass should not give quality boost.
The encoding speed was about 0.05 fps due to extremely placebo settings and 1 thread used (same as Rav1e). You could probably get 0.3 without much if any damage to quality.

Here are images from the encode: http://imgbox.com/g/yrCWrTYtF4
In the dust storm scene that uses higher bitrate than the rest and is at the start of the 910frame clip, Rav1e does well and it seems to be very close - I am not totally convinced it is as good as x264 as I think there are some signs of kinda low-passing the noisy blocks, but I am not completely confident it is worse either, although I am inclined to say x264 is in fact better here.

The rest of the clip has Rav1e clearly deficient despite the large bitrate though. It constantly smoothes the solid/flat areas and generally can't keep the milder grain and texture (which is a flaw). So its psychovisual decisions probably still aren't ready for high quality transparent encoding. This is a general problem with any non x264/x265 encoder probably, even x265 would drop texture detail everywhere before it got aq and psyrdo.

I'm trying to upload the source and streams (not fun to reproduce the Rav1e one hah), but uloz.to seems to fail on me. One thing that I should perhaps note about source - it has its chroma temporally denoised (not luma). In case that particularly matters for rav1e rate control... it only has constant quantizer mode though, afaik.


Commandlines:
rav1e.exe --speed 0 --quantizer 20 --tune Psychovisual n:\test.y4m -o psy-q20-speed0.ivf

x264-2935-64.exe n:\etr-testLL.mkv --qcomp 0.60 --aq-mode 1 --pass 3 --bitrate 14526 --no-mbtree --min-keyint 5 --keyint 240 --b-pyramid normal --deblock 0:0 --psy-rd 1.0:0.0 --aq-strength 0.8 --preset placebo --bframes 9 --direct auto --me tesa --merange 64 --subme 11 --threads 1 --colormatrix bt709 --sar 1/1 --chromaloc 0 --input-range tv --range tv --force-cfr --fps 24000/1001 -o n:\test-etr-x264-10bit-noqpmax.mkv --output-depth 10 --stats n:\noqpm.txt

[Atak_Snajpera]

What is the point of using AV1 with such insanely (15Mbps) high bitrate for anime? Why not use XviD or even MPEG-2 if you have such high bitrate budget?

[mandarinka]

Originally Posted by Atak_Snajpera

What is the point of using AV1 with such insanely (15Mbps) high bitrate for anime? Why not use XviD or even MPEG-2 if you have such high bitrate budget?

Transparent quality? I don't know what you expect from mpeg2 or xvid here but they would not give it to you. After all, the pictures clearly show that even 14 megabits isn't enough when encoder doesn't do the right decisions.
In any case, the point of it is stated in the post - it was claimed by certain people (and it was not just internet randoms) that Rav1e beats x264 at any bitrate, already. I wanted to test that claim.
(It's also a realistic case for me, but I would not use unfinished/untuned encoders normally for that, of course.)

[Atak_Snajpera]

Originally Posted by mandarinka

Transparent quality? I don't think what you expect frommpeg2 or xvid here but they would not give it to you.
In any case, the point of it is stated in the post - it was claimed by certain people (not just internet randoms) that Rav1e beats x264 at any bitrate already. I wanted to test that claim.
(It's also a realistic case for me, but I would not use new/untuned encoders normally for that, of course.)

OK. I will have to check how bad is this codec in parkjoy at 5Mbps. I'm expecting similar disaster to that crappy SVT-HEVC encoder.

[mandarinka]

Parkjoy might benefit from the compression strength advantage of the format, same as it usually shows in low bitrate tests. Rav1e has no AQ yet though so that will probably be a big disadvantage because parkjoy iirc benefited a lot from it?
But you would not run into this "can't have transparent dirt on a flat color area in cel anime" issue, that's for sure.

[Wolfberry]

I recommend to use the official AppVeyor builds here: https://ci.appveyor.com/project/tdaede/rav1e/history

[mandarinka]

Originally Posted by Wolfberry

I recommend to use the official AppVeyor builds here: https://ci.appveyor.com/project/tdaede/rav1e/history

At the time I went to #aomedia to ask for these binaries (I recall I could not find the artifact button that leads to the binary there/it was not working atm... not sure now) and somebody there recommended to get the release one. So I did that.

[Wolfberry]

The pre-release is just a weekly snapshot and the latest one is already kinda old, so...

[mandarinka]

Yeah, obviously. At the time I ran this test though, it was just 9 or 10 days old. You have to remember I used speed 0, so just getting 910 frames encoded took three or four days (PC hibernated overnight). The following week I was kind of busy which added more delay to this post. So it wouldn't really be a big difference if I used appveyor then.

[Wolfberry]

AFAIK, assembly is disabled on windows at the moment, so you are basically running on rust code.
I am recommending AppVeyor builds in case someone want to try it out now.

[Atak_Snajpera]

OH MY GOD! The encoding speed is just INSANELY SLOOOOOOOOOOOOOOOOOOOOOOOW. 90 minutes have passed and my 8C/16T managed to encode only 350 frames from just first pass.
How can you even test any codec if encoding takes so much time?