VideoHelp Forum
+ Reply to Thread
Results 1 to 10 of 10
Thread
  1. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    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.

    Image
    [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.
    Last edited by KarMa; 19th Feb 2018 at 21:57. Reason: minor
    Quote Quote  
  2. 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.
    Quote Quote  
  3. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    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 20:01.
    Quote Quote  
  4. 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

    Quote Quote  
  5. Originally Posted by KarMa View Post
    Encoding with VP9 via FFMPEG will use most of my 6 cores, if not completely 100% all of my 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.
    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.

    Originally Posted by KarMa View Post
    Not to mention nothing can really play AV1
    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.
    Quote Quote  
  6. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    Originally Posted by SameSelf View Post
    Did you not read what I posted?
    I could ask you the same thing.


    Originally Posted by SameSelf View Post
    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.
    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.



    Originally Posted by SameSelf View Post
    Originally Posted by KarMa View Post
    Not to mention nothing can really play AV1
    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.
    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.
    Quote Quote  
  7. 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? ¯\_(ツ)_/¯
    Quote Quote  
  8. Originally Posted by SameSelf View Post
    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.
    Evidence?
    Quote Quote  
  9. Member
    Join Date
    Dec 2012
    Location
    Germany
    Search Comp PM
    inapproachable nice, AV1 will be gold for users with a slow internet connection
    Quote Quote  
  10. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    Originally Posted by SameSelf View Post
    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? ¯\_(ツ)_/¯
    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.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!