Regression in VBR for TFF AVC encoding with frequent Reset()

[ViCue_S_]

We experienced a regression behavior from MFX_RATECONTROL_VBR RC moving app from Haswell to Skylake.

Major conditions to reproduce

• Interlaced input, MFX_PICSTRUCT_FIELD_TFF AVC encoding, 1080i@59.94
• Frequent bitrate change, like 6->5.8->6->5.8 Mbps (10 times per 30 field pairs/ second)
• GOP pattern – infinite P (no HRD compliance)

Application: We observe it with sample encode from MSS 2017R2 Linux, just a little change was made to invoke frequent bitrate change (multiple times per second). On both platforms the same application was used

HW/SW stack:

1. CentOS 7.2
2. HSW (i7-4650u, Intel Media Server2016R1)
3. SKL (i7-6500u,  Intel Media Server2017R2)

Result: HSW with MSS 2016 keeps very close to target bitrate, but SKL with MSS 2017 generate ~8x smaller bitstream (visually worse and PSNR ~2dB worse than HSW’s stream)

When BufferSizeInKB was increased from default value to 2sec size than SKL bitrate increased ~4x but still ~1dB worse and 2x smaller than HSW’s

What is disappointing that we expect similar behavior when app-with-no-change moved to new hardware generation. This bitrate behavior change is dramatically impacts whole product.

We could accept if bitrate declined while visual quality remained same. But significant drop in VQ can’t be excused by any bitrate savings.

We acknowledge the extreme Encoder Reset() usage in app keeps BRC blind with no past statistics. But the major point is that we expected (and MediaSDK backward compatibility claims assuring) behavior similarity from gen to gen.

Can you please recommend how to fix this issue? We need a quick workaround to make bitrate on SKL precise same as it was on HSW & MSS2016

With Best Regards!

[Dmitry_E_Intel]

Hi ViCue,

Thank you for detailed description. I reproduced the issue. We’re investigating it. 

Regards,

Dmitry

[Dmitry_E_Intel]

Although BRC reset can support such a high frequency, it is not designed and optimized for this kind of excessive reset. The reset frequency more than 1 per sec is not recommended. If the application really requires frequent change, use different MaxFrameSize for each frame would be a better solution. When BRC reset is called most of statistics are reset. That is why frequent reset is not recommended even though it can work well under certain conditions.

Regards,

Dmitry

[ViCue_S_]

Thank you Dmitry for your reply. In my case bitrate significantly undershoot, MaxFrameSize will not help. right? Do you have a MinFrameSize?

[Dmitry_E_Intel]

I meant that instead of frequent BRC resets (via encoder->Reset() ) , different MaxFrameSize for each frame would be a better solution to slightly decrease target bitrate. Another option is to keep target bitrate in a relative lower stable value instead of frequent BRC Reset calling. And of course external BRC is also an option.

Regards,

Dmitry

[ViCue_S_]

thanks for your reply. is my understanding correct that Intel does not accept this as a bug? shall we get this behavior as a new reality?

[Dmitry_E_Intel]

Yes, it's not treated as a bug.

Regards,

Dmitry

[ViCue_S_]

thank you Dmitry for your time investigating it. I have got a valuable feedback for your AI (and maybe come down to architects as well). When they want to improve something they better to make a clone. create a new VBR rate control instead of "improving" that something exist and works in millions of products for years. 

Yours, ViCue

[Artem_S_Intel]

Hi ViCue S, 

Are you experience the same problem on SKL without changing bitrate?

6->5.8 Mbps is not such a big change, I can propose as WA to use just 5.8 Mbps always  this won't affect quality hard way.