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]
http://www.compression.ru/video/codec_comparison/hevc_2017/MSU_HEVC_comparison_2017_P5...Q_encoders.pdf
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.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays!
+ Reply to Thread
Results 1 to 10 of 10
Thread
-
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.
-
https://github.com/xiph/rav1e
Overview
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.
Features
X Intra frames
X 64x64 superblocks
X H, V, and DC prediction modes
X 4x4 DCT and ADST transforms
X Realtime 480p encoding
-
Did you not read what I posted? VP9/AV1 aren't meant to be deployed on a multi-core machine like x264/5. They are meant to be deployed across massively parallel nodes which puts the onus on the organization with sufficient resources using it, not to mention the laborious process of fine tuning the parameters to suit the organization's needs.
For DASH encoders, whether or not AV1 is well supported among consumer players is irrelevant because all they care about is building support for it into their app/browser.
Bottomline, these codecs are built for a completely different ecosystem. -
I could ask you the same thing.
AV1 is certainly single core at the moment but VP9 is multicore able. It even has muticore encoding on by default, and I will repeat myself. "Encoding with VP9 via 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."
https://groups.google.com/a/webmproject.org/forum/#!msg/codec-devel/2zYWenmdUM8/n7_KPkQAEjAJ
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.
On my system, I can decode my encoded AV1 720p videos in realtime using the provided decoder and MPV. My CPU usage was low, which I was kind of impressed by. I could not manage to encode 1080p or higher videos, for decoding purposes, due to encoding times.
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
-
AV1 is better, ignoring the massive amount of time it takes to encode with the slowest settings.
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.
Similar Threads
-
12th annual / 2017 MSU Codec Comparison results
By sophisticles in forum Latest Video NewsReplies: 0Last Post: 28th Aug 2017, 00:21 -
Subtitle Comparison
By xweel in forum SubtitleReplies: 2Last Post: 15th Feb 2016, 15:21 -
The first HEVC codecs comparison by MSU Laboratory
By Stears555 in forum Video ConversionReplies: 22Last Post: 20th Nov 2015, 21:53 -
TBC Comparison
By magikarp99 in forum RestorationReplies: 77Last Post: 4th Feb 2014, 16:04 -
D-SLR comparison
By andrewgerm in forum Camcorders (DV/HDV/AVCHD/HD)Replies: 7Last Post: 17th May 2013, 04:02