Something strange with VBR

Something strange with VBR

I develop a application for video streaming with mfx encoder of Intel media SDK. 

I set 5 Mbps for target bitrate with VBR. 

When my scene is idle, the actual bitrate still is about 1  Mbps. (a little high)

I think the birate should be as low as possbile in idle scece.

Does any bady give me some idea?

22 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


There are many valid reasons you may be seeing encoded bits created for idle scene. For example, the Group of Picture (GOP) pattern of encoded frames may be generating independent (I) frames that do not reference other frames. This is desireable behavior.

Is this the level of information you were looking for? If you have a specific example you feel may be incorrect, I would need more information about hte specifics of how you have setup the enocde.


This is my setting. I take a scheme that has only one I-frame (GopPicSize = 0), so I think I will get a bit-streaming has low bit-rate in idle scene.
But I find I get too many "P_L0_16x16 mode" MBs, not p-Skip MBs in idle scene. The judgement of MB mode is strange.
I still get the bit-streaming with 1Mbps in idle scene.
Do you give me some suggestion? Thanks.

m_mfxEncParams.mfx.CodecId = MFX_CODEC_AVC; // H.264
m_mfxEncParams.mfx.TargetUsage = MFX_TARGETUSAGE_BEST_SPEED
m_mfxEncParams.mfx.TargetKbps = 5000;
m_mfxEncParams.mfx.RateControlMethod = MFX_RATECONTROL_VBR;
ConvertFrameRate(pInParams->dFrameRate, &m_mfxEncParams.mfx.FrameInfo.FrameRateExtN, &m_mfxEncParams.mfx.FrameInfo.FrameRateExtD);
m_mfxEncParams.mfx.NumThread = 0; // if 0 then encoder decides
m_mfxEncParams.mfx.EncodedOrder = 0; // binary flag, 0 signals encoder to take frames in display order

m_mfxEncParams.mfx.CodecProfile = MFX_PROFILE_AVC_BASELINE;
m_mfxEncParams.mfx.CodecLevel = MFX_LEVEL_AVC_4;
m_mfxEncParams.mfx.GopPicSize = 0;
m_mfxEncParams.mfx.GopRefDist = 1; // only i-frame, p-frame
m_mfxEncParams.mfx.GopOptFlag = 0;//MFX_GOP_CLOSED | MFX_GOP_STRICT;
m_mfxEncParams.mfx.NumRefFrame = 1;
m_mfxEncParams.mfx.NumSlice = 1;


Downloadimage/jpeg idlescene.jpg703.78 KB

My application is about remote desktop.When I encode the idle scene of my desktop, I see the bitrate is about 1.2Mbps and too high.
I put my analyzed result in the attached file "idlescene.jpg". A idle frame need 40 kbit. (40K*30 frames= 1.2Mbps)
There are 20% MBs of P_L0_16x16 in a frame, but this is a idle frame.
I think there are something wrong.

Another problem. I set GopPicSize to Zero. But I still get I frame every 257 frame.
Please see the attached file "Strange_Iframe.jpg".


Downloadimage/jpeg idlescene.jpg703.78 KB
Downloadimage/jpeg strange-iframe.jpg806.87 KB

Thank you for the detail information. This definiatly helps me understand your concern and usage model. I'll investigate.
For the GopPicSize=0 issue, I beieve there is an intentionly limit on max size of GOP.


I developers are looking at this. Can you confirm if this is exectuitng MediaSDK as 'software' or is it on a hardware platform with Intel HD Graphics? If it is the latter, which one and which graphics drivers are used?



Hi Tony,

I use the hardware Encoder(MFX_IMPL_HARDWARE), the driver of graphics driver is the Intel media SDK is v.3.5.915.45249.


Hi Tony:

I test this Intel QSV encoder with two idle scene.
The bitrate of the idle scene 1 is ok (avg. 260 Kbps), but the bitrate of the idle scene 2 is too high (2710 Kbps).
I think there is something wrong.
The attached figure is the bitrate information which I get from our client.



Downloadimage/jpeg scene-caomparsion.jpg1.5 MB

Thanks RouYun,
I've reproduce the issue, developers are looking into it, and I'll provide any update here.


Hi RouYun,
No update, but it is being tracked as an issue. I'll keep you informed.

Hi Tony:

I see the intel media sdk 2013. any update for this issue in this sdk?

- Rouyun

Hi Rouyun,

Thank you for your patience.  This issue will be resolved in the next versions of drivers for 3rd Generation Intel(R) Core(TM) Processors.

Hi Tony:

I update the new driver with intel HD 2500. The bitrate is too high(about 2Mbps) in idle scence.




This should not be the case and I see similar bitrate as SW with this driver.  Can you capture a log using the <MediaSDK>\tools\mediasdk_tracer\tracer.exe tool?

I wonder if the old MediaSDK DLL might still be getting used on your system.  Do you recall any issues/errors when you installed the new driver? 

Can you also provide these log files?: 



Maybe we can see what is wrong by looking at these.  THANKS

Hi Tony:

I already removed old driver, and install the new driver.  I didn't get any error, and still got the same encoding results.

I can use the sample code of Intel media SDK to reproduce the same status.

There are my modifyed pipeline_encode.cpp and you can rebuilded sample_encode.exe in the attached file.

I modifyed some configurations of encoder like "m_mfxEncParams.mfx.RateControlMethod = MFX_RATECONTROL_VBR; " in pipeline_encode.cpp.

my test arguments is 

sample_encode.exe h264 -i ..\content\input.yuv -o ..\content\output.264 -w 1024 -h 768 -f 30 -b 5000 -nv12 -hw -u speed

After I run the sample_encode.exe,  I get a the bistream "Output.264".

You can see the size is 6,281,247 bytes(6281247*8 =50249976 bits ), and you can see the input file has 272 frames with 1024x768 and NV12 format.

the average bitrate is 5.540 Mbps (272/30 = 9.07 Secs, 50249976/9.07=5540240 bps)

My input .yuv file is always idle scene. I think the bitrate is too high with VBR.

Please help me check these issue. Thanks.

P.S. the input .yuv file is too big, I put it in Dropbox.



Downloadapplication/zip iqsv-vbr-test.zip5.87 MB

Hi Tony:

Do you have any update dor this issue?



Hi RouYun,

We duplicated what you are seeing and are investigating. Thank you for the clear reproducer.

This appears to be a different 'root cause' than the issue that was fixed.  I should have more information very soon.

Hi Tony:

Do you have any information to fix this issue in new Intel Media SDK2013R2?

I get the same situration and my bitrate still is high with VBR control.



Hi RouYun,

The algorithm used in newer drivers is considered to be 'correct' as it achieves the requested bitrate (just not as 'optimal' as it could be with different algorithm).  Please make sure you update the drivers (as the MSDK 2013 R2 release does not change the driver implementation of this).

The issue is better if "target usage" is not set to the fastest 'speed' value of 7.  On our latest 4th Generation Core processors you will likely find that Target usage 6 provides the optimization you are looking for while maintaining the speed you desire.

We are always looking to improve, and I will make usre the developers are aware of the concerns.  Thank You.


I follow the same way to test the encoder and VBR rate control of IntelMediaSDK2013R2. The bitstream is more small than last version " IntelMediaSDK201" with targe usage"speed" in idle scence. but I think it still a little big in idle scence. (my test file is input.yuv in previous reply. threre are 272 frames in this file) 

test parameters:

sample_encode.exe h264 -i ..\content\input.yuv -o ..\content\output.264 -w 1024 -h 768 -f 30 -b 5000 -nv12 -hw -u speed

I change the target usage with "-u speed", "-u quality", and "-u balanced" , and I get different size of bitstream. the bitstream with "-u speed" is more small than "-u quality", and "-u balanced" in my test.

"speed" : 3.453 Mbps (272/30 = 9.07 Secs, 3915938*8/9.07=3453970 bps)

 "banlanced" : 4.655 Mbps (272/30 = 9.07 Secs, 5277365*8/9.07=4654787 bps)

"quality": 4.649 Mbps (272/30 = 9.07 Secs, 5270571*8/9.07=4648794 bps)

"speed" of last version : 5.540 Mbps (272/30 = 9.07 Secs, 50249976/9.07=5540240 bps)

By the way, why do I only use the API v1.6 on 3rd generation CPU, not v1.7? My CPU is i5-3450 and the new driver is v. 

In the document "" , It describes "Only 3rd and 4th generation Intel® Core™ processor family-based platforms fully support the latest API versions." in section 2.1.1.

any mismatch?

the attched files are my system analyer and test steps.


Because is an API 1.6 driver, even on Haswell. There is no graphics driver with Media SDK API 1.7 support available. That being said, all or some of the new API 1.7 features are Haswell exklusive.

Michael is correct.  The driver with hardware acceleration support of API 1.7 will be available very soon.

Leave a Comment

Please sign in to add a comment. Not a member? Join today