Alliance for Open Media codecs

[Nintendo Maniac 64]

Well then, as someone with much more expertise in audio than video, Opus not being compatible with MP4 is a big win for WebM in my book.

...unless you do streaming in the same manner that YouTube does whereby you just deliver completely independent streams for audio and video, therefore allowing you to use MP4 and WebM streams concurrently (sometimes a recently-uploaded video will have VP9 video encodes but only AAC audio encodes for whatever reason; here's an example video of such (https://www.youtube.com/watch?v=miE1nrkjmUA) that has VP9 video yet only AAC audio as of this comment).

[Blue_MiSfit]

Well then, as someone with much more expertise in audio than video, Opus not being compatible with MP4 is a big win for WebM in my book.

...unless you do streaming in the same manner that YouTube does whereby you just deliver completely independent streams for audio and video, therefore allowing you to use MP4 and WebM streams concurrently (sometimes a recently-uploaded video will have VP9 video encodes but only AAC audio encodes for whatever reason; here's an example video of such (https://www.youtube.com/watch?v=miE1nrkjmUA) that has VP9 video yet only AAC audio as of this comment).

So - speaking from the perspective of an OTT operator, having separate audio and video files is quite common for both HLS and DASH. This is basically mandatory the second you want to offer more than one audio track (e.g. multiple languages or 2.0 vs 5.1 etc).

I believe YouTube uses DASH by default on modern browsers. I know you can do fMP4 and webm via DASH but I didn't realize you could mix both in a DASH manifest, but YouTube is clearly doing this with their AV1 + Opus streams.

I do imagine that YouTube's JavaScript player is quite specialized though. I wouldn't expect this to work OOTB on other DASH clients like a Roku or something like dash.js (even if the underlying audio / video decoders supported AV1 and Opus) - but then again I've never tried :)

[benwaggoner]

I don't think that mp4 store opus/vorbis for one. Probably the most efficient lossy audio codecs.
xHE-AAC is really very good and going to be widely adopted in the mobile ecosystem. Similar mixed voice/other encoding like Opus. significantly better quality <24 Kbps in my limited testing.

As for container, WebM and MKV just aren't used for mainstream commercial content or streaming outside of YouTube. MP4 has a huge and mature ecosystem that is already deployed, and there's nothing about WebM that would justify the cost of switching ALL those components to ones that support WebM. There are so many components for transport, muxing, demuxing, encryption, decryption, fragmentation, ALL of which would have to be updated for WebM to be viable. All it takes is a few legacy-but-supported devices that can't use WebM to keep an organization from even contemplating switching. And even if all the components were updated, what would switching from MP4 improve?

I can't imagine any container format replacing MPEG-4 for at least a decade. If new container features are needed, they'll most likely be done as an official extension of MP4 by MPEG.

[mzso]

@benwaggoner
Well, I for one don't care at all about <100kbps crappines whatever the codec may be.

[Zebulon84]

From what I understand, the main point of AV1 is to have a good royalty free codec. Why associate it with an audio codec that require licensing like xHE-AAC, when an equivalent royalty free codec like opus exist ?
Compatibility is not an issue, as nothing is compatible with AV1 today, so you can just add both together.

[IgorC]

xHE-AAC is really very good and going to be widely adopted in the mobile ecosystem.
???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

[benwaggoner]

@benwaggoner
Well, I for one don't care at all about <100kbps crappines whatever the codec may be.
You may not. But if you are in rural India on a 2G network, you would care a LOT. And have a lot of company.

Or, if you are in a subway, or on airport WiFi.

[Nintendo Maniac 64]

Hey, has anyone tried decoding AV1 on a CPU that lacks AVX and seeing what the resulting CPU utilization is? (for reference, even the newest 2c/4t Coffee lake Pentiums lack AVX) I'm starting to wonder if my Xeon's under-utilization is due to the fact that my CPU completely predates AVX...

I know that a similar thing happened in the past where VP9 had some heavy optimizations for SSSE3 (I don't believe this is the case anymore) which resulted in something like a 2.5x performance gain simply by having SSSE3 support (which wasn't present on AMD CPUs until 2011).

[MoSal]

Hey, has anyone tried decoding AV1 on a CPU that lacks AVX and seeing what the resulting CPU utilization is? (for reference, even the newest 2c/4t Coffee lake Pentiums lack AVX) I'm starting to wonder if my Xeon's under-utilization is due to the fact that my CPU completely predates AVX...


I know this doesn't exactly answer your question, but I profiled the decoder with an AVX2-capable CPU, and while there are hot AVX2 optimized functions (namely the ones called by av1_make_inter_predictor), a lot of (currently) hot functions are still implemented in C (e.g. av1_read_coeffs_txb and od_ec_decode_cdf_q15). So the decoder is still not well-optimized SIMD-wise, regardless of the instruction set.

Everyone will probably end up using ffav1 anyway, so this shouldn't really matter.

[lvqcl]

Everyone will probably end up using ffav1 anyway

From Video Dev Days 2018 (September 22) (https://www.videolan.org/videolan/events/vdd18/):
Dav1d: a fast new AV1 decoder

Dav1d is Dav1d.

[LigH]

Nice ... another alternative to aomenc, similar to rav1e (by team Xiph), here by team VideoLAN.
_

:o Oops: decoder.

[mandarinka]

I plan to add debugging options exactly for the purpose of getting feedback from users - the first obvious thing to add is the internal cdef-dist parameters to tune them. That said, they will remain debug options - for example, we may change how cdef-dist works internally when we find a better way to do it, and that will break the options. If you find a combination of debug options that looks better, I'd rather you report it as a bug and we use that information to change the defaults.

I don't think that's going to be viable. The point of tweakability is that the changes taht improve one source don't improve all sources. I would be surprised if one set of magic numbers were ideal for all content. And likewise, even beyond that objective factor, people have different ideas about how should the video look and that requires ability to change settings too and again precludes one specific setting from being ideal for everything.

Hmmm, makes me think... Doom9 has this in its forum rules: "There is no best".
It's not a straightforward "video truth" (heh), but the reason behind it most likely has a connection exactly with this case. In video processing/compression, you usually don't have an absolute correct and final answer that is true always, regardless of context. Personally I agree with it that there is not one best aq-strength, psy-rdo, crf and so on. IMHO it's going to happen with Rav1e options too.

[Selur]

Since when feeding 10bit yv12 with profile I get:
Profile 2 bit-depth < 10 requires 4:2:2 color format
I got a small question:
What color sampling and bit depth combinations are supported in which profile when using aomenc?

Cu Selur

[nevcairiel]

You should be using Profile 0 (Main) for 10-bit 4:2:0 for maximum compatibility.

The general AV1 rules are pretty simple:
Main Profile (0) is 8/10-bit 4:2:0 or Monochrome (4:0:0)
High Profile (1) is 8/10-bit 4:2:0, 4:4:4, Monochrome
Professional Profile (2) is 8/10/12-bit, 4:2:0, 4:2:2, 4:4:4, Monochrome

I would assume that the encoder follows the same rules - and judging by that message it even enforces the "use the lowest profile possible" suggestion?
I don't know right off the top of my head if the profiles actually influence anything else beyond the bitdepth/chroma, but I don't think so, which gives you little to no reason to use a higher profile when you don't need its chroma/bitdepth extensions.

[foxyshadis]

I like more the second round testing at lower data rates and this comment:

You should focus your tests on the data rates at which your video will most likely be deployed. At this point, H.264 and any newer codec should produce near perfect quality at 6 Mbps, making that data rate irrelevant for forward-looking testing. HEVC and VP9 take the near perfect quality level down to between 3.5Mbps to 4Mbps, and AV1 and future codecs should bring this down into the 2Mbps to 3.5Mbps range.

The bias of this comment is obvious: This is targeting the little-to-no-grain FHD segment. Grain is basically an uncompressible random number generator, the only only way out is tons of bitrate or FGM. People are going to hate on AV1 the same way they hate on HEVC because it won't store film grain efficiently, since neither codec is even remotely targeting that.

[foxyshadis]

@benwaggoner
Well, I for one don't care at all about <100kbps crappines whatever the codec may be.

It has nothing to do with only being good at crap bitrates, and everything to do with having one codec that can go from 8kbps to 500kbps without compromise, the one codec to replace them all. That is the siren call of Opus, and that is the promise of xHE-AAC, although it hasn't exactly been realized yet. IMHO it's still better to have two heavyweights that are better than everything else out there, because it keeps the pressure on to keep improving.

???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

Spotify has been using it all year at the 24kbps point, and they're working on moving it up the stack. Android 9 has made it mandatory. (Android 5 made Opus mandatory.)

[Mr_Khyron]

From Video Dev Days 2018 (September 22) (https://www.videolan.org/videolan/events/vdd18/):
Dav1d: a fast new AV1 decoder
Ronald Bultje is making the decoder?!!

So we will have the worlds fastest AV1 decoder soon ;)
https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/

:)

[IgorC]

Spotify has been using it all year at the 24kbps point, and they're working on moving it up the stack. Android 9 has made it mandatory. (Android 5 made Opus mandatory.)
Spotify uses HE-AAC for lowest bitrate mode, not xHE-AAC.
As for the rest of bitrates they use Vorbis and LC-AAC. There is no quality benefit from xHE/HE-AAC codec at higher rates. Add to it that Vorbis is free and LC-AAC patents will expire in 2 years.
https://support.spotify.com/us/using_spotify/system_settings/high-quality-streaming/


Android 9 has made it mandatory.
That's a decoder. There is still no any encoder (and it won't be)
Remember MPEG surround format? It's 11 years old ... with zero adoption. xHE-AAC goes a same road with its 6 years of 'unadoption'. After MP3 and (HE)AAC none of a new mpeg audio format has seen any meaningful adoption.

[marcomsousa]

ffmpeg 2018-09-13 zeranoe build
ffmpeg -threads 4 -i 1080.mp4 -benchmark -f null -
ffmpeg version N-91943-g1b98bfb932
[libaom-av1 @ 000001e19c898940] 1.0.0-507-g5d963cb57

frame= 1736 fps= 19 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=0.637x
bench: utime=88.703s stime=0.938s rtime=90.919s
bench: maxrss=233580kB

ffmpeg 2018-09-16 zeranoe build
ffmpeg -threads 4 -i 1080.mp4 -benchmark -f null -
ffmpeg version N-91961-g5109c38162
[libaom-av1 @ 000001b015cfd8c0] 1.0.0-590-g6fa400604

frame= 1736 fps= 34 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=1.15x
bench: utime=100.594s stime=2.812s rtime=50.395s
bench: maxrss=274472kB

The new ffmpeg builds with a newer libaom-av1 improves performance a lot (like SmilingWolf said)

[iwod]

Add to it that Vorbis is free and LC-AAC patents will expire in 2 years.



Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.

[mzso]

Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.

Why? Because around no-one cares about it by now?

[LigH]

In general, generalizations are wrong... "no-one" is a strong assumption without proof over the whole population of earth using technology compatible to LC-AAC already (e.g. iTunes).

If you don't care about AAC, it's your choice. But don't assume about anyone else.

[Blue_MiSfit]

Let's try to keep discussion focused on AV1, guys ;)

[marcomsousa]

Let's try to keep discussion focused on AV1, guys ;)

Can doom9 promote AV1 and give an sub-forum like for HEVC?

So we can have more specialized threads:

AV1

Software adoptions
HW compatible
libaom
Rav1e
Dav1d
Tune with parametres
10bit and 12bit
Quality compare
Performance compare
Custom Builds
Containers
Etc...

[hajj_3]

???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

xHE-AAC was added to the DRM+ digital radio standard which india is rolling out. It may still become popular in the future if DRM+ becomes popular.

I can't see it becoming popular online due to the patent costs especially as Opus 1.3 has improved lower bitrates recently and will continue to improve.

[foxyshadis]

Can doom9 promote AV1 and give an sub-forum like for HEVC?

So we can have more specialized posts:

News
Software adoptions
HW decode compatible
HW encode compatible
Tune with parametres (libaom-av1)
Tune with parametres (ffmpeg)
Tune with parametres (others)
10bit and 12bit
Quality compare
Performance compare
Custom Builds
Containers
Etc...


As much as I'm hoping AV1 sets the world on fire, especially once it's released from Google's "performance? who needs optimization when you have the world's largest server farm?" attitude, Doom9 is about interest more than promotion. So far there just aren't that many posts about AV1; compare the HEVC forum. Some of those threads are obvious duplicates or way too niche, but if you want to go ahead and found a dedicated AV1 tuning or comparison thread, go ahead.

News goes in the news forum, naturally.

[hydra3333]

So far there just aren't that many posts about AV1; compare the HEVC forum.
OK. Possibly only for now, though ? A novice like me and perhaps most punters may have reasonably inferred that with google and so many (almost all ?) large industry players signed up and behind it that it is likely to receive growing attention. Just a thought.

[IgorC]

Sorry for offtopic. Last one and probably will get it somewhere else.
Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.
It's difficult to say. I'm not a lawyer. I just saw some patent related estimations here http://www.ecodis.de/audio.htm
Especially when laws change per country. Also there are decoding and encoding related patents. MP3 decoding related patents have expried in 2015 but encoder patents in 2017. https://www.cs.helsinki.fi/group/pakkaamo/docs/legal.pdf

It might be the case that patents of LC-AAC have already expired.
Will investigate.

[Nintendo Maniac 64]

The new ffmpeg builds with a newer libaom-av1 improves performance a lot (like SmilingWolf said)

MPC-HC v1.8.2 also got released - could you perhaps confirm/deny whether its built-in LAVfilters also contain these performance improvements?

Thing is, I saw no performance gains when using 1.8.2 vs 1.8.1, so I need to confirm/deny whether my performance issue is persisting or whatnot.


I did however notice that, out of the three cores being utilized on my Xeon x3470, one of them is pretty much fully pegged and the other two are about half utilization - this would then equal the ~25% utilization I'm seeing.

Now normally I would let this all go as simply a case of "not having fast enough single-threaded performance" and be done with it, but the fact that you and others were seeing over 60% utilization on your own 4c/8t CPUs (which implies it was balancing the load across more than 4 threads) makes me thing something still isn't quite right here - I mean, weaker single-threaded performance shouldn't result in fewer threads being utilized, and if anything you'd want it to be the opposite, no?

[lvqcl]

I downloaded aom-master.tar.gz (that is, the latest sources), recompiled libaom amd ffmpeg libs myself, and I cannot see speed increase over vanilla LAVFilters-0.72.0-13.

Also: according to LAVFilters sources, it uses AV1 library v1.0.0-552-gbb82e05fb which does have that "row-based multi-thread decoding" patch.

[Selur]

Got a few additional questions about aomenc, since I couldn't find any doc about it.

Does anyone know where I can lookup the default values for all the options where the help doesn't provide a default value?
What are the allowed values for '--usage' and '--profile'?
What is the difference between 'Usage' and 'Bitstream' profile?
What are the 'forced_max_frame_width' and 'forced_max_frame_height' values for? Does the force to encoder to internally not downscale width/height?
What is the recommend value for '--timebase' and when should one change this value?
What is the 'resize-mode'-option for and what are valid values for it?
What are the 'superres' options for?
What are S-frames and what are the sframe-modes?
What does the 'input-chroma-subsampling' options for and what are valid values for them?


Thanks for anyone who help with some answers. :)

Cu Selur

[SmilingWolf]

Got a few additional questions about aomenc, since I couldn't find any doc about it.

Does anyone know where I can lookup the default values for all the options where the help doesn't provide a default value?


You can check some defaults here: https://aomedia.googlesource.com/aom/+/master/av1/encoder/speed_features.c
Not the most user friendly way but that's all there is for now unfortunately

As for the other questions, my best guess is that they are described one way or the other in the spec.
Or in the sources... somewhere. Yeah not quite the best for end users.

[easyfab]

encoding default :
https://aomedia.googlesource.com/aom/+/master/av1/av1_cx_iface.c#107

[Selur]

Thanks! :)
about s-frames (switching frames): https://www.youtube.com/watch?v=o5sJX6VA34o seems to be only interesting for abr low latency live streaming, so not interesting when you don't have multiple streams of different bitrates available.

[Blue_MiSfit]

Very cool. I should go to Demuxed this year!

[lvqcl]

Found this comment (https://aomedia.googlesource.com/aom/+/master/av1/decoder/dthread.c#44) in libaom code:
// TODO(hkuang): Fix the pthread_cond_broadcast in windows wrapper.
Apparently it was made in this commit for vp9 (https://chromium.googlesource.com/webm/libvpx/+/d5fa786b4f881bc50663a0c1333a053e99406dfa%5E%21/vp9/decoder/vp9_dthread.c). I wonder is it still true?

(Also, libaom phtreads wrapper (https://aomedia.googlesource.com/aom/+/master/aom_util/aom_thread.h) has a lot of code for pre-Vista Windows. Why? Nobody bothered to clean it up? ;))

[LigH]

The last issue (unaligned memory access in GCC 8.2.0) was marginally related to cleaning up VP9 remains... :o

[marcomsousa]

I have diferent Coding path when encoding with differents aom builds with the same y4m.

Coding path: LBD
Coding path: HBD

Can't you explain why and how to change this?

[SmilingWolf]

My builds come with the CONFIG_LOWBITDEPTH build option enabled.
It enables 8bit content optimized codepaths, which work roughly 2x (in theory) - 1.75x (in practice) faster than the high (10-12) bit depth codepaths because you can stuff 8 bits in just 8 bits of memory, while to use 10-12bits you need to use 16 bits of memory, halving the throughput.
The default of that build options is 0, which means the 8bits codepaths are never used, and a lot of builds out there just use default settings (MABS ones in primis).

Lotsa yadda yadda on my part, issues 2062 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2062) and 2147 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2147) probably explain better what this means for end users

Side note: today's build are complete, few minutes they'll be up on MEGA.
There's a little feature I've been keen to try for a long time now: loop filter bitmask (https://aomedia.googlesource.com/aom/+/84b09935284d56def49cca7d7f79aa8265566c0b) for decoding, which promises a 6% decoding performance increase in single thread (https://aomedia.googlesource.com/aom/+/c75fb08f653b7614cdbe8e840140cb6617022ce3)

[LigH]

I will mention this in the MABS project, maybe wiiaboo agrees to enable it (or even make a choice to build either or both, like for x264 and x265, unless that are able to provide a multilib solution as well).

[SmilingWolf]

I think there's no need for CONFIG_LOWBITDEPTH=0 builds, with CONFIG_LOWBITDEPTH=1 the appropriate codepaths are selected automatically based on input and output bit depths.

Today's build:
av1-1.0.0-629-g7b9ddd4bf: https://mega.nz/#!cg5njRjA!WZkuEg2g7qDdAjq19nAhd3dlGnQa-vEcCgQL5_vRMY8

Cautionary note: the issues tracker has been populating quite fast the last couple of days, so there's a chance this is not the most stable build to work with.
I have just finished a series of encodes that took all week , so I'll be able to try it and report back if anything nasty happens.
Also, some coding features have been temporarily disabled for row-mt (https://aomedia.googlesource.com/aom/+/2fc59df195a7579bb8d5e6223da26e883d0f7a02) to accomodate some corner cases

Silver lining: the code is being modified to enable easier debugging of threading related issues, so maybe we'll see some newfound stability on that front in the coming days/weeks

[marcomsousa]

I'm building (yet another version) AOM with Visual Studio 2017 from sources.

They are automatically builds

AV1 executable builds: here (https://ci.appveyor.com/project/marcomsousa/build-aom/build/artifacts)
I also open source the build scripts at Github: here (https://github.com/marcomsousa/build_aom)

I note that with VS2017 generates a lot of *.exe compare with gcc


aomdec.exe
decode_with_drops.exe
decode_to_md5.exe
twopass_encoder.exe
dump_obu.exe
lightfield_decoder.exe
lightfield_bitstream_parsing.exe
lightfield_encoder.exe
aom_cx_set_ref.exe
lightfield_tile_list_decoder.exe
aomenc.exe
lossless_encoder.exe
noise_model.exe
scalable_decoder.exe
resize_util.exe
scalable_encoder.exe
set_maps.exe
simple_encoder.exe
simple_decoder.exe


At this moment I'm only saving aomenc.exe and aomdec.exe.
You can do pull requests to improve this script.

[SmilingWolf]

All of that EXEs are generated under MSYS2 too, they are simply not installed by "make install" because they are examples or test tools, not meant for the end user.
# find . -name \*.exe -type f
./aomdec.exe
./aomenc.exe
./CMakeFiles/3.12.1/CompilerIdC/a.exe
./CMakeFiles/3.12.1/CompilerIdCXX/a.exe
./examples/aom_cx_set_ref.exe
./examples/decode_to_md5.exe
./examples/decode_with_drops.exe
./examples/lightfield_bitstream_parsing.exe
./examples/lightfield_decoder.exe
./examples/lightfield_encoder.exe
./examples/lightfield_tile_list_decoder.exe
./examples/lossless_encoder.exe
./examples/noise_model.exe
./examples/scalable_decoder.exe
./examples/scalable_encoder.exe
./examples/set_maps.exe
./examples/simple_decoder.exe
./examples/simple_encoder.exe
./examples/twopass_encoder.exe
./resize_util.exe
./tools/dump_obu.exe
Love the AppVeyor integration! Thanks!

[LigH]

Just chatted a bit in IRC ... gnafu believes that CONFIG_LOWBITDEPTH=1 is a) still necessary to be set at compile time, b) in general useful, because it enables an optimized code path for 8 bit precision only, but does not alter the behaviour of higher bit depths.

I hope he is right.

[marcomsousa]

Just chatted a bit in IRC ... gnafu believes that CONFIG_LOWBITDEPTH=1 is a) still necessary to be set at compile time, b) in general useful, because it enables an optimized code path for 8 bit precision only, but does not alter the behaviour of higher bit depths.

I hope he is right.

I tested with CONFIG_LOWBITDEPTH=1 and it's faster. But it was disable because something...

Turn off CONFIG_LOWBITDEPTH by default

CodecWG agreed to have this off for default "C" model.
Commit (https://aomedia.googlesource.com/aom/+/155120f44aad2fce30f5a8a4ba2a15653e0e2f8f%5E%21/)

[alex1399]

Who is gnafu?

[SmilingWolf]

Who is gnafu?

https://freenode.logbot.info/aomedia/20180921

If your question is "who's him in the project", I think he's just an enthusiast like most of the people here on doom9

[SmilingWolf]

Graphs time! Click to enlarge
Y axis: chosen metric
X axis: bits per pixel

720p:
https://thumb.ibb.co/fj5BWe/msssim_720.png (https://ibb.co/fj5BWe)https://thumb.ibb.co/dnZS4z/psnrhvsm_720.png (https://ibb.co/dnZS4z)

1080p:
https://thumb.ibb.co/fW9GxK/msssim_1080.png (https://ibb.co/fW9GxK)https://thumb.ibb.co/irpujz/psnrhvsm_1080.png (https://ibb.co/irpujz)

BD rates for 720p:
rav1e -> x264
RATE (%) DSNR (dB)
MSSSIM -18.3758 0.910887
PSNRHVS -17.3064 1.14428

x264 -> x265
RATE (%) DSNR (dB)
MSSSIM -25.6195 1.21115
PSNRHVS -29.8289 1.83058

x265 -> av1
RATE (%) DSNR (dB)
MSSSIM -16.6292 0.680221
PSNRHVS -13.0642 0.641722

BD rates for 1080p:
rav1e -> x264
RATE (%) DSNR (dB)
MSSSIM -19.4204 0.869977
PSNRHVS -16.9114 0.949348

x264 -> x265
RATE (%) DSNR (dB)
MSSSIM -28.9956 1.18206
PSNRHVS -31.474 1.63676

x265 -> av1
RATE (%) DSNR (dB)
MSSSIM -24.1474 0.840846
PSNRHVS -19.4281 0.796909


Clips used for 720p: F.Y.C, KimiNoNa720, PresageFlowerFight720, PresageFlowerWalk720, TearsOfSteel720, TheFifthElement, ThisIsHalloween
Clips used for 1080p: KimiNoNa, PresageFlowerFight, PresageFlowerWalk, TearsOfSteel

Encoders:
x264 157-2932-303c484
x265 2.8-68-fa57fa584898
rav1e 0.1.0-315-1fa32bbd
av1 1.0.0-577-g8ae39302e

VQM Tools:
dump_msssim and dump_psnrhvs from the daala git repo: https://github.com/xiph/daala
Everything glued together with some bash and python2 scripts
The metrics used are from the Total field of the tools' output, so they take into account both luma and chroma. In dump_msssim this just looks like an arithmetic mean between the three measurements, while dump_psnrhvs applies some weighting.
The final metrics-per-resolution have been obtained taking the measurement for each clip and weighting it with the number of pixels.

Cmdlines:
x264 --preset veryslow --tune ssim --crf 16 -o test.x264.crf16.264 orig.i420.y4m
x265 --preset veryslow --tune ssim --crf 16 -o test.x265.crf16.hevc orig.i420.y4m
rav1e -o test.rav1e.cq80.webm --quantizer 80 -s 3 --tune psnr orig.i420.y4m
aomenc --frame-parallel=0 --tile-columns=6 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --threads=4 --end-usage=q --cq-level=20 --test-decode=fatal -o test.av1.cq20.webm orig.i420.y4m

Quality settings:
x264: CRF 16-24 step 1, and 24-34 step 2
x265: CRF 16-24 step 1, and 24-34 step 2
rav1e: CQ 80-160 step 16
aomenc: CQ 20-40 step 4

Clips used:
F.Y.C: https://amvnews.ru/index.php?go=Files&in=view&id=6801, second link, the 250.78Mb one. Clip cut with ffmpeg -ss 00:00:10 -t 20, 1280x720, 480 frames
KimiNoNa and KimiNoNa720: scene from the Kimi no Namae Wa, BD source. Clip cut with ffmpeg -ss 00:01:13 -t 17, 1920x1080, 410 frames
PresageFlowerFight and PresageFlowerFight720: scene from Fate/stay night: Heaven's Feel - Presage Flower, BD source. Clip cut with ffmpeg -ss 00:43:50 -t 15, 1920x1080, 360 frames
PresageFlowerWalk and PresageFlowerWalk720: scene from Fate/stay night: Heaven's Feel - Presage Flower, BD source. Clip cut with ffmpeg -ss 00:15:14 -t 13, 1920x1080, 312 frames
TearsOfSteel and TearsOfSteel720: https://media.xiph.org/tearsofsteel/tearsofsteel-1080bis-png/ frames 13500 to 13900, 1920x800, 400 frames
TheFifthElement: clip found on the #aomedia channel: https://freenode.logbot.info/aomedia/20180726 -> themayhaks.com/~gideon/tfe.mkv, 1280x534, 240 frames
ThisIsHalloween: https://www.animemusicvideos.org/members/members_videoinfo.php?v=196998, second link, the LOCAL/123 MiB one. Clip cut with ffmpeg -ss 00:01:50 -t 15, 1280x720, 450 frames

Clips notes/misc details:
All of them have been losslessly cut and stored in FFv1 in an MKV container to serve as master files, decoded to y4m for encoding. All the master files use 8bits 4:2:0 subsampling, and so do the encodes.
The *720 clips actually have been resized to a 1280 width and the heigth has been adjusted accordingly, so either 720 or 534 as required to keep the aspect ratio.
Resizing done with ffmpeg using the z.img library/zscale video filter, using a 4 taps lanczos kernel.
F.Y.C: mixed and superimposed anime/real life content, lots of effects, rain in a couple of scenes, fast motion, flashes, many scenecuts. AMV encoder unknown, final bitrate around 9.4Mb/s
KimiNoNa and KimiNoNa720: anime, detailed backgrounds, brief scene with moving croud, cut to moving trains, cut to moving background with static foreground, few scenecuts
PresageFlowerFight and PresageFlowerFight720: anime, fight between Rider and Saber for whoever knows what I'm talking about, lots of particles at some point, reasonably fast motion, few scenecuts
PresageFlowerWalk and PresageFlowerWalk720: anime, MC just walking around in the school, no really detailed backgrounds, mostly static and slow, very few scenecuts
TearsOfSteel and TearsOfSteel720: real life with synthetic/rendered elements, smoke, rapid camera movement and motion, very few scenecuts
TheFifthElement: real life, lots of film grain, static, very few scenecuts. The original uploader sourced the clip from the BD and resized it himself
ThisIsHalloween: anime, no effects, some flames in a scene, mostly static but brief scenes, many scenecuts. Scenes used come from the BD box of the anime (Soul Eater), the final encode of the AMV has been made with x264, CRF 15 and --preset veryslow --tune animation, final bitrate around 4.3Mb/s

As you have already noticed, my testbed mostly covers my personal interests: AMVs (F.Y.C and ThisIsHalloween) and anime in general, with some real life content thrown in the mix
Natural consequence, since I tailored this to my needs, is that I used only encoding settings I felt confortable with, especially with aomenc:
- maximum number of tiles allowed per clip for smooth playback and (whenever it didn't bug out) multithreaded encoding
- cpu-used no lower than 4 or I would have never seen the end of it

Alright, wall of text over, I'm open to any kind of feedback since I'm posting this to get corrections or suggestions

[NikosD]

Alright, wall of text over, I'm open to any kind of feedback since I'm posting this to get corrections or suggestions

Oh man!

I'm speechless of your work and of your post!

Good to see you around.

[marcomsousa]

...

Excelent post :thanks: