What is current status for hardware H.265 encoding.

[Yups]

Originally Posted by ReinerSchweinlin

While looking at you encodes, I noticed something:

The hardware-encoders all were able to detect the end-credits as simple paning from bottom->up and therefore use very little bitrate (as it should be), while the x265 encode uses a LOT more bitrate for this section.. Ill try to replicate that and dig a little into the search patterns. I am sure that this makes an impact of the overall score, because if almost 1/4 of the clip gets a magnitude more bitrate than needed, the demanding rest of the clip is starving...


BTW: Back in "the days", there was "bitrate viewer 1.4" for MPEG2 files... Any successor around?

just downlaoding "SOL LEVANTE" - the prores version is so big and the download speed so slow (not maxing out my Internet at all) - which version did you use? (Or did you wait 16 hours?).

I haven't tried CRF on x265 for this video because it's so slow, the bitrate allocation might differ there. CQP is usually the best choice on my GPUs. Sol Levante is 37.8GB big, it was fast when I downloaded.

[Yups]

Originally Posted by ReinerSchweinlin

This free video file of a blender Project would be interesting to test with a very low bitrate. I am fully aware that the results won`t be what one wants as end result - it´s more of a test how the encoder is dealing with very limited conditions.

https://upload.wikimedia.org/wikiped...ull_movie.webm

Yes, i´ts already compressed, but thats fine for me and represents a usecase for many of us anyway This video has a nice mix of "cartoon style" still scenes with a little gradient in the back, defined, sharp lines in the front, scenes with a little more action, some scrolling/paning, some textures, etc... The resolution is fine, if it´s no trouble for you, I´d love to see it in 720p.

There is a also a 720p version on this site. The CRF mode is a lot better than the bitrate mode for this type of content.

    
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 best                     88.59     167 fps     200 kbit


x265 (Staxrip 2.1.9.0)
i7-1165G7 slow                       84.61     26 fps      200 kbit
i7-1165G7 CRF slow                   88.18     34 fps      200 kbit

Link: https://drive.google.com/file/d/1zNP...ew?usp=sharing

[Yups]

Originally Posted by Yups

There is a also a 720p version on this site.

Some more reference points for this. CRF mode only for x264/265, it's much better than bitrate mode for this test case.

    
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


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

Fixed function speed preset does not support bframes on Iris Xe with current driver, 16 bframes for the other presets. Offset mostly 2:6:8, on some a bit lower depending on the output bitrate.

[benwaggoner]

Originally Posted by Yups

I haven't tried CRF on x265 for this video because it's so slow, the bitrate allocation might differ there. CQP is usually the best choice on my GPUs. Sol Levante is 37.8GB big, it was fast when I downloaded.

Sol Levante is my new favorite encoder stress test, as it has a lot of complex content of a type that encoders aren't typically optimized for. It's definitely the most challenging to encode source without film grain I've played with.

I'd expect HW encoders to lie down and cry (aka have a lot of visible artifacts) without using High Tier or raising level above the minimum required for frame size/fps. x265 placebo falls totally apart doing a 1080p24 Level 4.0 encode.

[ReinerSchweinlin]

Originally Posted by butterw2

The main takeaway for me was that the new decoder/encoder will not be available for the cheapest chips/motherboards right now.

Thanx, thats too bad. Oh well, an i5 then probably would be the way to go.

Originally Posted by YUPS

Fixed function speed preset does not support bframes on Iris Xe with current driver, 16 bframes for the other presets. Offset mostly 2:6:8, on some a bit lower depending on the output bitrate.

Thank you for testing "hero". Very interesting. Also thanx for the info about b-frames. Given the speed gain, this really looks like a usable alternative to software encoding for my planed "low power encoding rig". I expected Software Encoding to be more efficient in terms of quality/bitrate, but given the speeds and power consumption - the new XE Encoders seem "good enough". Expecting your testencodes visually, they really look good!

[Yups]

Iris Xe CQP is really good (for a hardware encoder), CBR/VBR are not that good due to some missing features (Lookahead). I wonder if Turing/Ampere can match or beat Iris Xe with its constant rate mode, is there a x265 comparison somewhere, how is it in comparison? Bframes support for fixed function speed preset might come in a later driver because their Linux Media SDK enabled it:

HEVC encode

Extended B frames support across all target usage with LowPower on


(LowPower= fixed function)

[Tenkei]

Originally Posted by Yups

Iris Xe CQP is really good (for a hardware encoder), CBR/VBR are not that good due to some missing features (Lookahead). I wonder if Turing/Ampere can match or beat Iris Xe with its constant rate mode, is there a x265 comparison somewhere, how is it in comparison? Bframes support for fixed function speed preset might come in a later driver because their Linux Media SDK enabled it:

HEVC encode

Extended B frames support across all target usage with LowPower on


(LowPower= fixed function)

Wouldn't 2 pass negate the lack of lookahead?

[benwaggoner]

Originally Posted by ReinerSchweinlin

While looking at you encodes, I noticed something:

The hardware-encoders all were able to detect the end-credits as simple paning from bottom->up and therefore use very little bitrate (as it should be), while the x265 encode uses a LOT more bitrate for this section.. Ill try to replicate that and dig a little into the search patterns. I am sure that this makes an impact of the overall score, because if almost 1/4 of the clip gets a magnitude more bitrate than needed, the demanding rest of the clip is starving....

Yes, x265 with default settings spends an inexplicable amount of bits on title cards and scrolling credits. My guess is a defect in the Rate Factor implementation which is way overestimating how low QPs need to be for that kind of content. It's nigh-impossible to tell the difference between credits at CRF 20 and CRF 40.

It's possible it is a better match for x264. With 4x4 CUs, --amp, --rect, and --tskip, x265 can encode details down to a single pixel width, and SAO is quite good at suppressing ringing artifacts for text and line art. Intra-frame prediction with 1/8th pel is also excellent for big pages of text in the same font; basically each repeated letter gets a near-perfect prediction without residual.

[benwaggoner]

Originally Posted by Tenkei

Wouldn't 2 pass negate the lack of lookahead?

Exactly.

Historically, it's more that lookhead partially negated the need for 2 passes, of course

[ReinerSchweinlin]

Originally Posted by Yups

Iris Xe CQP is really good (for a hardware encoder), CBR/VBR are not that good due to some missing features (Lookahead). I wonder if Turing/Ampere can match or beat Iris Xe with its constant rate mode, is there a x265 comparison somewhere, how is it in comparison? Bframes support for fixed function speed preset might come in a later driver because their Linux Media SDK enabled it:

HEVC encode

Extended B frames support across all target usage with LowPower on


(LowPower= fixed function)

It´s really too bad I don´t have my RTX Cards any more (Sold them to get bigger ones - and then... well not buying one right now ....the remaining AMD Cards will do for the moment). The Turing Encoder really isn´t that bad either, but as far as I remember it wasn´t as good as what XE can do. In lack of a direct comparison, this is only "my feeling"...

2-pass with nvencc: As far as I rmemeber its not really 2-pass in the traiditonal sense of doing the whole file twice / the encoder takes a GOP or other small number of frames and runs them twice internally. The hybrid encoder from mainconcept offloads rate control to the CPU while using nvenc of Turing - but that resultet in much lower speeds (pure nvencc in my tests above 150fps - same input files with the hybrid encoder: around 30fps).

Maybe someone with a Turing Encoder wants to jump in and encode the examples from above?

I could test my AMD Encoder - but without b-frames we can predict the outcome

Originally Posted by benwagoner

Thanx for confirming. I couldn´t find a "sane" setting for normal content which also works "as intented" on credit-szenes with x265.

[rwill]

Originally Posted by Tenkei

Wouldn't 2 pass negate the lack of lookahead?

It depends on how its implemented.

Lookahead shows the encoder how things probably will develop
short term wise while 2-pass will show an encoder the average
rate @ quantizer ( rate@CRF ), among other things, over the
whole sequence plus the dirty per frame details.

Lookahead is needed for short term decisions like estimating
the video buffer development over the next N frames. This can
be done up to the end of sequence in the second pass but also
over the next N frames with buffering delay in the first pass.

If it is implemented good 2-pass can 'almost' negate the lack
of lookahead in a first pass. It depends on how well the
"rate@quantizer" predictors for short term decisions are done.
If one predicts short term frame sizes from rate@quantizer
from the previous pass or rate@distortion_cost from the current
pass or a mixture of both and how good the overall system is...

rate@quantizer correlation might go bad if quantizer differs too
much between passes and rate@distortion_cost might be bad due
to bad rate correlation with distortion_cost.

It depends.

2 pass will always beat 1 pass though, just imagine a sequence
with 5000 frames of "bitrate breaking action" followed by 5000
frames of "solid black". Then imagine what happens if you swap
the display order of the two 5k parts around.

[Yups]

Originally Posted by benwaggoner

Yes, x265 with default settings spends an inexplicable amount of bits on title cards and scrolling credits. My guess is a defect in the Rate Factor implementation which is way overestimating how low QPs need to be for that kind of content. It's nigh-impossible to tell the difference between credits at CRF 20 and CRF 40.

x265 Bitrate mode is not good for this sample, possibly because of the scrolling credits which is quite long. I will add CRF scores later this week, CRF scores are a lot higher.

[excellentswordfight]

Playing a bit bit with quicksync on Xe, when i try to use ICQ mode with lookahead on an i7-1165G7 with QSVEncC i get the following message:

"LA-ICQ (Intelligent Const. Quality with Lookahead) mode is not supported on current platform"

Anyone know why? I thought that Xe should have support for most (all?) features?

I also noticed that VBV isnt supported in ICQ mode, is that a feature missing on the intel side or on the encoder side? Is it on any roadmap to support it? I'm not a fan of doing encodes that are not vbv compliant with selected level, cause with lookahead I would assume that it should be possible.

[Yups]

Are you trying Lookahead with H265? Intel does not support Lookahead on H265, only with H264 and it works there. About VBV, this is what I found in the Media SDK:

For variable bitrate control, the MaxKbps parameter specifies the maximum bitrate at which the encoded data enters the Video Buffering Verifier (VBV) buffer. If MaxKbps is equal to zero, the value is calculated from bitrate, frame rate, profile, level, and so on.

There is a max-bitrate option in QSVEnc, I think it works for VBR and LA_VBR (h264).

[Yups]

As promised, here my x265 CRF results from Sol Levante at extremely low 4k bitrates. The best Iris Xe CQP preset is basically comparable to x265 medium CRF which I believe is the worst I have tested so far (based on the VMAF scores).

  
Sol Levante                        VMAF      speed       bitrate

Quicksync H265 (27.20.100.9316)
Iris Xe CQP best                   72.45     20 fps      1378 kbit


x265 (Staxrip 2.1.9.0)
i7-1165G7 CRF slow                 75.44     1.7 fps     1365 kbit
i7-1165G7 CRF medium               72.63     3.8 fps     1378 Kbit
i7-1165G7 CRF very fast            69.30     5.9 fps     1371 Kbit

https://drive.google.com/file/d/1GZ6...ew?usp=sharing


main10 10 bit
gop 120
CQP 47_47_50
offset 2_5_10

[ReinerSchweinlin]

Thanx for all the work!!

[Yups]

Another x265/x265 CRF vs Iris Xe CQP comparison using this sample.

 
Intel Demo Clip               VMAF    PSNR    SSIM     VQM     speed    bitrate

Quicksync H265 
Iris Xe CQP best              91.76   41.85   0.9748   0.790   67 fps   2438 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

https://drive.google.com/file/d/1onL...ew?usp=sharing


Open gop 120 for all, as for Iris Xe I was using these settings:

CQP 23_24_26
offset 2_5_8
bframes 16


Interestingly Iris Xe wins VQM metric against x265 slow, whereas VMAF/PSNR/SSIM prefer x265 slow over Iris Xe. Personally I prefer VMAF.

[benwaggoner]

Originally Posted by Yups

Interestingly Iris Xe wins VQM metric against x265 slow, whereas VMAF/PSNR/SSIM prefer x265 slow over Iris Xe. Personally I prefer VMAF.

Can you expand on that? I've not really compared VMAF and VQM in depth myself. Why do you prefer VMAF?

Of course, all frame-scored metrics suffer from the problem of how to extrapolate from a score for a <10 seconds to a clip of meaningful duration that captures the impact of quality variation throughout a video.

[Yups]

I never use 10 seconds clips for this reason. As for your question I prefer their scoring system over the others, a higher score means better quality unlike with VQM. 100 means highest, 0 means lowest quality, it's simple.

With SSIM tiny differences in the scores could have big visual subjective differences, there is a tiny 0.001 difference between slow and medium in my last example. Apart from the scoring system I have more trust in VMAF, I believe it's closer to subjective quality than the others. However I wouldn't say it's always closest to subjective quality, there are surely cases where VQM or SSIM will do better.

[benwaggoner]

Originally Posted by Yups

I never use 10 seconds clips for this reason. As for your question I prefer their scoring system over the others, a higher score means better quality unlike with VQM. 100 means highest, 0 means lowest quality, it's simple.

With SSIM tiny differences in the scores could have big visual subjective differences, there is a tiny 0.001 difference between slow and medium in my last example. Apart from the scoring system I have more trust in VMAF, I believe it's closer to subjective quality than the others. However I wouldn't say it's always closest to subjective quality, there are surely cases where VQM or SSIM will do better.

And VMAF isn't really a "metric" in the traditional sense. It's a ML model to predict subjective scores based on several relatively simple objective metrics. The ML is trained on a variety of test encodes, and Netflix has periodically improved the ML training, and has added a new objective metric at least once. So the same clip measured with 2018 VMAF would have a different score with the 2021 VMAF.

VMAF is also limited by the sorts of content that was subjectively rated in their training set. Early VMAF didn't seem to have tested different adaptive quantization modes, and so VMAF wasn't accurate in predicting subjective quality between AQ approaches. And it rated dark scenes overly high for some reason, perhaps due to training content limitations. VMAF's underlying objective metrics are all luma-only, so everything gets compared as a black-and-white film. Automated tuning based on VMAF would naturally shift bits from chroma to luma more than is psychovisually appropriate.

VMAF scores are also not based on just the encode itself, but are relative to the resolution compared to. For example a 720p encode compared to a 720p source would have a significantly higher VMAF than the exact same stream compared to the source at 1080p.

I've not played with the latest VMAF much yet, and I presume it is improved in some ways. Which is good! But anyone giving a VMAF score needs to state what the comparison resolution was and what VMAF version was used.

That said, VMAF is absolutely the least-bad metric we've ever had, and is getting better.