VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Results 1 to 8 of 8
Thread
  1. Hello,


    It's been a while since the last time I posted a QSV test and today I have something a bit different. As anyone that has been around the video encoding game knows, one of the common responses offered to a person that asks about hardware encoders is "x264+ultrafast+i7 is both faster and higher quality than" <insert hardware encoder here>.


    Well, I'm here to prove that this is not true, at least not completely. With the test system I used, i3 7100 (2C/4T), 8GB DDR4-2400, 32GB Optane SSD for swap, separate SSD's for read/write, x264+ultrafast was a tiny bit faster than qsv+quality setting in Handbrake, built from source on Manjaro Mate, with all the updates. This speed advantage held for all 4k test encodes I did, typically 2-3fps faster. Quality wise however, QSV HEVC easily beat x264+ultrafast. Adding 10bit to the mix, greatly increased the quality of the encodes in both their cases.



    I have run hundreds of test encodes, using source files from various sources, here are some test encodes.


    Some notes, I have read that Netflix uses 15MB/s for their 4k offerings, frankly they must be using some crazy filtering and industrial strength encoders because in my test 15MB/s is barely watchable with the Netflix samples available on Xiph Derf's, in fact setting x264 to use the defaults CRF23 and medium preset results in about 29MB/s, so the claimed 15MB/s is about half what x264 "thinks" should be used with the default settings.


    More considerations, if you are using Y4M or similar sources, it behooves you to get the fastest read drive you can, because I/O is a massive bottleneck when working with these types of sources. Similarly, if you are using jpeg2000 muxed in a MXF or ProRes Lossless, you need the fastest cpu you can afford with QSV because decoding is a huge bottleneck and QSV does not have hardware decode acceleration for these formats. QSV also has a maximum resolution support of 4k DCI, so if you plan on using an AVC source that's bigger than 4k, then you are still decoding on the cpu.


    Further, since Handbrake does not support hardware filtering or decoding at all, no matter what resolution the source is, if you use HB, then the decoding is done on the cpu, so again, buy the fastest cpu you can afford or use ffmpeg directly which supports hardware decoding and filtering via QSV.


    Hope someone finds these tests useful.
    Quote Quote  
  2. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    So x264+ultrafast 10bit is worse that QSV HEVC 10bit?
    Quote Quote  
  3. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    So it requires a GPU HEVC encoder to beat the x264 AVC encoder in its least-efforts settings. Fine. I can afford more efforts, though. No need for a top-speed scenario for me, personally.

    At least, thanks for your efforts to narrow this topic further.
    Quote Quote  
  4. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    Thatís not much of a valid test when you donít provide the source file for reference. Plus, if you are using Netflix clips as your source for some, not only are you going against terms of use there and potentially putting this site in jeopardy posting them here, but you are using a clip that already has been pre-processed and one which exhibits artifacts based on its original encode (which likely is HEVC, and thus unfairly giving an inherent bias towards that type).
    Get your act together.

    Scott
    Quote Quote  
  5. Originally Posted by Cornucopia View Post
    Thatís not much of a valid test when you donít provide the source file for reference. Plus, if you are using Netflix clips as your source for some, not only are you going against terms of use there and potentially putting this site in jeopardy posting them here, but you are using a clip that already has been pre-processed and one which exhibits artifacts based on its original encode (which likely is HEVC, and thus unfairly giving an inherent bias towards that type).
    Get your act together.

    Scott
    I told you were to get the sources, the sources are 30GB test files available here:


    https://media.xiph.org/video/derf/

    I believe this is the link, though I can't verify it at the moment because of my firm's firewall. Just type Xiph Derf into google and you will see the sources. These are provided by Net Flix themselves in Y4M format, not previously compressed, as test samples, I would think tat most members of this forum were aware of their existence.

    Before you comment, get your act together, this is a valid test, Net Flix has made available nearly 500GB of test sources, and I ran multiple test encodes with all of them, x264 was used as the reference encoder because that's the one most people recommend for archival and the 15MB/s bit ratewas used because that's what Net Flix supposedly uses for their 4k content, I do not know this for a fact since I do not have a Net Flix account but that is what I have seen reported.

    The artifacts that you see are not in the source, they are the result of x264+ultrafast poor encoding at that bit rate, all test encodes were done using 2 pass (except for the CRF, obviously) and the QSV are not the highest quality possible because Handbrakes "quality" setting for QSV chooses TU2, not TU1 (this is confirmed by diving into the code).
    Quote Quote  
  6. Originally Posted by LigH.de View Post
    So it requires a GPU HEVC encoder to beat the x264 AVC encoder in its least-efforts settings. Fine. I can afford more efforts, though. No need for a top-speed scenario for me, personally.

    At least, thanks for your efforts to narrow this topic further.
    Not quite, x264 will beat QSV AVC if you crank up x264's quality, but the speed tanks, even x264+medium+crf23 requires more than 15MB/s bit rate for 4k encodes, so the 15MB/s chosen test rate was to show the difference between the encoders.

    At 30MB/s and medium, x264's speed tanks, making QSV much faster and with QSV you can encode 5 stream simultaneously at full speed, at the highest quality setting, assuming you have the necessary I/O bandwidth, decoding speed and ram (Handbrake on Manjaro uses between 3-4 GB of ram per encode for 4k).

    The main benefit of QSV, other than the fact that with 10 BIT HEVC it's basically untouchable in terms of quality per speed, is the fact that you use less power than a pure software encoder and in theory at least, a casual video enthusiast that needs to encode content on a semi-regular basis, can do so cheaper than having to spend big bucks on a high end cpu and cooling solution.

    Or if someone has a laptop with a Skylake or better, they can put it to work encoding video while freeing up their main system.
    Quote Quote  
  7. I doubt that many people with ultra lowend CPU (2C/4T) will be using software encoder with 4k footage anyway. People doing video editing/compression will most likely use cheap Ryzen 1700 (8C/16T) for that. x264 + medium preset on that CPU is reasonable fast.
    Quote Quote  
  8. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    I've not looked at the videos but should point out that HEVC has a simple large block advantage. With HEVC supporting up to 64x64 blocks vs 16x16 for H.264. Which is why H264 is naturally disadvantaged above 1080p.
    Quote Quote  



Similar Threads