Encoding x265 with Intel Quick Sync + Low Power fails #5932
Comments
|
@galinart Any ideas what this might be? |
|
I'm just about to submit a patch that may fix this and hopefully it'll be in a nightly build soon. This problem is occuring because handbrake defaults low power to on under windows (it's off under linux) and the handbrake capability checking code is bugging out when the encoder init it uses always fails. Post that patch it will only be possible to experiment with low power by passing handbrake the lowpower=on parameter (use -x in HandbrakeCLI or the box in ghb). It should no longer crash provided your hardware/firmware supports low power encoding for the selected handbrake rate control method and codec. If it isn't supported the encode will fail, but hopefully only if you've used the lowpower=on user supplied parameter. With my 13th gen desktop CPU handbrake I can do a low power CQP HEVC encode that previously ran at 60fps at around 300fps so it should be bleeding obvious if you get it working. This probably isn't the place to suggest or discuss this but I'll likely disappear so you'll have to forgive me. I would presume that low power is not officially supported by handbrake so experimentation is entirely on you .. as is messing with any internal parameters. To encode at low power with the patch I have to use "force-cqp=1" parameter as my 13th gen desktop intel cpu doesn't offer low power ICQ hevc encoding, but does offer CQP. The low power CQP encoder is basically the same as the high power one and is as good as ICQ if you force it to use a much longer GOP parameter than the default handbrake uses. If you run handbrake with the spec. limit for image feature tracks (256 frames) at worst you'll hopefully get a longer than default GOP length that produces better encodes and handbrake will just restrict it to the highest value it's willing to use. "force-cqp=1:gop-ref-dist=256:gop-pic-size=512:lowpower=1" Using this makes it work a bit better but without patching handbrake so the full 256 frames are used by the encoder would I expect CQP to be visibly as good as ICQ. For now at least, your best bet for offline archival encoding is the default ICQ hevc which doesn't have a hierarchical B tree so isn't reliant on powers of 2 gop-ref-dist for each layer. It's also the case that a decoder which doesn't support the 256 image feature track required by gop-ref-dist=256 is just not specification compliant and so there's no reason to ever use anything except gop-ref-dist 256 unless you have bitrate or encoder/decoder lag constraints. With as long a GOP as possible the intel codec usually beats out the software encoder, not only in qualitative quality and file sizes, but in number of degrees the CPU has heated the room. |
and others
Problem Description
Lets say i encode a couple episodes of a season with H.265 (Intel QSV) plus low power quick sync activated in the settings.
A lot of the files finish successfully, but sometimes i get the following error and the encode failes:
[10:39:57] qsv_enc_init: using 'hardware (1) via D3D11' implementation, API: 2.10
Error code -5, hb_qsv_wait_on_sync 601
encqsv: hb_qsv_wait_on_sync failed (-5)
encqsvWork: qsv_enc_work failed -5
Retrying fails again. Restarting Handbrake and retrying fails too.
Deactivating low power quick sync in the settings decreases encoding speed, but the encodes finish successfully.
My system is an ASRock N100M Mainboard with Intel® Quad-Core Processor N100 CPU
It runs on Windows 11 with the latest intel drivers. (311.0.101.5382)
Activity Log, Crash Log or any other details
What Operating System are you running?
Windows 11
What version of HandBrake are you running?
1.7.3 (2024021000)
Where did you download HandBrake from?
Handbrake website
The text was updated successfully, but these errors were encountered: