The MBBRC flag improves quality for my videos converted in VBR bitrate mode. When I set this flag in combination with lookahead there is no difference. Is it correct that mbbrc doesn't work with lookahead?
Yes, you are correct. The LookAhead algorithm does not use the MBBRC or ExtBRC options. This is expected.
ExtBRC works with lookahead....but very very slow.
You report an interesting observation. The expected behavior is that if both ExtBRC and MFX_RATECONTROL_LA are enabled ExtBRC will be ignored and look ahead will work. There may be some bug in MSDK implementation though. Could you please tell your driver and MSDK library versions and the exact encoder parameters config, preferably via MSDK Tracer log?
Here an example for the command line: -h264 -w 1920 -h 1080 -extbrc 1 -b 5000 -lad 40 -rc 8 -u 4 -goprefdist 0 -goppicsize 0
This is valid for QSTranscode. LA and extbrc both enabled. When extbrc is set to 1 encoding speed slows down in a strong way. I would expect the same behaviour with Handbrake, although I haven't tried yet. My driver version is 22.214.171.124.3234. MBBRC on the other side will be ignored with Lookahead.
Same in Handbrake. So for Handbrake the command line with LA and extbrc is the following:
Thanks Michael, that's enough for me to investigate. I'll get back with results.
My investigation shows that extBRC is ignored if LA is set, as it should be, but by the time in code where extBRC is actually dropped from config MSDK already mistakenly changed async depth parameter to 1 from the default 4. This leads to performance drop due to natural slowness of async=1 plus some inconsistency between application pipeline vs. internal task queue depths. This is definitely a bug in MSDK implementation and we are grateful to you for finding and reporting it. Will fix this in one of the nearest driver updates.
To prove my assumption I checked that "la+extbrc+async_depth=1" give same fps as "la+async_depth=1".
The newest driver solved it. Are there any other changes beside the extBRC/LA fix?
which driver version did you use?
3277 (15.33 driver branch) is still not an officially released driver on Intel.com :(
15.33 driver is currently being developed and will have improvements mainly related to Windows 8.1.
The 15.33 driver I'm using is WHQL PV and from Intel. Driver releases from downloadcenter are badly outdated. After months no Lookahead. I learned soon or very soon means I don't know when.
Yes, we agree and understand the frustration. The issue of availability of newer drivers on intel.com has been escalated to appropriate teams.
126.96.36.199.3282 from Gigabyte. I know from some devs that they prefer to download from downloadcenter and not from other sources which is a problem when there is still no API 1.7 driver.