MSU last month released results from another codec test, this time including the soon to be frozen AV1 (they used Version 0.1.0). Ignoring encoding speed, they found AV1 to be a clear winner at bitrate/quality efficiency.
[Attachment 44748 - Click to enlarge]
A few weeks ago I did my own visual AV1/x265/x264 tests and found AV1 at the absolute slowest settings to be obviously better than x265 placebo, but I was measuring encoding speed in a few frames a minute. When using the --good preset in AV1, it gave me a more normal 4 frame per second encoding but the line between --good AV1 and placebo x265 is barely there, making x265 still very worthwhile. Not to mention nothing can really play AV1, so I had to decode my encodings into raw YV12; and it still has not be standardized yet. In my experience AV1 is single thread only encoding, no matter how many threads I tell it to use.
+ Reply to Thread
Results 1 to 10 of 10
Last edited by KarMa; 19th Feb 2018 at 20:57. Reason: minor
Comparing VP9/AV1 vs x264/5 encoding speeds is not apples vs oranges because VP9/AV1 are not meant to be deployed on multi-core systems that encode a file in its entirety. Rather, the onus is on developers to split the file into many pieces, encode in parallel (think cloud), then stitch the resulting pieces back together. This is what Google/Youtube and host of other DASH encoders do, and it fits perfectly into their business model, especially with patent litigation being what it is. I suppose a consumer could implement a similar strategy if they use image sequences as their DI, but then considerable time would also need to be invested in fine tuning the options for VP9/AV1 which puts these codecs within the reach of only the savviest of hobbyist with time and cpu clocks to spare (versus mining the latest crypto). For the rest of us, x264/5 crf is about as hard as I want to think about the problem.
Encoding with VP9 via FFMPEG will use most of my 6 cores, if not completely 100% all of my 6 cores. Using the January 5th 2018 build of AV1, will only use 1 of my 6 cores, without ever touching the other 5. No matter the commands I give it.
Last edited by KarMa; 28th Feb 2018 at 19:01.
rav1e is an experimental AV1 video encoder. It is designed to eventually cover all use cases, though in its current form it is most suitable for cases where libaom (the reference encoder) is too slow.
Because AV1 is not yet frozen, it relies on an exact decoder version and configuration that is periodically updated.
X Intra frames
X 64x64 superblocks
X H, V, and DC prediction modes
X 4x4 DCT and ADST transforms
X Realtime 480p encoding
Bottomline, these codecs are built for a completely different ecosystem.
FFMPEG will use most of my 6 cores, if not completely 100% all of my 6 cores."
From my provided source - "VP9 encodes are faster with multithreaded encoding on by default."
Should also point out that VP9 is not a codec and instead libvpx (in fffmpeg) is the codec I'm talking about. Does Google use libvpx for encoding their Youtube content; based on how little attention they give it, probably not. I'm sure they have a better forked internal one. There are also a few other VP9 codecs that can be purchased from 3rd parties.
But for smartphones/tablets, they will need decoder chips which is a ways away.
I have no idea what you are trying to say. First you said MSU found AV1 to the clear winner ignoring encoding speed, but then you found x265 to be better, now AV1 is swole again? ¯\_(ツ)_/¯
inapproachable nice, AV1 will be gold for users with a slow internet connection
x265 is still better in the real world considering it has had 5 years of maturity and massive speed upgrades from better use of lower level assembly instruction sets, while the AV1 (AOMedia) encoder is for a standard that does not even exist yet. People tend to forget how slow the reference encoder for HEVC was before standardization.
I found x265 @placebo to be on par (more or less) with AV1 (AOMedia Codec) using the --good setting (which is some kind general fast setting). --good gave me ~4 frames per SECOND. So with the wide support for HEVC, the multicore support, and faster encodings make x265 better. AV1 wins however when using the default slowest settings which gave me like 2 frames per MINUTE, single core. The default slowest was noticeably cleaner and retained more detail. As with x264/x265/libvpx, we are just going to have to wait for the encoder to be optimized.
Currently they are still testing out their experiments which should of been finished back in like October of 2017 but they have been pushing the date back every month. They are running hundreds of tests encodes, deciding which features are worth including with the standard for the compression gains and which are not worth the CPU cycles. Which features should be mandatory and which should be in the higher optional tiers. They are also talking with hardware encoders/decoders makers to see which feature is possible for HW encoders/decoders and what is impractical.