I have edited my initial post, to make it more readable and focus more on the encoding tests, just in case someone happens to Google their way to this test at some point in the future.
The first source was the Tears of Steel 13Gb JPEG2000 MXF 4096x1714p24 converted to h264 lossless using x264, cropped to 4096x1712 (during encode to QSV, probably affected encoding speed slightly), for these samples I used Staxip to encode via QSVEnc with the following options:
detail-enhance 7 --colormatrix bt709 --colorprim bt709 --transfer bt709 --fullrange --d3d11 --sao none --ctu 64 --no-timer-period-tuning --fixed-func --vbr 5500
--codec hevc --quality best --profile main --trellis off --b-pyramid --vpp-detail-enhance 7 --colormatrix bt709 --colorprim bt709 --transfer bt709 --fullrange --d3d11 --sao none --ctu 64 --no-timer-period-tuning --vbr 5500
--codec hevc --quality best --profile main --trellis off --b-pyramid --colormatrix bt709 --colorprim bt709 --transfer bt709 --fullrange --d3d11 --sao none --ctu 64 --no-timer-period-tuning --fixed-func --vbr 5500
--codec hevc --quality best --profile main --trellis off --b-pyramid --colormatrix bt709 --colorprim bt709 --transfer bt709 --fullrange --d3d11 --sao none --ctu 64 --no-timer-period-tuning --vbr 5500
I also went to Xiph Derf and downloaded the 2160p50 y4m files: crowd run, ducks take off, in to tree, old town cross, and park joy; I combined them in Shotcut and exported them as a 24.8 Gb HuffyUV file.
I encoded this file using Staxrip first with x264+slow+tune film and x265+fast+tune grain, both of theese 2 encodes used CRF30, the x264 file was 20.6 Mbs and the x265 was 19.8 Mbs.
For the qsv encodes I set the bit rate of qsv h264 to match that used by x264 and I set the bi rate of qsv hevc to use the bit rate used by x265. There are 2 versions of each qsv encode, one with ff in the name indicating that "fixed function" or "low power" mode was used.
The test system used is a HP 17-by3065st 17.3" with a 17.3 inch screen, 5-1035G1 4C/8T Ice Lake (these have AVX-512!), 8Gb ram, 128Gb SSD + 1Tb 5400rpm spinning rust, Win10 Home.
Bottom line, stop encoding H264 and H265 using any software based encoder, switch to Ice Lake QSV, or even better, Tiger Lak QSV and never look back.
+ Reply to Thread
Results 1 to 20 of 20
Last edited by sophisticles; 13th Sep 2020 at 19:12.
Here's the files referenced above.
One note to anyone that will say that I used "too much" bit rate, I let x264 and x265 use whatever bit rate their algorithms determined was needed to provide CRF30 level quality. In all honesty, I don't think anyone would use CRF30 for any content they planned on keeping. this test file apparently is very hard to encode because both x264 and x265 wanted to use more than 140Mbs when I used CRF23.
Last edited by sophisticles; 13th Sep 2020 at 19:48.
did you test time with h264 qsv ice lake with older lake.
there is new intel gen yet to come tiger lake, it has massive improvement if you or anyone gets hand on please share here.
I find hardware-accelerated H265 encoding to be very fast and very useful if you just want to make a quick encode for your phone or something. I still think x264 does a better job at retaining fine detail like film grain.
I never buy laptops with the latest gen cpu until they are out at least a year, to make sure there are no bugs in the new cpu's and because it takes about a year for the prices to come down to what I consider reasonable.
For me, encoding/editing video on a laptop hooked up to my 50 inch TV has changed the way I do computing. With software based encoding, you're running your cpu at full blast for extended periods of time, generating heat and wasting a bunch of electricity and for what? A mistaken belief that it is somehow of higher quality at some low bit rate that no one in their right mind would use anyway?
The Blu Ray spec allows for up to 54 Mbps for audio and video combined (for 1080p), 40 Mbps for video only and UHD BD spec allows for up to 100 Mbps video for 3840x2160p, Netflix I think uses 16 Mbps for their 4k streams, so why would anyone bit rate starve their encodes?
I tested this Ice Lake laptop extensively, you can't touch it with a software based encoding solution. I had thought about buying an off lease HP dual socket server, you can get a used dual Xeon system, in good shape, for $500-$600, but after losing power half way through a long 9 hour encode, either because a storm hit over night that killed power, or because the power supply glitches and the system reboots or because I accidently unplugged the computer trying to unplug the vacuum cleaner or having to hear the cpu fan on my Ryzen 5 1600 spinning at max level as it tries to cool the cpu, I decided to never encode with software again.
With this laptop, encoding in fixed function mode, it's whisper quite, cool, fast, and the best part since it has a built in battery it acts like an ups, meaning if any of the above happens, like losing power or I accidently unplug it (which I have done), I don't lose any work, they system just switches over to battery automatically.
The only thing that's going to replace this laptop as my go to encoding solution will be a newer laptop in a couple of years.
For derf tests, QSV hevc has significant problems with crowd run, park joy, ducks take off. Significant detail loss, blurring and macroblocks. There shouldn't be any macroblocks with HEVC. It looks like MPEG2. What settings did you use ? In the other set you were using things like --vpp-detail-enhance, disabling SAO - maybe you used "not ideal" settings? It shouldn't look that bad.
eg. attached are some same frame type comparisons (B vs. B etc...)
x265 is a bit noisy around edges like cars for old town cross. For lower bitrate ranges, like CRF 30, most people would leave SAO enabled. You might consider using 10bit encoding for HEVC - since it's natively supported by HEVC decoder hardware and standard.
The bit rate used in these tests is way lower than anything I would use for normal encodes. Both x264 and x265 wanted to use 140+ Mbps for CRF 23 the Derf sources, which is understandable considering they are 50fps sources and have a lot of motion vectors, well some of them do.
Be that as it may, under normal playback, on my 50 inch 1080p60 TV, sitting about 10 feet right in front of the set, playing back the encodes using smplayer on Win 10, I was hard pressed to tell the difference between the encodes and at the more "normal" 25 Mbps that I would normally use for 2160p content there is no difference between the encodes that I can find.
I'm guessing you pixel peeped to get those screenshots, something most people don't do, they just enjoy the movie.
I wanted to do a lot more test encodes, but I am taking 2 Chem and 1 Bio class this semester and between them and working 10 hours a day, 6 days a week, I am fried.
I have run into a weird bug with Handbrake and Vidcoder + Ice Lake QSV, namely that both apps crash as soon as I try encoding QSV with them, ffmpeg from the command line works fine, as does QSVEnc via Staxrip; ironically enough Hybrid also crashed a number of times.
My guess is that the graphics drivers that came with this laptop are flaky, I would rip them out and install official Intel drivers, but I just bought this thing for school so I could do chemical analysis work and I don't want to f*ck it up in the middle of my semester and have to spend hours getting everything running again.
Maybe after this semester is finished I will upgrade it like I want to and set it up the proper way.
Personally though, I am happy with the quality of Ice Lake's QSV.
Yes, that is a low bitrate / high crf range for typical usage for most users... You can repeat some tests at 30, 50, 70 whatever bitrates or lower crf values.
The differences are pretty large on some sections
If x265 needed 140Mbps (or whatever bitrate) to achieve a certain level of "quality" using "fast", what does QSV need 180Mbps? 200Mbps? to achieve similar quality? ie. How much worse is it ? What about x265 "slow" ? That's the current quality setting most people use (it was rebalanced a while back from "slower") .
Or, at this ~20Mb/s bitrate range , what bitrate range does QSV hevc need before the macroblock and blurring issues improve ? 25Mb/s ? 30Mb/s ? The x265 encode has some other issues too, but those are relatively minor compared to QSV hevc at that bitrate
HEVC shouldn't fall apart like that with severe macroblocking , QSV or not. You expect QSV to be worse, softer with less detail - but it shouldn't look *that* bad on some of those sections. Maybe there were some other issues with the settings or drivers.
I base it on my own encodes I have done. I do not have an Intel CPU. I have an MSI GTX1070 GPU so possibly QSV is superior to NVENC. But in my own tests encoding some uncompressed 1080p material through NVENC H265 10-bit, I am seeing very good compression, very fast encoding speed and it actually looks very good for as small as the file is. But I can see where it is at times falling short compared with x264.
Last edited by stonesfan187; 23rd Sep 2020 at 10:41.
To be fair, the NVENC H265 10-bit encodes I have done through Staxrip are not really significantly larger than my x264 encodes (I'm often noticing some content compresses much better with H265) and just for a streaming library or doing a fast encode to watch on a mobile device, the NVENC H265 10-bit encodes look plenty fine, it doesn't have to be a work of art. I do agree that the time and resource savings can make it worthwhile over an x264 or x265-based encode.
Last edited by stonesfan187; 23rd Sep 2020 at 10:55.
As for claiming that you have zero effect on resources used. You live in a world of supply and demand, and you purchasing a computer caused there to be less supply. The computer company you bought from will probably built a new computer to replace the one you took. When your manufacturing line and logistics are in place to build a certain computer, especially a fancy new machine, there is less resistance to building a new machine to meet demand.
If no one bought it, they would quickly stop making it as they are losing money.
What kind of encode times are you getting with these parameters? What sort of output quality do you get when you lower the bitrate to a more reasonable level like 4-5Mbps with each? I did a few test encodes with NVENC H265 10-bit and they looked great imo. I was really amazed how low I could take the bitrate without major hits in quality.
Last edited by stonesfan187; 23rd Sep 2020 at 15:42.
The proper comparison is if you start with no system at all, buy a laptop like I did, in all fairness it needs upgrading with faster read and wrote hard drivers and more ram, to take it to where I want it will cost me another $300 or so, for a fast 1tb SSD for the OS and a fast 1tb SSD for writing plus another 8gb ram.
With that, I would be able to easily encode 5 4k videos simultaneously via QSV, to build a software based system from scratch, that can do that, will cost way more than $850, when you consider the cpu, motherboard, power supply, cooling, drives, OS, ram and an uninterrupted power supply.
Such a monstrosity also uses a lot of electricity.
The laptop in comparison is thin, portable, quite, sips electricity and doesn't require any exotic cooling.
As for the rest, there are 7 billion people on the face of this planet, with the demand for faster and faster computing increasing every year, in fact the 3 fields that the department of labor predicts will continue increasing over the next decade is IT, Healthcare and Business Analytics / Big Data, all these things require faster and faster computers, meaning the demand for faster hardware is only going to increase, so we may as well embrace more efficient designs.
Intel recommends look ahead, but near as i can tell qsv hevc doesn't support it and it appears to be incompatible with extbrc.
I have a ton of work to do by Sunday and a big Chem test next Tuesday, but after that I will have a day or two to breathe and relax and I will run some more tests with the Netflix samples from Derf, so check back next week for a bunch of test encodes.
I did some more testing with NVENC H265 10-bit through Staxrip and DVDFab. The quality is okay for just a quick encode that I might stream to my phone or laptop. It doesn't beat encoding the same source through x264 Medium at CRF20. I think I'm just gonna go with NVENC H265 10-bit through DVDFab. The program just seems easier to use and the encodes look fine if I use CRF24 instead of the default 26 in DVDFab. It doesn't have to be a masterpiece. Yes it doesn't look as good as x264 Medium, but for the time saved, I can live with the slightly lower quality.
Last edited by stonesfan187; 8th Oct 2020 at 13:01.