A question on latest Intel Media SDK version 20.5.1 about qsvenc HOT 14 CLOSED

This is for Linux right? On Windows and Tigerlake, current fixed function HEVC encode can make use of bframes+bpyramid with target usage quality and balanced. The speed preset does not support bframes currently, in future drivers it might be supported.

from qsvenc.

I'm on Windows 10 using Ice Lake (i7-1065g7). I cannot use bframes and bpyramid with fixed function. B frames are set to none by the encoder, even if I set it in the GUI (using either balanced (4) or quality (1)). Maybe, I'm not setting mine up correctly. Which encoding method are you using for HEVC 10bit and what custom settings do you make? Thanks

from qsvenc.

This is interesting. It definitely woks on Tigerlake with quality (TU1) and balanced (TU4). Speed preset doesn't use it and therefore the quality is much worse. It works on all modes and both 8 or 10 bit, ICQ quality factor isn't fully supported with FF but this is another problem. CQP with 16 bframes works really good together with 2_6_8 offset.

from qsvenc.

I guess it must be an enhancement in Tiger Lake. I use CQP HEVC 10-bit encoding with 16 bframes (not fixed-function) and it does a great job and I do still get around 200-250fps and very low cpu usage (less than 20%) with balanced and less than 10% with best (I accidentally found setting async depth to 4 on my laptop, causes the CPU usage to drop dramatically without losing encoding speed). It would be great to have bframes and bpyramid with fixed function - I assume the file sizes come down quite a lot with bframes and bpyramid.

from qsvenc.

Not sure if it's driver oder hardware related, maybe they didn't enable it on Icelake yet. I'm using async depth 5, it's slightly faster than 4 on my device. Yes CQP works really good with 16 bframes and bypyramid, you also should try offset 2_6_8. You can use lower CQP I/P/B with this.

from qsvenc.

Thanks for the tip. Do you mean that you set CQP I frames to say 32, P frames to 36 and B frames to 38 or 30, 34, 36 etc for 10bit?

from qsvenc.

I think you are referring to QP Offsets I,P and B under the "rate control". I always had them at 0, so you mean QP Offset I to 2, QP Offset P to 6 and QP Offset B to 8?

from qsvenc.

Yes CQP Offset: --qp-offset 2:6:8

Your bitrate should go down a bit, means you can go down with your CQP bitrate values.

from qsvenc.

Thx - just tried it and I could use lower IPB values, achieved a lower bit rate also. Really appreciate the tip. BTW I use staxrip as GUI.
I initially had IPB as 34,36,36 (10bit HEVC) and the movie I used gave bitrate of around 1370k for 720p - very good quality. I tried with the offsets you mentioned and set IPB as 32,33,35 and that gave a bitrate of 1240k! (about 10% less with lower IPBs). I've yet to look at the video but signs are that it should look at least as good as my original.
One more thing, I found that setting GOP length makes a big difference - currently for CQP mine is set to 32 frames. If I set it to 0 (default in staxrip), QSVEnc sets it to usually 240 frames. This usually lowers bitrate even more but can degrade pq. I'll try the new settings with a default GOP also.

from qsvenc.

CQP with this offset is the best quality bitrate mode, on Tigerlake.

QSVEnc is using FPS x 10 for the gop lenght, so it depends on the input fps from your movie and yes it makes a big difference. I usually do use fps x 10 but sometimes I want a 5 seconds seeking and then I use fps x 5.

from qsvenc.

Just to finish off, I encoded my blu ray of Avatar Extended Collectors Edition. A few days ago, I had encoded it using x265 10bit CRF24 using the medium preset. The only change was that I used aq-mode 3 (instead of default aq-mode 2). This gave a 720p file with video bitrate of 2326k. Avatar is a great movie to test with - full of action etc. For my purposes, CRF24 x265 10bit provides excellent quality. I then used the new CQP settings of I/P/B = 32/33/35, the qp-offset of 2:6:8, 16 bframes, bpyramid on and the gop length of 32. This provided a 720p file with video bitrate of 2176k! I would have expected about 20% higher bitrate for similar quality to x265, so to get similar bitrate is a real bonus (gotta love bframes and bpyramid).

I then used StaxRip's excellent video comparison tool and I really could not see any difference in 99% of the frames I checked. I must have checked about 200 frames from different parts of the movie. The only (EXTREMELY slight) differences I found were in people's facial detail - I can't believe anybody could tell which movie was cqp or x265 playing them side by side. However, I must stress that the differences were really difficult to notice. Frankly I was blown away by the quality of the hardware encode vs software encode. I've attached some examples below of cqp and x265 snapshots from StaxRip's video comparison tool. The first image in the pair is the cqp version and then the x265 version:-

from qsvenc.

Yes I know from Tigerlake that CQP with this settings can be compared to x265 medium-slow. Icelake non-FF Hybrid HEVC encode could be similar or possibly the same as Tigerlake. CBR/VBR is much worse than x265 though, for example Intel doesn't support lookahead HEVC. ICQ is quite good as well on Intel, the problem is that it does not scale beyond 5-6 bframes unlike CQP. In fact 16 bframes on ICQ could be worse than 5 bframes.

from qsvenc.

ICQ was my preferred choice. I used it on a lot of movies with 16 b-frames and b-pyramid on and it did a great job. However, I found that when it came to movies with a lot of fast motion, the b-frames caused a lot of blocky artifacts during those scenes. The movies it worked well on were of the slow moving drama type etc. Now, with your tip added, I think CQP will be my go to. I compared TU1 to TU4 and just could not see any difference - the only thing was that files were marginally smaller with TU1, but not by much and the speed is about 2-3x faster with TU4.

I like the principle of ICQ and the FF on IceLake with ICQ does a great job, but you can't use b-frames etc. Also, I find that the FF ICQ file sizes are not much bigger than x265 equivalents in most cases. As there are no b-frames, the quality is great.

I noticed that when trying HandBrake default settings with ICQ, it automatically sets gop length to 24, (it sets it to 32 for CQP) and sets b-frames to 2, ref-frames to 2 and b-pyramid off. Like you noted, more than a few b-frames with ICQ can look really bad. The exception (in my case) is that you can use ICQ and 16 b-frames with b-pyramid for "non-action" type movies.

I could never get VBR to work as the bitrate range is far too small - it could not cope with cases where you had static scenes that were quickly followed by high motion scenes and vice versa. ICQ is perfect for that but it can't currently handle a lot of b-frames in fast motion scenes (much too blocky).

from qsvenc.

On Tigerlake ICQ with bframes 16 is worse than bframes 5, it doesn't improve the bitrate efficiency. If it's the same on Icelake you should try bframes 5. But nevertheless, CQP with the settings above is the best quality bitrate mode. The difference between TU1 and TU4 is indeed small, it's not worth the speed decrease in my opinion. It's a bit different for FF encode on Tigerlake because even TU1 is very fast. TU1 FF is slightly faster than TU7 Hybrid on my Tigerlake device with the exact same settings. ICQ has the advantage of having just 1 global bitrate setting while for CQP there are 6 settings which directly affects the bitrate. So it's more for experts. Even Intel says this.

_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.

Also without question: making this work well cannot be done without extra development. Simply setting one global QP for all frames without content analysis/dynamic adjustments is quite likely to have worse bitrate vs quality than other BRC alternatives.

As CQP is best left to expert users, the remainder of this article will focus on “automated” BRC algorithms._
https://software.intel.com/content/www/us/en/develop/articles/common-bitrate-control-methods-in-intel-media-sdk.html

from qsvenc.