18.104.22.168.3316 22.214.171.124.3325 Tested these two drivers. With both drivers lookahead fails with both Handbrake and QSTranscode. All other bitrate modes work fine. The cause is libmfxhw64.dll/libmfxhw32.dll from driver 3316 and 3325. By replacing it with dll's from driver builds 3308 or earlier Lookahead is working again. Looks like something is wrong in 3316 and 3325, or is it intended for whatever reason? Is there a fix planned?
Using 3316 I tried LA here on my side with some of our internal tools and Media SDK sample_encode. I do not encounter any issues.
I suspect the issue may be connected with the specific applications you refer to. Can you please provide the command line configurations you used with these tools or even better a Media SDK trace log for the individual workloads.
From where did you get the 3316 and 3325 driver?
Can you try Handbake? Also what Windows did you test? In Handbrake simply use very best quality--> TU2 and Lookahead will be automatically enabled on Haswell. Otherwise copy and paste this into the advanced query field:
We can confirm that there is an issue with some LA usages on 3316 and later drivers. The root of the issue has been identified and we are working on both a Handbrake specific workaround and a long term solution for LA for the graphics driver.
Thanks for making us aware of this issue.
Yesterday I tried LA with QSTranscode 1018 and it worked unlike Handbrake. But there were big differences in speed, encoding time 50% faster than 3308 driver and earlier. With your post it is clear something unintended happened.
The driver just released (assuming you refer to 3345) on Intel.com does not have the required fix. It will be part of the next driver drop.
However, the issue you observed was due a very specific use of the SDK API for LA as used by Handbrake. Correct?
A workaround (https://trac.handbrake.fr/changeset/5851) was implemented in recent nightly HB builds. Can you please try recent nightly build. Let us know if this helps.