High CPU consumption and Green Frame Problem

High CPU consumption and Green Frame Problem

1.The CPU(i3 530@2.93GHz) consumption goesvery high whileusing the "Intel H.264 SDK Encoder" and the "Intel H.264 SDK Decoder"in the graphedit to deal with a 640*480,30frames/s video stream,which ismuch worse to the situation of using my own encoder and decoder.Why?

2.Green frames appearin the condition of using my own encoder and "Intel H.264 SDK decoder". (SetAcceleration(MFX_IMPL_AUTO)). But if the hardware acceleartion is disabled forcibly by setting"SetAcceleration(MFX_IMPL_SOFTWARE)",green frame problem disappear.

How can Iavoid the green frames while using my own encoder and the "Intel H.264 SDK decoder" with hardware acceleration?

Thanks !


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

Hi Patrick,

It sounds like its not using hardware acceleration, but I need some more information before taking a guess. For instance, what platform is this on? Does it have acceleration? What version of the Media SDK filters are you using? Have you updated your graphics driver recently, if not can you?

Also, can you share the registry key:

HKCU\Software\Intel\Media SDK Sample Filters\H264Encoder and H264 Decoder?

It strange that a clip would change going from HW to SW. There must be some kind of confusion between your own encoder and ours. We can check it out once I understand the platform a bit better.


Hello Eric,

Here is the information of my PC:

OS:windows 7 32bit

CPU:Intel i3 530


Display Adapter:Intel HD graphics(driver version:

Intel Media SDK verison:1.5 Gold

Video Capture Device:Logitech HD Webcam C270

registry keys:

I think I'm gonna explain more details of the problems I met with using Intel Media SDK. What I've done is:"capture video from a HD webcam--encode(H.264)--decode--display". I was trying to replace my own encoder and decoder with the sample filters in "Media SDK 1.5GOLD" to enable the hardware acceleration on my Intel i3 platform.

The graph "Webcam-myColorSpaceConverter-Intel Media SDK H.264 encoder-Intel Media SDK H.264 decoder-EVR" can run successfully. But the trouble is, the CPU occupancy rate goes as high as 90%,which seems abnormal. The screenshot below shows the details:

So my confusion is, why the CPU occupancy rate keeps so high?

Next, I replaced the "Intel Media SDK H.264 encoder" with my own encoder. The graph became "Webcam-myH.264encoder-Intel Media SDK H.264 decoder-EVR".Another problem occurred. The EVR window presents green frames like the picture I showed you.Only when I shake the webcam sharply,or wave my hands quickly before the webcam lens,the green frames disappear. Once I stop doing that,which means the pictures captured by the webcam remains steady,the screen returns to green frames. And I can judge from the register key that full HW acceleration was working at the moment. If I manually set "SetAcceleration(MFX_IMPL_SOFTWARE)" in your filter code to turn HW to SW,the problem disappear.

Why does your decoder running on SW works well with my encoder but presents green frames if it is running on HW?

I'm not sure if I had made my description ofquestions clear enough since I'm not a native English speaker.If not,please ask me for further description.

I really appreciate your help!


Thank you for the additional data. The graph: (Webcam-myColorSpaceConverter-Intel Media SDK H.264 encoder-Intel Media SDK H.264 decoder-EVR) is running the H.264 encoder in software mode so the CPU utilization should certainly be a bit high. However, I need to find out if its too high for that platform. I am going to need to check it out and see.

The green problem is quite interesting. Can you capture the resulting bit stream from the graph: Webcam-myH.264encoder-Filewriter and send it to me? Large enough to see the green corruption, but not huge please. Id like to interrogate that stream.

Hi,Eric. I've uploaded two stream files which were produced by:
(Webcam-Intel SDK H263 Encoder-Filewriter):IntelEncStream.h264

I've looked into the slices of this two different streams and I found it interesting that the constitution of slices of them are totally different.

(blue:P slice; red:I slice; green:B slice)

stream produced by my encoder:

stream produced by Intel SDK H.264 Encoder:

So, does this means that hardware decoding filtersdeveloped with Intel Media SDK can only handle streams of the form that the picture showed above?(But CyberlinkPowerDVD can correctly handle my encoderstream with full HW acceleration)

Another thing is, the Intel encoder stream file(12.1MB) is much bigger than my encoder file(5.18MB).
Even though with thefact that
MyEncStreamtime: 23 seconds resolution:1280*720
IntelEncStream time:11 seconds resolution:640*480

Thanks again.



I just wanted to let you know that I've recieved the streams that you posted and we are investigating it. I'll update this thread as soon as we have an idea on what is happening.

Thanks for your patience


We noticed that there are a lot of differences between the two streams that may contribute to the discrepancy in size, however whats more concerning is the validity of the MyEncStream.h264. This stream is encoded using the Baseline/Level1 profile with a resolution of 1280x720 which is not legitimate. This could be the reason for some of the artifacts. We will go back and look at the robustness of our HW encoders ability to handle these types of streams, but Id recommend aligning the two different test cases using a correct profile and give it a try again.

Thanks for your question!


Thanks for your advice!


Whatis the correct profile?


I am not sure I understand the question. The correct profile depends on what your trying to do. However, the file that was created with the sample encoder filter has these settings:

Inform : 7 200 Kbps, 640*480 (4:3), at 30.000 fps, AVC (High@L3.2) (CABAC / 2 Ref Frames)

And the other file:

Inform : 1280*720 (16:9), at 25.000 fps, AVC (Baseline@L1.0) (1 Ref Frames)

The sample encoder filter settings can be modified in code, or the aforementioned registry keys.


Best Reply

Hi Eric,

When I used intel sample_decode.exe with "-hw" option to decode one test file t.h264,I encounted the same issueofGreen Frame. The file's information is as the following:

Input file : t.h264
Output file : t.yuv
Dimension : 1280 x 720
Profile : High
Level : 3.1
Max. bitrate : 513 kBps
CPB Size : 1025.0 kBits
Mode : VBR
DPB size : 1
PAR : 1/1
Timing info : present
Time scale : 180000
Min. duration : 3750
Max. pic.-rate: 48.000
Fix frame rate: yes

There is no any Green Frame issue without using "-hw" option. I guss haredware acceleration may cause the issue.
Thank you in advance!


Hi Eric,

I got more information for the issue. If GPU isSandyBridge HD Grsphics, there is no Green issue. If GPU is Intel Q45/Q43 Express chipset, the issue occurs. Does the Q45 GPU support the hardware acceleration for H264 decoder?


Hi Ishang,

The Q45 chipset has the Intel Graphics Media Accelerator x4500 which does support h.264 decode acceleration. The platform specific library is bundled with the Graphics Driver Install. Have you updated your driver recently? If not, please do so:


Also, check \program files\Common files\Intel\MediaSDK\i1\ver\ and get the version number of the libmfxhw(64/32)-i1.dll.


Added 2/23 - Just a point of clarification. The x4500 part comes in 2 different flavors. To use the MediaSDKs hardware acceleration you need to have a G45/GM45 based chipset minimum. See http://en.wikipedia.org/wiki/GMA_X4500#GMA_X4500 for the different skews and features



Just to note, using the Media SDK 2012 sdk in software mode (as my hardware does not support the hardware encoding), I still get the green artifact. I'm using the sample encode example app.

My batchfile is this:
sample_encode.exe h264 -i city_4cif.y4m -o OutputEncodedFile -w 176 -h 144

I've tried playing the raw stream in SMPlayer, as well as added the container using Yamb, and I get the same exact results (green artifacts as this person reported).

Note, the input file was taken from http://trace.eas.asu.edu/yuv/ as your developers guide suggests.

I'm using all your tools in your Intel Media Developer's guide and figured this was going to be an easy test to see if we wanted to use your SDK. Am I doing something wrong taking this raw video and trying to convert it to h264? If the software implimentation doesnt work and we are required to always have the sandy bridge CPUs, this sdk may not work for our customers. From what I read however, this SDK should work, but just drop back to the software mode.

The batchfile as you will see from your example will have bUseHWLib = 0; I did a memset at tmain to ensure the structure is all 0s



Any ideas?



From your description I do not see any issues. My guess is that the content you are feeding the encoder is not of YUV type.
The "city_4cif.y4m" file you refer to does not seem to part of the content from thehttp://trace.eas.asu.edu/yuv/site.

Just to make sure I downloaded the first QCIF clip (akiyo) from the website:http://trace.eas.asu.edu/yuv/

I'm able to encode this raw clip (after unzipping) into an H.264 stream using SW encode without issues, using the following command: "sample_encode.exeh264 -i akiyo_qcif.yuv -o tst.264 -w 176 -h 144"

My apologies!I was sure I downloaded city_4cif.y4m from that site. My issue is resolved and this is working!

Thank you,

Leave a Comment

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