Alliance for Open Media codecs

[v0lt]

ffmpeg-4.2-N-93276-g3b23eb283a-win64-static (https://drive.google.com/open?id=11-RIGTnNB5jjHrO4puotRHsNu_YdGMKr)
Test on this build. i5-3570K.
-t 10 Stream2_AV1_4K_22.7mbps.webm -benchmark -f null -
libaom-av1 - max 15 fps
libdav1d - max 13 fps
libdav1d -threads 4 -tilethreads 4 - max 18 fps
libdav1d -threads 8 -tilethreads 1 - max 18 fps
I see progress compared to last time (https://forum.doom9.org/showthread.php?p=1859851#post1859851).

Please give me a link to a good 10-bit AV1 sample.

[sneaker_ger]

Please give me a link to a good 10-bit AV1 sample.
http://download.opencontent.netflix.com/?prefix=AV1/Chimera/

[nevcairiel]

Note that 10-bit is not an optimization target at all yet, since its not in use in the real world at all yet either.

[v0lt]

@nevcairiel
Why does libdav1d give a speed less than libaom-av1 with default settings? 8 and 10-bit. Poorly selected default settings?

i5-3570K, AV1 10-бит.
-ss 5 -t 20 Chimera-AV1-10bit-1920x1080-6191kbps.mp4 -benchmark -f null -
libaom-av1 - max 25 fps
libdav1d - max 21 fps
libdav1d -threads 4 -tilethreads 4 - max 25 fps
libdav1d -threads 8 -tilethreads 1 - max 26 fps

[soresu]

Dunno if anyone noticed the CNN restoration experiment commited to the "experimental" branch at the AOMedia git repo.
Link here (https://aomedia.googlesource.com/aom/+log/refs/heads/experimental).

[EwoutH]

@v0lt Which version of dav1d are you using? You can use `dav1d --version` to check.

A big factor is because your CPU doesn't support AVX2 instructions, where dav1d is most optimized for (Haswell (4000-series) and newer support it). Your CPU i5-3570K falls back on SSSE3, which recently got a lot faster (https://www.reddit.com/r/AV1/comments/awxvks/ssse3_performance_improvement_of_dav1d_blogpost/) with dav1d.

Also can you try -tilethreads 4 without a threads option?

Anyway there is at least one patch incoming (https://code.videolan.org/videolan/dav1d/merge_requests/622) that's not yet in FFmpeg that will improve performance with 10 to 30% percent, depending on content.

[dapperdan]

I interpreted volts question as being "if I can get faster results from dav1d by passing some settings, why can't it figure those out by default".

Presumably, if those patches land the default might beat libaom, but there would still be extra speed a ilavle as long as you knew the right options to pass.

There may well be a good reason for these not being the defaults though.

[Gravitator]

Through the synthetic test mode ffmpeg, I get higher rates of DAV1D than AOM. But in real conditions I get worse playing than AOM (via ffplay). We are waiting for optimization for SSSE3.

[sneaker_ger]

Also can you try -tilethreads 4 without a threads option?
On i5-2500K with ffmpeg (binary from one post above) -tiletreads 4 (alone) is some 15% slower than -threads 6 -tilethreads 2. ("Blackmagic Pocket Cinema Camera 4K ‘Nature’-oAbB4dQOz4I" 1080p24)

[v0lt]

@v0lt Which version of dav1d are you using? You can use `dav1d --version` to check.
ffmpeg-4.2-N-93276-g3b23eb283a-win64-static provided by Wolfberry. But the links are gone.

ffmpeg-4.2-N-93290-g88d0be1c0e-win64-static (https://drive.google.com/open?id=1jpnMkcW8j1UPD4StPDt9ZwFtwNTXnD1C)
Thank. This build works better.

i5-3570K
ffmpeg -hide_banner -t 10 -c:v <codec&parameters> -i Stream2_AV1_4K_22.7mbps.webm -benchmark -f null -
libaom-av1 - max 15 fps
libdav1d - max 16 fps
libdav1d -threads 4 -tilethreads 4 - max 24 fps
libdav1d -threads 8 -tilethreads 1 - max 21 fps
ffmpeg -hide_banner -ss 5 -t 20 -c:v <codec&parameters> -i Chimera-AV1-8bit-1920x1080-6736kbps.mp4 -benchmark -f null -
libaom-av1 - max 60 fps
libdav1d - max 64 fps
libdav1d -threads 4 -tilethreads 4 - max 105 fps
libdav1d -threads 8 -tilethreads 1 - max 87 fps
ffmpeg -hide_banner -ss 5 -t 20 -c:v <codec&parameters> -i Chimera-AV1-10bit-1920x1080-6191kbps.mp4 -benchmark -f null -
libaom-av1 - max 25 fps
libdav1d - max 21 fps
libdav1d -threads 4 -tilethreads 4 - max 26 fps
libdav1d -threads 8 -tilethreads 1 - max 27 fps

[benwaggoner]

There's a solution. :)
https://cdn.vox-cdn.com/thumbor/1HzHTQhjVUrhVDHQC8k1hdM9HPg=/0x0:2040x1360/1200x800/filters:focal(913x433:1239x759)/cdn.vox-cdn.com/uploads/chorus_image/image/63124099/energizer_unit_vsavov7.0.jpg


Yay! Two more formats to sink into obscurity...
The time **IS** ripe for a new replacement for JPEG/GIF/PNG. We're looking at >>2x compression efficiency improvements. And HEIF is getting good traction in the Apple ecosystem.

I would prefer an AV1 in HEIF over a new file format, though. HEIF has a lot of great features as a container format.

[nevcairiel]

HEIFs tiling is pure cancer. It's a typical format designed by committee, overly complex for its own good.

[sneaker_ger]

dav1d 0.2.0 is final.

https://medium.com/@ewoutterhoeven/dav1d-0-2-0-covering-all-pcs-including-mobile-eac3e43868c2

[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]

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;a=blob;f=contrib/src/dav1d/rules.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.

[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. :devil:

[benwaggoner]

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?p=1850675&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 (https://github.com/xiph/rav1e/releases/tag/20190219), 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]

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]

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]

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?

[mandarinka]

AFAIK, assembly is disabled on windows at the moment, so you are basically running on rust code.

Are you sure? I was asking about the speed in the channel too, exactly for this reason, but didn't get this information there. Maybe it would be a good idea if the encoder displayed ASM used like x264 does.
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?
I don't think Rav1e even threads much. That's why I ran x264 at 1 thread too, to get even ground in the multithreading quality trade-offs (with the idea that Rav1e doesn't make them yet but will in the future when it threads).

Edit: Or not - looks like threading as well as some other options were added after my testing.

[Atak_Snajpera]

https://i.imgsafe.org/3d/3da34b7c3e.png

[Wolfberry]

Take a look at the source code: https://github.com/xiph/rav1e/blob/master/build.rs#L25
So yes, nasm is explicitly disabled on windows.

[mandarinka]

Seems threads and other new options got introduced in after the build I used. Though that should not matter for quality, I used the slowest possible one before the speed levels rebalancing.

Does anybody have any explanation about what the --train-rdo flag does?
And also, what does bottom-up encoding mean?

[Atak_Snajpera]

Why rav1e ignored my 5Mbps bitrate and gave me 10Mbps ?!?
https://i.imgsafe.org/40/40b77cd424.png

When I was watching encoded file I was quite impressed by quality but then I realized that I was comparing 10Mbps AV1 with 5Mbps x264 :(

comparision
AV1 10Mbps vs x264 10Mbps
https://www.mediafire.com/file/t3hwslldv5vzlk2/AV1-10Mbps.mkv/file
https://www.mediafire.com/file/bhyulmmn5hn122n/x264-10Mbps.mkv/file

quick screenshots
AV1 -> http://atak-snajpera.5v.pl/images/AV1-10Mbps.mkv_snapshot_00.03.000.png
x264 -> http://atak-snajpera.5v.pl/images/x264-10Mbps.mkv_snapshot_00.03.000.png

spoiler AV1 is still in (blurry) woods...

[mandarinka]

Rav1e rate control is rather basic I think, they only just landed a first attempt on it. You generally want to encode AV1 (even with 1pass cqp) and then run 2-pass x264 to match, like I did :)

Edit: looks like it doesn't do too well on PJ either, the grassy bank is obvious but also the people are still artifacty. x264 has sharp artifacty edges on the figures while Rav1e has them blurrer which might be more pleasant, but it still artifacts a lot there. (and I wonder what's with the superstrong artifacting in the first few frames).

[Wolfberry]

Information about train-rdo: https://github.com/xiph/rav1e/pull/948
It is currently disabled at all speed levels since it is not usable yet.

[mandarinka]

Or so it is approximate (worse) RDO that uses cost estimates based on a trained model instead of actual values.
(So a speed option, not something improving quality).

I guess I could have figured that out from the name, should have put more thinking into it.

[IgorC]

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.
MPC-BE 1.5.3 (build 4455) beta (https://forum.doom9.org/showthread.php?p=1867953#post1867953) has switched from libaom to dav1d 0.2.x

[hajj_3]

MPC-BE 1.5.3 (build 4455) beta (https://forum.doom9.org/showthread.php?p=1867953#post1867953) has switched from libaom to dav1d 0.2.x

great news, i just tested it, it uses far less cpu playing av1 files than before :)

[Nintendo Maniac 64]

great news, i just tested it, it uses far less cpu playing av1 files than before :)

I was paranoid that this would only be the case for AVX-enabled CPUs, but even on my AVX-less Haswell Pentium G3258 I was seeing ~50% faster performance than what I would get via MPC-HC v1.8.4 with its built-in LAVfilters.

[sneaker_ger]

Yes, the dav1d developers added a lot of SSSE3 optimizations for older CPUs. AVX is useless, AVX2 is good. See the discussions and links on the last pages.

[Nintendo Maniac 64]

I also just tried a very recent nightly build of LAVfilters as well (0.73.1-30 built on 2019-03-08), and unfortunately the resulting performance indicates that it's likely still using the AOM decoder.


older CPUs

Reminder that even the newest Pentiums lack AVX. Heck in terms of actual IPC and performance-per-clock, my own Pentium is only two generations old, and one of those generations were practically skipped-over for the desktop.

[nevcairiel]

I also just tried a very recent nightly build of LAVfilters as well (0.73.1-30 built on 2019-03-08), and unfortunately the resulting performance indicates that it's likely still using the AOM decoder.


LAV will be switching to dav1d 0.2.1 soon, which was released only minutes ago. I wanted to use 0.2.0 already but knowing that a small improvement was coming up shortly, it made sense to wait.

[LigH]

New uploads: (MSYS2; MinGW32: GCC 7.4.0 / MinGW64: GCC 8.3.0)

AOM v1.0.0-1457-geca009dba (https://www.mediafire.com/file/l0kwzzlkz0mk36n/aom_v1.0.0-1457-geca009dba.7z/file)

rav1e 0.1.0 (fbecf18 / 2019-03-13) (https://www.mediafire.com/file/836rpxr2cqar688/rav1e_0.1.0_2019-03-13_fbecf18.7z/file)

dav1d 0.2.1 (408d048 / 2019-03-13) (https://www.mediafire.com/file/yopfiwjye3cgye8/dav1d_0.2.1_2019-03-13_408d048.7z/file)

[IgorC]

Good News: AV1 Encoding Times Drop to Near-Reasonable Levels (https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Good-News-AV1-Encoding-Times-Drop-to-Near-Reasonable-Levels-130284.aspx)

https://dzceab466r34n.cloudfront.net/Images/ArticleImages/InlineImages/122183-AV1-Figure1-ORG.jpg

[Tommy Carrot]

Good News: AV1 Encoding Times Drop to Near-Reasonable Levels (https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Good-News-AV1-Encoding-Times-Drop-to-Near-Reasonable-Levels-130284.aspx)


Indeed, it's getting faster. Unfortunately at the cost of compression efficiency, according to my tests it has gotten worse by about 3-5% since december, and --cpu-used=0 currently barely has better quality than --cpu-used=1 had 3 months old ago, while the encoding speed is still being slower. In other word, for the same quality/efficiency, the encoding speed hasn't really improved much, but the maximum efficiency has gotten worse.

[EwoutH]

The VLC Dev and 3.0 branches now use dav1d 0.2.1.

Here are new Nightly builds for:

VLC Dev Windows (64-bit) (https://nightlies.videolan.org/build/win64/last/)
VLC 3.0 Windows (64-bit) (https://nightlies.videolan.org/build/win64/last-3/)
VLC Android 3.1 (64-bit) (https://nightlies.videolan.org/build/android-armv8a/)

Chimera (http://download.opencontent.netflix.com/?prefix=AV1/Chimera/) (8-bit 1080p) now plays most scenes fluently on my Galaxy S7 (Exynos 8890 with 4x Mongoose 1, 4x Cortex-A53 and 4GB LPDDR4). Summer in Tomsk 1080p (from Elecard (https://www.elecard.com/videos)) plays fluently, while Summer Nature 1080p still has a stutter here and there (bitrate is a lot higher). 720p videos are now decoded without a hitch.