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.

[Martin_Vanputten]

Hi Nina,

Thank you for the update. I have been testing with hardware acceleration only as all our machines are outfitted with Intel boards. If we can get rid of the majority of the leak that should by us more time before the final fix is implemented.

Keep me posted, I have to keep my superiours up to date on the issue.

Cheers.

[Nina_K_Intel]

Hi Marty,

The resume is that the problem I mentioned yesterday is the actual and likely single reason for the leak.

It just wan't trivial to confirm that the fix helps, that's why I hestitated.

Can you please try the fix at your side?

Comment out the assert and condition as below at line 183 of base_encoder.cpp:

//assert(!jt->pmfxSurface->Data.Locked); // all surface should be unlocked

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

//{

MSDK_SAFE_DELETE(jt->pmfxSurface);

jt->pSample->Release();

// }

What I see in my experiments after the fix:

1) file-avi splitter-intel enc-dvd dec-evr

Private memory of gedit.exe fluctuates: among values 113,116,119,122, going up or down per each play-stop. I think it is connected with decoder and evr somehow as in 2) situation is different

2) file-avi splitter - intel enc - dump

Private memory stays almost constant, 63 smth Mb

(without a fix it would grow)

Please let me know if this helps. We will continue more detailed verification.

Regards,

Nina

[Martin_Vanputten]

Hi Nina,

I had just tested the fix, I still see memory left over after stopping the graph however the foot-print is smaller. I will have my tester run through some scenarios such as 500 recordings in 5 second intervals, before it crashes anywhere from 220 to 240... I'll keep you posted as to how many recordings we achieve.

Meanwhile, I'll await anything else that might help fix it.

Thanks Nina,
Cheers.

[Nina_K_Intel]

Hi Marty,

Thank you for such a quick feedback. It's good that there's at least a change. Can you tell what was the footprint before the fix and now - in size? And which chain do you test - cam-enc-mux-filewriter?

Also, what I saw after the fix was that memory size fluctuated - increasing or decreasing after a play-stop (I monitored over 10 iterations).

I'll keep looking for more issues, but the problem is that I don't see a leak any more - only fluctuation, which is normal I believe.

Regards,

Nina

[Martin_Vanputten]

Hi Nina,

While running the graph it would fluctuate, growing a bit in size and shrinking but never shrinks to its smallest size, and gradually grows... when stopping, starting, and stopping, etc... I see a 2000K footprint on every stop.

Cheers.

[Nina_K_Intel]

And what is the filters chain?

2Mb - you see now, right? And what was the value before the fix?

Thanks,

Nina

[Martin_Vanputten]

Before I was seeing anywhere from 3 to 5 Mb... definitely an improvement.

The chain of filters are as followed:

Decklink Video Capture -> AVI Decompressor -> Intel H.264 Encoder -> MainConcept MP4 Muxer -> FileWriter

[Martin_Vanputten]

Hmm,

My first test was with the application itself, but after testing with graphedit, it looks a lot better. Maybe I didn't copy the right dll to our project... I'll have to take another look to confirm, keep you posted.

Cheers.

[Martin_Vanputten]

Hi Nina,

After more testing... heres the breakdown

Development machine: software encoding, graphedit looks good, application almost as good
Release machine 1: hardware encoding, graphedit has 2Mb footprint, application same.
Release machine 2: hardware encoding, graphedit has 2Mb footprint, application same.

What I had noticed is that in graphedit, when the application does run, depending on when you stop (based on the high and low of the fluctuation), the footprint can be anywhere from 0 to 2Mb which might explain the results of graphedit on my development machine.

I used the same graph as denoted before, I believe the only diference between your graph is the video source, mine being a decklink card but we use the decklink in many applications and don't see any issues with memory consumption using this filter.

I will continue to see what I can find.

Cheers.


EDIT... the 500 recordings test got up to 251 recordings, new high score but still no cigar.

[Nina_K_Intel]

Marty,

I am finally able to reproduce and partly localize the leak.

It corelates with VPP presence before the Encode. Either of the following:

1) cam-(YUY2)-intel enc, VPP color conversion YUY2->NV12 is enabled, LEAK

2) cam-(MJPEG)-MS MJPEG dec-(RGB32)-intel enc, CSC plugin is enabled to convert RGB32->NV12, LEAK

3) cam-(MJPEG)-Intel MJPEG dec-(NV12)-intel enc NO LEAK!

4) file source-avi spl-intel enc, resize enabled through property pages, LEAK

If you manage to avoid color conversion in your pipeline as a temporary workaround the leak would go away.

I will keep searching for the exact location of the leak tomorrow.

Regards,

Nina

[Nina_K_Intel]

The leak is inside MSDK library HW VPP component: m_mfxVPP.Init allocates more than m_mfxVPP.Close frees. A fix in HW MSDK dll is required. A WA on filters level could be to create/delete m_mfxVPP object on BaseEncoder.InternalReset/InternalClose instead of calling Init-Close. There are other possible WAs, I will come back with more details tomorrow.

Nina

[Martin_Vanputten]

Hi Nina,

This looks interesting... however I can't avoid the color conversion due to the nature of the video source we are using... UYVY. I'll await to see what you find out today, but this is good news!

Cheers.

[Martin_Vanputten]

Hmm, I'm a bit confused about this workaround as I don't actually create a video-preprocessing object. I'm working solely in C# and calling the Encode filter through its GUID on a COM import attribute. I do release the object after the graph is built to conserve memory but I don't see any known functions based on the interface I'm using through DirectShow to do an InternalReset/InternalClose.

Maybe I'm missing something? Different interface maybe?

[Nina_K_Intel]

Hi Marty,

I meant that there are mfxVPP and mfxEncode Media SDK core library components inside Encoder Filter. mfxVPP has a leak. But we have already figured out that new/delete instead of Init/Close won't help as these MFXVideoVPP class is simply a wrapper over C functions, no actual destructor.

My suggestion for a workaround will be the following:

1) I checked that AVI Decompressor can output YUY2 among other formats

2) Encoder Filter uses CSCPlugin (SW code) in case of RGB32 top bottom and mfxVPP in case of all other formats to convert to NV12 for mfxEncode

3) in your case mfxVPP is used and it causes a leak

4) if you add YUY2->NV12 conversion to CSCPlugin and use plugin instead of mfxVPP you will avoid the leak

5) This should not be significant performance impact (sw conversion instead of hw) becuase as I have found out current filter code uses system memory surfaces between VPP and Encode. And HW components work on d3d surfaces natively. So extra copies occur in the current pipeline. If we remove copies and use SW conversion instead of HW there should be even performance improvement.

6) I will send you an e-mail with suggestions on how to modify the filter source code.

Regards,

Nina

[Martin_Vanputten]

Hi Nina,

I compiled the base_encoder files into the solution and tested in software mode (hardware mode isn't even available now)... but I still see a leak... anywhere from 4 to 6 megs. That and the CPU throttles at about 98%.

I'm am already using MainConcept's MP4 muxer and have played with the software encoder a bit which does not throttle that high nor is there any leak whatsoever... so I have branched the project off into MainConcept's world until the hardware fix is in place without any leaks.

As soon as the fix is in place for hardware encoding I will switch back.

Keep me posted.

Cheers.

[Nina_K_Intel]

Hi Marty,

I think the problem to run on HW system is that you haven't installed SW MSDK dll (libmfxsw32/64.dll from MSDK Gold package) there. The code I shared initializes an additional MSDK session with SW IMPL - it needs SW dll to be in dll search path. This session hosts SW VPP which doesn't have a leak. The original session initialized with IMPL_AUTO will pick up HW dll which was installed by graphics driver. This HW session hosts HW Encode. If SW dll is not in the system first session Init will fail.

Previously HW session hosted both HW VPP and HW Encode and HW VPP was causing the leak.

When I run on a SW system (no HD Graphics) and both sessions use SW dll I do see memory build up after several first play-stop's but it quickly stabilizes, so it's not a leak.

Please try on a system with HD graphics with SW dll also installed (copied and added to either PATH variable or local app folder).

Regards,

Nina

[Martin_Vanputten]

Hi Nina,

I'll let you know what I find.

Cheers.

[Martin_Vanputten]

Hi Nina,

Can you confirm the path for the SW library, I do have them in both 32 and 64 bit paths...

C:\Program Files\Intel\Media SDK 2012\bin

Cheers.

[Nina_K_Intel]

Hi Marty

The path should be C:\Program Files\Intel\Media SDK 2012\bin\Win32 for 32-bit dll andC:\Program Files\Intel\Media SDK 2012\bin\x64 for 64-bit dll.

You can run some simple sample from the package to check that MSDK 2012 installed correctly and SW dll can be found.

-Nina

[Martin_Vanputten]

Hi Nina,

It definitely is installed correctly. I will be persuing other options, in the mean time, if you need me to try anything to help with the process let me know.

Cheers.

[Nina_K_Intel]

So what is the current problem with the APP+WA? If both HW and SW MSDK dlls are available in the system, modified filter should work fine. Can you try GraphEdit?