QuickSync and MSDK maximum bitrate & MJPEG HW decoder

[diamantis__nikos]

Hello.

I was testing various transcoders using MSDK and QuickSync HW encoding and I couldn't find the maximum bitrate for H.264 and MPEG2 encodings.

I searched the MSDK documentation and the help/readme files of the transcoders and didn't find anything.

Is there a maximum bitrate for H.264 and MPEG2 encodings using QuickSync HW ?

By using an MSDK MJPEG encoder, I managed to get a maximum bitrate of 2.9Gbps (yes, the number is right!) using -q 100 and an uncompressed source.

But with the same source using QuickSync HW encodings of H.264 and MPEG2, the encoders seemed to max out at ~60-70Mbps

Given than maximum bitrate of H.264 is officially 300Mbps (it can go at least double of that), I would prefer - if there is no other HW restriction - to be able to encode at max bitrate of 300Mbps.

Also I found out a bug in all QuickSync HW transcoders (which seems like an MSDK bug)

If you put a high average and/or maximum bitrate for HW encoding in H.264 or MPEG2, like 100Mbps, then the MSDK doesn't put the bitrate to the maximum value, but to an arbitrary value.

For example you may put average bitrate to 100Mbps and get a file with 3.8Mbps bitrate!

Or you can put the average bitrate to 90Mbps and get a file with a 19.8Mbps bitrate !

These are crazy results - I think is a bug inside MSDK.

One last question:

Do you know any decoder capable of HW acceleration of MJPEG codec using MSDK or DXVA2 directly ?

Thanks!

Nikos

[Surbhi_M_Intel]

Hi Nikos,

I have done an analysis on the bit rate we can achieve with H264 encoding. Right now, the highest I am able to achieve is 60Mbps with Media SDK HW and SW.
There is a sharp drop in the bit rate when trying to encode at higher bitrate like 80-100Mbps. Thank you for pointing it out. That is definitely an issue and we are looking into it. 
You can use Intel Media SDK HW which has capability to decode MJPEG with HW acceleration.  You can download the samples/tutorials from here

Thank you again for finding the issue. We would definitely try to fix this issue in our future releases and include that in our release notes. 

[diamantis__nikos]

Thank you for your time and effort.

I'm glad that you confirmed my results.

Waiting for a fix, in near future I suppose.

Nikos

[Emmanuel_T_]

Hi Nikos,

I have experienced a weird behaviour too when HW encoding in H.264 with high bitrates.

What I noticed is that even though you set the bitrate to something high (e.g 100-150 Mbps) the encoder won't use this range but will drop to something lower. However, I did manage to reach this range of bitrates and even higher when using constant QP. So it makes me think that this is not a HW limitation but rather an encoder limitation in non-constant QP modes.

But the question I have now, and I haven’t tried to investigate further, is whether the objective quality provided by such high bitrate bitstreams in constant QP is indeed higher that in non-constant QP. My assumption would be that the encoder does not use more bitrate (e.g. in vbr) simply because it would not make any sense from a RD point of view. In other words, the encoder may not be able to produce an higher quality encoding that would require this amount of bitrate.

But as I said, these are just assumptions...

Emmanuel

[Surbhi_M_Intel]

Hi Nikos,

I am able to figure out how you can achieve higher bit rate like 100-150Mbps while H264 Encoding through Media SDK. 

There is a parameter - BRCParamMultiplier which can help achieve higher bit rate, it multiplies to the target bit rate to get higher bit rate.
TargetKbps(desired bit rate) is mfxU16,  which will overflow after 65535. So to attain higher bit rate we should increase the value of BRCParamMultiplier and keep the value of TargetKbps within the threshold.

BRCParamMultiplier was introduced in version SDK API 1.3 to achieve higher bit rate. You can find more details about it in Media SDK manual which you can find in doc folder. Please change version to SDK API 1.3 or the latest in your code. By default Media SDK API version is set to 1.0 to allow backward compatibility. 

I have used the simple_encode tutorial from here. The version 0.0.3 is the latest set of tutorials for Media SDK.
Thank you for your Question again. 

[diamantis__nikos]

Hello again.

After several months, I decided to take a look again on the subject of maxbitrate for H.264 encoding.

I'm not a developer, so I used some apps that are using the -BRCParamMultiplier.

Using a Win 8.1 Pro x64 – Core i7 4790 (Haswell iGPU HD 4600) – Drivers v.4080 (Latest) – API v1.13 system I found out a new limitation for CBR, VBR and AVBR, which is ~365Mbps. After a little investigation it looks like the parameter can take large values and although the multiplication of bitrate * BRCParamMultiplier is right, the encoder behaves exactly like before, giving smaller bitrate values after hitting the ceiling of 360+ Mbps.

Using CQP 0 rate control on the sample that I had a max of ~365Mbps using the above RC modes, I managed to build a 3327Mbps (!) H.264 file, so I don't think it's a HW limitation.

Is it capped by the driver, MediaSDK or something else?

Waiting for your reply.

Thanks!

P.S

Nice article here https://software.intel.com/en-us/articles/common-bitrate-control-methods-in-intel-media-sdk

You may have to update the article about the new LA HRD compliant rate control with the latest API and there is a small typo, you write "BRCParamMultimplier", there is an extra m :)

[Surbhi_M_Intel]

Hi there, 

That's a really high bit rate (3327 Mbps) you are trying to achieve. This is a Media SDK architecture limit for the bit rate control for VBR and CBR, not a HW limitation which you have confirmed with your experiment. Question about your experiments- do you see any quality difference on really high bit rates, my understanding is after a certain point(differ for videos) there will not be a quality change. At the least not worth giving so much bits for a very small change in quality.  
Thanks for the article. corrected the mistake and we will soon have an article for LA mode.
Out of curiosity, why do you need such a higher bit rate?

Thanks, 
-Surbhi

[diamantis__nikos]

I did more tests today with a Win 8.1 Pro x64 system using a Core i5 2400 (HD 2000) SandyBridge and latest drivers v.4101.

Unfortunately, the restriction of 65536 Kbps still exists for VBR and AVBR modes, even after the use of BRCParamMultiplier.

Only CBR can go up to 360Mbps, before overflows again.

Weird restriction and only for Sandy...Do you know why ?

About Haswell, I'm not trying to achieve 3327 Mbps! I wrote that only to show that it seems there is no HW restriction, the limitation should be in software.

Which exactly is MediaSDK architecture limit in Kbps and for which RC modes ?

Is it possible to overcome this limit ?

For my tests, this has nothing to do with quality or differences between samples with different bitrate. It's only about decoding tests and limitations of decoders.