Beta 5 H.264 Encoder Memory Leak

[Martin_Vanputten]

Does anybody see a memory leak when using the H.264 Encoder in DirectShow? I noticed it in my application as every second while the graph ran it increased by 4 to 8 K. For the past two days I've been tryin to isolate the issue, as I have encoding for recording video and also playback graphs and the playback graphs work without any leaking. It's definatelly not my code because I just confirmed in graphedit by connecting a simple graph

video source - avi decompress - h264 encoder - dvd decoder - evr

I've tried with more advanced graphs and graphs such as file writing and different decoders, and different capture sources. The leak continues to happen however if I then go into the encoders property pages, and set the preset to "Normal", the leak all of a sudden goes away and the process (in task manager) increases a bit and then decreases and continues to do this but never goes over a certain limit which tells me its releasing com objects successfully.

Does anybody else see this? I just upgrade to beta 5 hoping it would fix it and before i was using beta 4. Thoughts, suggestions, concerns, ideas??

Thanks,
Cheers.

[Petter_L_Intel]

Hi Martin,

We will look into this and get back to you as soon as possible.

Just so that we can establish environment baseline, could you please provide some more info:

- What is the default Encoder preset you use?

- Are you running the filters on a machine that supports encode HW acceleration?

- Have you made any changes to the encoder filter or are you using the default sample implementation?

Regards,

Petter

[Martin_Vanputten]

Hi Petter,

The isolated example I did by using just graphedit; pulled the intel media sdk h.264 encoder into the graph and the default preset is User Defined. Target Usage is Balanced and bitrate is 6000. If I switch it to a normal preset it goes away. However in the application the end user will be able to select from the presets and categories the filter provides. And in the application the default settings are all set to automatic for simplicity on the users end.

I am running the filters on a machine that supports HW acceleration and tried it on a second machine to confirm. Just to confirm, is this an automatic flag or do I have to set something to enable hardware acceleration? I do notice the CPU jumping when encoding... could be the issue?

I have not made any changes to the encoder. I am using the beta 5 h264_enc_filter.dll and ultimatelly pulling it into a directshow graph via c#.

Cheers.

[Martin_Vanputten]

Some more information, not sure if its relative... but I have a dedicated nvidia 430... would this interfere with intel media? This being the case the second computer I tested on does not have a dedicated card and is just intel graphics.

Cheers.

[Martin_Vanputten]

I would like to confirm that this is software and not hardware accelerated. Apparently my nvidia graphics are messing with my intel graphics?

If I do manage to get HW encoding working properlly, I'm assuming the memory leak would go away however does this cause any concern on the hardware level?

[Martin_Vanputten]

Ah, on my development machine with the nvidia graphics and intel graphics, HW is disabled but just confirmed on a release machine with just the intel graphics that HW is enabled (encode partially accerlerated is disabled) however even though it's hardware enabled, still seeing this leak in memory. Hmm?

[Petter_L_Intel]

Hi Martin,

I did look into the issue you reported and I have identified a memory leak in the Media SDK DirectShow encoder sample. The issue does not seem specifically tied to HW or SW encoding. We are looking into a solution and will provide more info to you as soon as possible.

Thanks for helping us make Media SDK better!

Regards,

Petter

[Petter_L_Intel]

Hi again Martin,

Thanks again for reporting the issue. The DirectShow sample code bug will be fixed in the Gold release of Media SDK 2012 which is due for release a couple of weeks from now.

Regards,

Petter

[Martin_Vanputten]

Perfect... good to know it wasn't just me. Thanks for the support. Cheers.

[Martin_Vanputten]

This thread is a little bit outdated, however after working with the gold release for a couple months, just getting ready to release a product... I'm still noticing a weird buildup in memory when using the encoder. This can be reproduced in graphedit alone... if you start the graph, stop, and repeat the process several times then the memory footprint goes up. Eventually what happens is windows will display a warning message about memory consumption.

Any thoughts?

[Eric_S_Intel]

Hi Marty,

Yeah.. I see it using 2012 Gold. I am unsure whats causing it at this point and will investigate it.

-Eric

[Martin_Vanputten]

Thanks Eric, can you keep me posted on the status? Will an update come out for the samples or if its an easy fix maybe I can just edit it myself?

Cheers,
Marty

[Martin_Vanputten]

Any update?

Cheers.

[Eric_S_Intel]

Sorry Martin, No update.

I've got it in our database to be investigated, but its a national holiday in Russia and we are a bit short staffed this week. Is this a critical problem for your product launch?
-Eric

[Martin_Vanputten]

Yes by all means critical.

Heres the current scenario... we use the encoder in the medical workspace and our installer is currently onsite and leaves saturday morning, which gives me today and tomorrow to apply a fix.

It is very crucial we get this working because as of right now the memory issue when too high starts to affect the overal performance of our application and destroys the our mp4 muxer thus ending a recording too soon, 1 hour recording may only have 20 minutes. In a surgery this is bad!

Anything you can do to streamline the process of the memory leak would be greatly appreciated,
thanks Eric.

Cheers.

[Eric_S_Intel]

Ok Martin,

I'll pull Petter Larsson off what he was doing to help with the debug. Hopefully, we can find a workaround.
-Eric

[Martin_Vanputten]

Perfect, thank you very much! Again, very critical... please keep me posted. Thank you for your support.

Cheers.

[Martin_Vanputten]

Is it possible to get a copy of an earlier release where the leak does not exist? Is version 2 of the media SDK still available?

We have until the end of today to complete this project for the clients sake and ours... if version 2 is more reliable then it might be best to downgrade for now?

Are there any updates relating to the memory leak in version 3?

Cheers.

[Martin_Vanputten]

I'm trying to help out and locate the leak, no luck so far but in the receive function of mfx_video_enc_filter.cpp... theres a comment at line 199...

"mark that Receive function is responsible for freeing memory"

Is this a statement towards someone named Mark or is this like marking the line where were suppose to free memory?

[Eric_S_Intel]

Hi Martin,

Petter and I have been trying to debug this since yesterday afternoon. Unfortunately, its not really apparent where the leak is coming from. We continue to debug..

I certainly can provide the 2.0 DShow encode sample. I confirmed that this filter does not have the same memory leak however, there are some limitations with this sample as well. The 2.0 sample does not have YUY2 input pin support. We added that with 3.0.

We are continuing to look at the problem today, and I hope to have something to say later today.

If you want me to transfer MSDK 2.0 sample to you, please write me directly at: eric.sardella@intel.com to coordinate the transfer.

-Eric

[Nina_K_Intel]

Hi Martin,

We are debugging the leak and have a question, are you using MSDK HW or SW library in your experiment?

We have found a source of a small leak - it's the check inCBaseEncoder::InternalClose() method:

if (!jt->pmfxSurface->Data.Locked)

{

MSDK_SAFE_DELETE(jt->pmfxSurface);

jt->pSample->Release();

}

if (!jt->pmfxSurface->Data.Locked) { MSDK_SAFE_DELETE(jt->pmfxSurface); jt->pSample->Release(); }.

HW encoder may not free all the surfaces on Close call -this is a bug in MSDK dll which we will investigate and schedule to get fixed. The check can be removed to delete/free in any case - it's just an additional sanity check of MSDK encoder behavior.

But seems that it't not the main source of the leak as we still see it if we remove the check. We continue working on that.

The line which you have asked about - "//mark etc." only means that this flag tells that no need to store surface pointer and Receive function must free the memory when it exits.

Regards,

Nina