What is current status for hardware H.265 encoding.

[Yups]

Blender Open Movie from here: https://forum.doom9.org/showpost.php?p=1938861&postcount=423


HERO - Blender Open Movie VMAF speed bitrate

Quicksync H265 (27.20.100.9316)
Iris Xe CQP FF best 86.56 550 fps 199 kbit
Iris Xe CQP FF balanced 85.66 850 fps 201 Kbit
Iris Xe CQP FF speed 76.25 1550 fps 200 Kbit

Iris Xe CQP best 88.59 167 fps 200 kbit
Iris Xe CQP balanced 87.18 280 fps 201 Kbit
Iris Xe CQP speed 86.22 520 fps 200 Kbit


NVENC H265 (470.14)
GTX 1660S CQP best 84.52 430 fps 200 Kbit
GTX 1660S CQP default 83.55 990 fps 201 Kbit
GTX 1660S CQP performance 79.22 1130 fps 200 Kbit


x265 (Staxrip 2.1.9.0)
i7-1165G7 CRF slower 90.25 8 fps 200 Kbit
i7-1165G7 CRF slow 88.18 34 fps 200 kbit
i7-1165G7 CRF medium 85.72 56 fps 200 Kbit
i7-1165G7 CRF very fast 83.36 73 fps 200 Kbit


x264 (Staxrip 2.1.9.0)
i7-1165G7 CRF slower 75.37 81 fps 200 Kbit



Disabled b-adapt is better for this video. Turing CQP cannot reach Iris Xe CQP quality, subjective and objective the difference is large.

Turing has two downsides, only 5 bframes versus 16 bframes on Iris Xe and there is no GPU equivalent mode which is more flexible than a fully fixed function solution, however even the FF mode from Iris Xe looks better. It might look different with CBR vs CBR which I haven't tried. That said, the H265 CQP results from Turing are really good for a hardware encoder, something like x265 fast-faster with extremely fast encoding times, the CQP quality from Iris Xe is just insane.

[Tenkei]

Is there any reason to use CQP instead of ICQ with QuickSync. Never used it but it seems that ICQ is CRF equivalent. Did you try --ctu 64 and --ref X?

[Yups]

CQP with custom offset offers higher quality than ICQ, this old Quicksync bitrate method overview is still valid:

Constant QP (CQP) provides the most control and best performance. Without question, the best coding efficiency with Intel codecs can be obtained via CQP plus custom content analysis. CQP often has significant performance advantages as well. CQP operates most closely to reference implementations. It is the most direct way to access codec capabilities and measure the effects of encoder parameter/algorithm trade-offs and also is the clearest way to evaluate against other codec algorithm implementations.
https://software.intel.com/content/www/us/en/develop/articles/common-bitrate-control-methods-in-intel-media-sdk.html


For a basic user ICQ is easier to handle, there is just one global setting and that's it. Furthermore ICQ does not really scale over 5 bframes (16 bframes can be worse than 5 at low bitrate) whereas CQP scales really good beyond 5 bframes even at low bitrate. Here I did include both ICQ and CQP: https://forum.doom9.org/showpost.php?p=1930663&postcount=369

On Iris Xe it automatically uses ctu 64 (Gen 9 ctu 32), this can't be changed at the moment. Tskip and SAO are also enabled on Tigerlake which I can't disable. Reference frames best leave it auto, with 16 bframes+bpyramid Intel sets it to 6 reference frames, I've tried 8 reference frames but there is no improvement.

[Yups]

CQP best runs ~5% faster with Intels new driver build 9466 (https://downloadcenter.intel.com/download/30381/Intel-Graphics-Windows-10-DCH-Drivers) on Iris Xe.

I was searching for CQP improvements and noticed that 14 and 15 bframes offers slightly better scores at a slightly lower bitrate on Iris Xe over 16 bframes which I was using. This is tested on Intel Demo Clip and Blender Open Movie low bitrate.

13 bframes and lower gradually decreases bitrate efficiency, it's a big degradation from 14 to 13 bframes. 14 bframes is a tiny bit better than 15. For better context:




Intel Demo Clip 1080p VMAF PSNR SSIM VQM speed bitrate

Quicksync H265 27.20.100.9466
Iris Xe CQP best 16 bframes 91.76 41.85 0.9748 0.790 73 fps 2438 kbit

Iris Xe CQP best 14 bframes 91.98 41.96 0.9754 0.780 74 fps 2426 Kbit

NVENC H265
GTX 1660S CQP best 90.62 41.28 0.9699 0.885 150 fps 2439 Kbit

x265 (Staxrip 2.1.9.0)
i7-1165G7 CRF slow 93.20 41.90 0.9754 0.800 8 fps 2430 kbit
i7-1165G7 CRF medium 91.05 41.35 0.9744 0.861 19 fps 2440 Kbit
i7-1165G7 CRF very fast 89.99 40.97 0.9726 0.894 32 fps 2440 Kbit


x264 (Staxrip 2.1.9.0)
i7-1165G7 CRF slow 89.38 40.21 0.9693 0.974 30 fps 2425 Kbit


Bitrate goes down from 2438 to 2426 and scores go up, it's a clear win.

[MGarret]

CQP with custom offset offers higher quality than ICQ, this old Quicksync bitrate method overview is still valid:


https://software.intel.com/content/www/us/en/develop/articles/common-bitrate-control-methods-in-intel-media-sdk.html


For a basic user ICQ is easier to handle, there is just one global setting and that's it. Furthermore ICQ does not really scale over 5 bframes (16 bframes can be worse than 5 at low bitrate) whereas CQP scales really good beyond 5 bframes even at low bitrate. Here I did include both ICQ and CQP: https://forum.doom9.org/showpost.php?p=1930663&postcount=369

On Iris Xe it automatically uses ctu 64 (Gen 9 ctu 32), this can't be changed at the moment. Tskip and SAO are also enabled on Tigerlake which I can't disable. Reference frames best leave it auto, with 16 bframes+bpyramid Intel sets it to 6 reference frames, I've tried 8 reference frames but there is no improvement.

What a load of misleading information in that Intel article. CQP is not even a "proper" rate control. Of course it operates closely to reference implementations because, guess what: reference software don't even have real rate control algorithms. So, yeah, CQP with some custom software that analyzes characteristics and complexity of every scene is what huge content providers like Netflix and others use and play around to squeeze more optimized encodes to save bandwidth. I see it as an entire pipeline where several tools are used and not just one rate control algorithm. When this kind of algorithm is implemented inside the encoder, then it won't be called CQP but something else.

[Yups]

Who cares? The point is CQP offers higher quality than ICQ, the Intel article is correct on this.

[MGarret]

The point is you obviously don't have any proof for your claim. I just pointed out what I think about some dubious claims from that article.

If you believe that just using fixed qp's is going to create efficient encoding in terms of file size/picture quality... well, I'm not going to persuade you otherwise. We all have our specific needs in regards to using encoders. Keep believing in your vmaf/psnr/ssim numbers.

[Yups]

The point is you obviously don't have any proof for your claim. I just pointed out what I think about some dubious claims from that article.

What claim? The claim that ICQ is worse than CQP on Iris Xe? Dude if ICQ would offer better results over CQP I wouldn't use CQP. It would be insane if ICQ would offer even better results over CQP. The claim that CQP offers best coding efficiency on Intel isn't dubious, dubious are your postings.



If you believe that just using fixed qp's is going to create efficient encoding in terms of file size/picture quality... well, I'm not going to persuade you otherwise. We all have our specific needs in regards to using encoders. Keep believing in your vmaf/psnr/ssim numbers.


Nonsense. Subjective and objective CQP is clearly better than ICQ, I told this more than once and I have uploaded several samples. If you don't agree prove it!

If you don't believe in vmaf/psnr/ssim numbers download the sample or ask for the upload if I didn't upload any wanted sample, I'm always checking for subjective quality my results. I don't force you to believe any numbers.

Bframes scaling with CQP is way better than with ICQ or CBR/VBR on Iris Xe. CBR/VBR 7 bframes are best and on ICQ there is no real improvement over 5 bframes. With CQP it scales up to 14-16 bframes, this is one reason why ICQ can't reach CQP. This is something you can't know because you are obviously clueless.

About fixed CQP, I mean depending on the bitrate/quality target different quantization parameter are required, this is no different to any other constant rate factor. I don't understand your problem to be honest, I mean it's super easy on Intel (easier than on Nvidia).

[MGarret]

What claim? The claim that ICQ is worse than CQP on Iris Xe? Dude if ICQ would offer better results over CQP I wouldn't use CQP. It would be insane if ICQ would offer even better results over CQP. The claim that CQP offers best coding efficiency on Intel isn't dubious, dubious are your postings.





Nonsense. Subjective and objective CQP is clearly better than ICQ, I told this more than once and I have uploaded several samples. If you don't agree prove it!

If you don't believe in vmaf/psnr/ssim numbers download the sample or ask for the upload if I didn't upload any wanted sample, I'm always checking for subjective quality my results. I don't force you to believe any numbers.

Bframes scaling with CQP is way better than with ICQ or CBR/VBR on Iris Xe. CBR/VBR 7 bframes are best and on ICQ there is no real improvement over 5 bframes. With CQP it scales up to 14-16 bframes, this is one reason why ICQ can't reach CQP. This is something you can't know because you are obviously clueless.

About fixed CQP, I mean depending on the bitrate/quality target different quantization parameter are required, this is no different to any other constant rate factor. I don't understand your problem to be honest, I mean it's super easy on Intel (easier than on Nvidia).

Hey chum, did I struck the nerve somehow?

Here, read about about etiquette on this forum.
4) Be nice to each other and respect the moderator. Profanity and insults will not be tolerated.

I just stated my opinion and you found yourself offended because I somehow negated your findings? Are you that sensitive? I don't even know about your samples because this thread is couple of years long and I read it occasionally. I still stand by common knowledge that CQP is inefficient and "dumb" type of rate control. I don't know what Intel is doing differently and I don't care. Enjoy your Iris XE or whatever.

[Tenkei]

Both of you can be correct. Usually RCF mode means better quality for the same bitrate, but if Intel's ICQ is broken it might reduce too much, like hevc-aq does in x265. Can't really conclude anything, without comparing clips of several scenes, one scene is not enough. Hand-picker quantitizer might be better for one scene, but it won't be an efficient way to encode hour long video.

Also, one frame might look better on CQ and other would be better on ICQ, so it depends on what are we comparing. Do you see quality difference in running clip or just a single random frame you chose.

[ReinerSchweinlin]

Blender Open Movie from here: https://forum.doom9.org/showpost.php?p=1938861&postcount=423

.
.
.
.

Disabled b-adapt is better for this video. Turing CQP cannot reach Iris Xe CQP quality, subjective and objective the difference is large.

Thanx for investigating this :) I am just waiting for the i5 NUCs to be available :)

[Yups]

Both of you can be correct. Usually RCF mode means better quality for the same bitrate, but if Intel's ICQ is broken it might reduce too much, like hevc-aq does in x265. Can't really conclude anything, without comparing clips of several scenes, one scene is not enough. Hand-picker quantitizer might be better for one scene, but it won't be an efficient way to encode hour long video.


ICQ isn't broken, it's how it is. That being said, H265 ICQ isn't even fully supported in fixed function mode from the hardware (rate factor can't be changed). In the end you can use whatever you want, personally I won't bother too much with ICQ because CQP offers me a better quality and slightly higher performance.



HERO - Blender Open Movie VMAF PSNR SSIM VQM speed bitrate

Quicksync H265 27.20.100.9466
Iris Xe CQP best 14 bframes 88.94 41.13 0.9864 0.544 191 fps 198 kbit

Iris Xe ICQ best 14 bframes 86.72 40.02 0.9841 0.609 174 fps 198 Kbit



@ReinerSchweinlin, hopefully we can get DG2 this year. They could aim for something higher in GPU hybrid mode, I mean this GPU comes with much more EUs and higher GPU clock speeds. If not it should run a lot faster in hybrid mode than Iris Xe iGPU.

[ukmark]

Does the Intel graphics driver version have any effect on the quality/speed of QuickSync fixed function (HEVC) encoding?

I know that the API version is linked to the graphics driver and affects quality/speed of non-FF encoding, but I am guessing that fixed function encoding can only be improved by upgrading the GPU?? (i.e. upgrade your laptop etc).

The reason I ask is that I'm on the latest driver as of 9/5/2021 (27.20.100.9466) and I did a quick test using FF encoding and it appeared to me that the quality (in terms of facial detail retention) has improved from a couple of months ago. Not a scientific test, but just wondering if anyone knew of a link between graphics driver version and FF encoding quality (if any).

TIA

[Yups]

I don't know about FF mode (haven't checked), on CQP Hybrid with Tigerlake there is a difference between some of the drivers. 9466 runs ~5% faster which I have mentioned in #454 and 30.0.100.9563 (inside preview driver) adds another 5% speedup on top of this. My VMAF scores did improve slightly over time when I compare it with a 6 months old driver, but these changes are not regularly from what I have seen. On my old Gen9 I have't seen differences for a long time, because this GPU architecture is very old.

[ReinerSchweinlin]

@ReinerSchweinlin, hopefully we can get DG2 this year. They could aim for something higher in GPU hybrid mode, I mean this GPU comes with much more EUs and higher GPU clock speeds. If not it should run a lot faster in hybrid mode than Iris Xe iGPU.
just checked techpowerup release info page, no updates so far. Let´s hope for the best :)

[ukmark]

and 30.0.100.9563 (inside preview driver) adds another 5% speedup on top of this.

How do you get your hands on the preview drivers? Thx

EDIT: NVM I managed to get it from "station-drivers" (https://www.station-drivers.com/index.php?option=com_kunena&view=topic&defaultmenu=860&Itemid=858&catid=17&id=468&lang=en&limitstart=12#5005)

[benwaggoner]

I'm finally getting my RTX a6000 tomorrow, if there are any tests to run on that. I generally expect HW encoding quality to be identical to other RTX 3000 series GPUs.

[StormMeows]

Deleted

[benwaggoner]

I've been wondering how many 8-bit only HEVC decoders are out in the wild still. In the living room, there were a few early SDR UHD Smart TVs that possibly had only 8-bit decoders. There were some phone SoCs that were 8-bit HEVC only around five years ago.

Anyone have a guess as to when and what the last devices to ship with Main but not Main10 HEVC decode were? Are there any significant clusters of devices still in use with those limitations?

[Blue_MiSfit]

Android phones in the 5-7 year age range are probably the biggest cohort I can think of. The software fallback decoder in Android is very limited as well ;)

[benwaggoner]

Android phones in the 5-7 year age range are probably the biggest cohort I can think of. The software fallback decoder in Android is very limited as well ;)
Right, that was the biggest group of 8-bit only decoders I knew of. Of course with mobile replacement rates being what they are, most of those devices are already out of use and the remaining number is presumably shrinking rapidly.

Living room devices, PCs, and tablets get replaced more slowly, so 8-bit only devices (if any) in those categories may be the more enduring issue. I can't think of any living-room devices that were 8-bit only, but I'm sure some tablets were based on the same 8-bit SoCs used in some phones.

[pandy]

I've been wondering how many 8-bit only HEVC decoders are out in the wild still. In the living room, there were a few early SDR UHD Smart TVs that possibly had only 8-bit decoders. There were some phone SoCs that were 8-bit HEVC only around five years ago.

Anyone have a guess as to when and what the last devices to ship with Main but not Main10 HEVC decode were? Are there any significant clusters of devices still in use with those limitations?

Not direct answer but terrestrial TV in Germany use H.265 1080p50 at 8 bit not 10 bit - weird but this absolute minimum for receivers in DE so it may be situation where at least some SoC's will not support 10 bit. Unclear to me why Germany stuck with 8 bit.

[benwaggoner]

Not direct answer but terrestrial TV in Germany use H.265 1080p50 at 8 bit not 10 bit - weird but this absolute minimum for receivers in DE so it may be situation where at least some SoC's will not support 10 bit. Unclear to me why Germany stuck with 8 bit.
Any idea what SoC is used in those?

[pandy]

Any idea what SoC is used in those?

Nope - there is quite actual list of accepted devices (but there is everything, even antennas there) - https://tv-plattform.de/en/themen/dvb-t2-hd/geraeteliste/ .

SoC's itself may be even 10 bit compliant but firmware specifically targeting German requirements may support only 8 bit...

[RedDwarf1]

Hi everyone,
I asked a question in the Hybrid encoder thread but so far no one has answered my question(s). This thread might also fit my question because it is nVidia hardware GPU (GTX1660 NOT Super) encoding related.

With regard to HEVC/H.265:

Hybrid keeps outputting CAVLC and not CABAC entropy encoding video. I would much prefer CABAC. The question I have is: is this because nVidia GPU's can only encode with CAVLC? Has anyone managed to encode HEVC/H.265 to CABAC using a nVidia GPU? My GPU is fairly recent and there has only been one update to the NVENC encoder since then to my knowledge.

Has anyone tested nVidia HEVC encoding on Turing GPU's or even noticed it since MediaInfo and similar programs do not seem to show the entropy encoding of HEVC video. I use H264/H265 BS Analyser v3.0 which does the very basics but is a bit limited especially with large files.

https://github.com/latelee/H264BSAnalyzer/releases

Can anyone shed any light on this?

[benwaggoner]

Hi everyone,
I asked a question in the Hybrid encoder thread but so far no one has answered my question(s). This thread might also fit my question because it is nVidia hardware GPU (GTX1660 NOT Super) encoding related.

With regard to HEVC/H.265:

Hybrid keeps outputting CAVLC and not CABAC entropy encoding video. I would much prefer CABAC. The question I have is: is this because nVidia GPU's can only encode with CAVLC? Has anyone managed to encode HEVC/H.265 to CABAC using a nVidia GPU? My GPU is fairly recent and there has only been one update to the NVENC encoder since then to my knowledge.
I don't believe HEVC and x265 even support CAVLC; it's just H.264. Are you sure you're testing with HEVC?

[RedDwarf1]

Yes it is HEVC. I have just software encoded using x265 and the video shows as having CABAC entropy encoding whereas the nVidia GPU encoding always shows as CAVLC according to H264/H265 BSAnalyser.

It might be worth you testing for yourself and checking with the stream analyser. MediaInfo etc does not show this information for HEVC

Here is the info copied from the analyser>
H.265/HEVC File Information

Picture Size : 640x480
- Cropping Left : 0
- Cropping Right : 0
- Cropping Top : 0
- Cropping Bottom : 0
Video Format : YUV420 Luma bit: 8 Chroma bit: 8
Stream Type : Main Profile @ Level 3(90) Tier Main
Encoding Type : CABAC
Max fps : 30.000
Frame Count : 4936

It does seem to be getting the number of frames incorrect because there should be 5001.

[benwaggoner]

Yes it is HEVC. I have just software encoded using x265 and the video shows as having CABAC entropy encoding whereas the nVidia GPU encoding always shows as CAVLC according to H264/H265 BSAnalyser.

It might be worth you testing for yourself and checking with the stream analyser. MediaInfo etc does not show this information for HEVC

Here is the info copied from the analyser>
H.265/HEVC File Information

Picture Size : 640x480
- Cropping Left : 0
- Cropping Right : 0
- Cropping Top : 0
- Cropping Bottom : 0
Video Format : YUV420 Luma bit: 8 Chroma bit: 8
Stream Type : Main Profile @ Level 3(90) Tier Main
Encoding Type : CABAC
Max fps : 30.000
Frame Count : 4936

It does seem to be getting the number of frames incorrect because there should be 5001.
Can you give an example of the nvenc output with CAVLC?

[RedDwarf1]

Can you give an example of the nvenc output with CAVLC?

Thanks for your contribution.

I ran into some problems which has prevented me from adding to this thread. Firstly Hybrid encoder would not run. It crashed on startup. An install with the latest version which I had not got around to install before then fix that, at least it now runs & starts up.

Next I ran into a problem encoding the small video that I used with the x265 encoder with MeGUI. I used the same avisynth script which worked fine with MeGUI but Hybrid kept failing to encoder it and I have not yet managed to sort that out.

----------------------

I have managed to get it encoded, I do not know why it was not working when I tried previously because I did not alter anything when I re-tried and it did successfully encode the video.

H.265/HEVC File Information

Picture Size : 640x480
- Cropping Left : 0
- Cropping Right : 0
- Cropping Top : 0
- Cropping Bottom : 0
Video Format : YUV420 Luma bit: 8 Chroma bit: 8
Stream Type : Main Profile @ Level 5.2(156) Tier High
Encoding Type : CAVLC
Max fps : 30.000
Frame Count : 5001

So you can see it is saying this video encoded with the nVidia NVEnc is CAVLC whereas the same video encoded with x265 comes out with CABAC.

[tonemapped]

Thanks for your contribution.

I ran into some problems which has prevented me from adding to this thread. Firstly Hybrid encoder would not run. It crashed on startup. An install with the latest version which I had not got around to install before then fix that, at least it now runs & starts up.

Next I ran into a problem encoding the small video that I used with the x265 encoder with MeGUI. I used the same avisynth script which worked fine with MeGUI but Hybrid kept failing to encoder it and I have not yet managed to sort that out.

----------------------

I have managed to get it encoded, I do not know why it was not working when I tried previously because I did not alter anything when I re-tried and it did successfully encode the video.

H.265/HEVC File Information

Picture Size : 640x480
- Cropping Left : 0
- Cropping Right : 0
- Cropping Top : 0
- Cropping Bottom : 0
Video Format : YUV420 Luma bit: 8 Chroma bit: 8
Stream Type : Main Profile @ Level 5.2(156) Tier High
Encoding Type : CAVLC
Max fps : 30.000
Frame Count : 5001

So you can see it is saying this video encoded with the nVidia NVEnc is CAVLC whereas the same video encoded with x265 comes out with CABAC.

Why L5.2?

[RedDwarf1]

Why L5.2?

I think that the encoder chose that because it was set to auto.

[benwaggoner]

I have managed to get it encoded, I do not know why it was not working when I tried previously because I did not alter anything when I re-tried and it did successfully encode the video.

H.265/HEVC File Information

Picture Size : 640x480
- Cropping Left : 0
- Cropping Right : 0
- Cropping Top : 0
- Cropping Bottom : 0
Video Format : YUV420 Luma bit: 8 Chroma bit: 8
Stream Type : Main Profile @ Level 5.2(156) Tier High
Encoding Type : CAVLC
Max fps : 30.000
Frame Count : 5001

So you can see it is saying this video encoded with the nVidia NVEnc is CAVLC whereas the same video encoded with x265 comes out with CABAC.
Color me baffled! I thought CAVLC straight-up wasn't available with HEVC.

I just did a test encode with Adobe Media Encoder in HW encoder mode, which also uses nvenc under the hood, and MediaInfo in "Details 5" tells me that it is CABAC:
Line 523: 00002D8 cabac_init_present_flag: Yes
Line 1158: 001AB78 cabac_init_present_flag: Yes
Line 3966: 00002D9 cabac_init_present_flag: Yes
Line 4601: 001AB7A cabac_init_present_flag: Yes
Without any reference to CAVLC at all.

What tool are you using to get your report data above? Can you double-check with MediaInfo set to Details 5?

[RedDwarf1]

Color me baffled! I thought CAVLC straight-up wasn't available with HEVC.

I just did a test encode with Adobe Media Encoder in HW encoder mode, which also uses nvenc under the hood, and MediaInfo in "Details 5" tells me that it is CABAC:
Line 523: 00002D8 cabac_init_present_flag: Yes
Line 1158: 001AB78 cabac_init_present_flag: Yes
Line 3966: 00002D9 cabac_init_present_flag: Yes
Line 4601: 001AB7A cabac_init_present_flag: Yes
Without any reference to CAVLC at all.

What tool are you using to get your report data above? Can you double-check with MediaInfo set to Details 5?

Ah that sounds promising but I cannot replicate it. I used the H264/H265 BSAnalyser which I linked to on the previous page. It is a free bitstream analyser

I have tried Details 5 and I get a totally blank page with any file I open be it x264 or x265/HEVC :( That is on the Debug menu isn't it? I have [View] set to Text view BTW. Changing the view to another and back to Text does seem to refresh it and display output. However after doing that it does not show the entropy encoding. I have copied all the long output and searched for CABAC & CAVLC without finding either.

For the above I did upgrade to the latest portable version. I have checked a few files with the same result. I do not have too many HEVC files having recently started using it.

I do not have that Adobe application, I will have to try Handbrake or see if I can find some other program which supports hardware encoding.

Handbrake shows CAVLC when the raw video is opened with H264/H265 BSAnalyser. I can only see one way around this ATM. Can you test your video with the following program to see what it shows? BTW It does not like large files so you might need to chop the file up with something. It requires raw video and will not open video in a container (Mp4/Mkv).

https://github.com/latelee/H264BSAnalyzer/releases

[benwaggoner]

I have tried Details 5 and I get a totally blank page with any file I open be it x264 or x265/HEVC :( That is on the Debug menu isn't it? I have [View] set to Text view BTW. Changing the view to another and back to Text does seem to refresh it and display output. However after doing that it does not show the entropy encoding. I have copied all the long output and searched for CABAC & CAVLC without finding either.
Yeah, you found a fun MediaInfo defect. You need to load the file after setting the correct settings. Here's the full process


Open MediaInfo
Set Debug > Details 5
Set View > Text
Drag your file into the MediaInfo window

[Mister XY]

Are there settings for qsvenc, which are similar to crf 20 and the preset medium?

[tonemapped]

Are there settings for qsvenc, which are similar to crf 20 and the preset medium?

Use ICQ and setting the quality to 17 gives results somewhat comparable to x265 at crf 20. If you have a noisy source, don't use QSV.

[Mister XY]

I have tested with icq 17 but i have also blur/artefact in dark moments. Here are my settings for staxrip.
--codec hevc --quality best --profile main10 --slices 1 --bframes 14 --ref 5 --b-pyramid --open-gop --weightb --weightp --aud --icq 18

[tonemapped]

I have tested with icq 17 but i have also blur/artefact in dark moments. Here are my settings for staxrip.

There are other settings in Staxrip you can change and I'll paste the options I use, but I don't have access to my system with QSV set up. You should increase the lookahead frames to the maximum (think it's either 30 or 50 - can't remember).

[Mister XY]

lookahead frames means LA ICQ or? That are for x264. I have not see this in hevc.

[Yups]

I have tested with icq 17 but i have also blur/artefact in dark moments. Here are my settings for staxrip.


What Intel GPU are you using? This makes a big difference. On Gen9 you cannot reach x265 medium quality. With ICQ there isn't much you can do to improve. CQP is higher quality but you have to use a custom offset, 2:4:8 or 2:5:8 works quite good.

[tonemapped]

What Intel GPU are you using? This makes a big difference. On Gen9 you cannot reach x265 medium quality. With ICQ there isn't much you can do to improve. CQP is higher quality but you have to use a custom offset, 2:4:8 or 2:5:8 works quite good.

I'm using Gen '9.5' (UHD 605) and it's possible to reach medium x265, but it requires more bitrate (to be expected).

[Mister XY]

I have a Intel Gen 11 with UHD 750

[tonemapped]

I have a Intel Gen 11 with UHD 750

Sorry for the delayed reply. I'm using my 15W HTPC (see signature) for Intel testing as I have the iGPU disabled in all other systems. Overall, I find QSV to offer better results for any grainy source, or even most sources if you're prepared for encodes to be slower.

Here's something to start you off in Staxrip 2.4.x (should apply to 2.6.x and beyond)

1. Select Intel - H265 from the menu
2. On the 'Basic' screen, select:
- mode: ICQ
- Preset: Best
- Profile: Main 10
- Level: Automatic
- Quality: 20 is a reasonable start. As with everything, it depends on the source.

Then make sure these options are enabled (you can use the search box at the bottom left of the screen): --codec hevc --quality best --profile main10 --trellis all --ctu 32 --la-quality slow --la-window-size 50 --bframes 8 --ref 4 --b-pyramid --b-adapt --i-adapt --open-gop --weightb --weightp --input-buf 16 --vpp-denoise 10 --vpp-detail-enhance 20 --sao none --fallback-rc --tskip --icq 22

That has produced perfectly reasonable results, although you will generally end up using more bitrate than x265. Some example comparisons (using older, less refined options) can be found in this thread (http://forum.doom9.net/showthread.php?t=183035).

Since you're not a purist - like me - otherwise you'd use software encoding, you can increase the perceived quality by using '--vpp-denoise 10 --vpp-detail-enhance 20' as noted above.

Again, this is just a starting point and you may find that some features are not support, but Staxrip lets the driver decide and it will automatically disabled unsupported features (unlikely given you have Gen 11).

I'd be very interested to see some screenshots of your results. Hope that's helped a bit.

[Yups]

I have a Intel Gen 11 with UHD 750


That's fine, it's Gen12/Xe based. On Xe many bframes is no benefit with ICQ, actually bframes 5 was the optimum with ICQ in my tests. This is the only real change you could try.

However for highest quality you have to switch to CQP.

- CQP bitrate mode
- preset best
- bframes 14-16 (bframes 14 is slighty better in my tests)
- open gop
- b-pyramid (automatically enabled anyway)
- no fixed function
- QP offset I/P/B 2:4:8 or 2:5:8 works good
- QP I -1/-2
- QP P xx (depends on your bitrate/compression needs)
- QP B: +1/+2


QP P heavily depends on resolution and your bitrate/size budget, something between 20-25 (8 bit) is a good try. QP I needs to be 1-2 lower than P and QP B 1-2 higher than P. This works quite good with the offset from above.

If you are using 10 bit you have to add +12 on the CP quantizer for roughly the same bitrate. For exampe 23_24_26 8 bit is (roughly) the equivalent of 35_36_38 10 bit.


@tonemapped, almost all of your settings are useless because they have no effect, you can't enable/disable tskip, weight, trellis (h264 only), ctu, b-adapt, la (no LA for h265!).

[Mister XY]

Thats are my settings now
--codec hevc --quality best --profile main10 --bframes 14 --open-gop --cqp 28:29:30 --qp-offset 2:5:8
Its look like better than icq.

[Mister XY]

Here is a screenshot with the macro blocks what i mean.
The block formation can be seen very clearly in dark areas.
Here are the settings.
--codec hevc --quality best --profile main10 --bframes 14 --open-gop --cqp 28:29:30 --qp-offset 2:4:8

[Yups]

We would need the original source or a small sample of this to check this out. The screenshot looks low quality to me but there is not much to say without a sample.

[Mister XY]

OK, here is a screenshot from the original source.

[Mister XY]

So, that are my settings for 4K and FHD encoding.
--codec hevc --quality best --profile main10 --bframes 14 --ref 6 --b-pyramid --open-gop --weightb --weightp --cqp 27:28:29 --qp-offset 2:4:8.
I have tested some 4k Movies and FHD Movies.
These settings are roughly the same size as with crf 20 slow.
In some movies, you see macroblocks.
If you concentrate closely, you will see macroblocks. This is noticeable from time to time, especially when there are many consistent colors.
But I also think that if SAO could be deactivated, the blocks would also disappear. Unfortunately, SAO is always on.
But for now I'm satisfied when you consider how fast I encode with the GPU instead of the CPU.

[Yups]

It's a very grainy original source and SAO might have an effect there. I don't know if some faster presets (including low power mode) automatically disable SAO, they are usually lower quality but in such specific case if some presets don't use SAO it might be worth a try. I wonder if it's a qsvenc issue or something else why we can't disable sao. According to qsvenc feature check it's not supported but the encoding log says SAO all.