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,

I had commented the while loop in the destructor but forgot the actual constructor. I can now add it the graph, however when I run it the graph spits out "Could not change state. The operation completed successfuly HRESULT = 0x00000000" which i believe means it was successful.

I'll continue looking through the filter.

Cheers.

[Nina_K_Intel]

Ok, I will try tomorrow to test your version of HW library and not joined set-up.

[Martin_Vanputten]

Sounds good, I'll await to hear what you find.

Cheers.

[Nina_K_Intel]

Hi Marty,

The error may be caused by wrong SyncOperation call which you added. Please check that it is done with VPP session. And has a reasonable timeout.

m_mfxVPPSession.SyncOperation(syncP, 10000);

Please let me know how the leak behaves.

Regards,

Nina

[Martin_Vanputten]

Hi Nina,

That makes more sense, I had it set to 0 for a wait period. It now runs and I ran the graph several times... the last time graphdit was at 237,000 and pushing stop it went up to 253,000.

I have a feeling were very close though, I can feel it! What else can I try?

Cheers.

[Nina_K_Intel]

Oh, good to hear that at least we managed to make the patch run. But it's realy frustrating that you still see the leak.

Today I was checking with the public GFX driver that most likely is the one you have (BTW - can you please tell the exact driver version you are using?) and I saw "leaks" only on first several iterations of Play-Stop and then memory level stabilized. But I was using a very simple graph: Cam - YUY2 - Encoder-Dump

I will debug the code tomorrow to check where these first leaks come from.

Could you compare 2 versions of filter - the origial and with the patch - by dynamics of memory in several (10 should be enough) interations of Play-Stop? This should help me understand if we are on the same page regarding what we observe.

Could you also try building the minimum graph - e.g. use Dump filter instead of Muxer+FileWriter or Decoder+Renderer?

Thanks,

Nina

[Martin_Vanputten]

Hi Nina,

I'll keep testing...

The driver version is 64x 2.11.15.0

I'll keep you posted with what I find.

Cheers.

[Martin_Vanputten]

I ran through the iterations... and I do notice it stabalizing... I'm going to build the filter into our application and run a suite of tests such as 500 recordings in 10 second intervals, this will give me a better analysis. Keep you posted, thanks for all your dedication and hardwork! :)

Cheers.

[Nina_K_Intel]

Great to hear that! I'll wait for your results.

BTW - for graphics driver version - it should be something like8.15.10.2509, can you check throuhg DeviceManager->DisplayAdapter->Intel HD Graphics?

-Nina

[Martin_Vanputten]

Sorry I clicked on the details of the installer... the actual version number is 8.15.10.2509

[Martin_Vanputten]

Much better results... however we found a small bug in our code that kept us from doing the full suite of tests but will continue to do the tests after we squash it.

What we did find... out of 500 recordings we had stopped it at 302 because we wanted to go up to 200 recordings in 5 second intervals.

What we see after 302 recordings is 890,000K being utilized. Much better than before seeing how that was a new high score at about 1/4 of the previous memory consumption. However it would be nice if the application stabalized at around 20,000K.

After we set out to do 2000 recordings, we tested it on 2 machines for the night, coming in this morning i found that one of the machines did not have HW turned on so obviously the system crashes, and blue-screened.

The other machine got to 268 recordings at 1,125,000K and this is where we found a bug in our communications... the command being sent to turn the graph on was not being sent because of a socket buffer issue.

I'll keep you posted with more details later today.

Overall, much better so far... but still a small leak that allows the system to consume memory gradually.

Cheers.

[Nina_K_Intel]

Hi Marty,

Thanks for the good news. At this point, can you confirm by experiment that the remaining memory consumption is due to MSDK filter/library? Would it be possible to run your automated test with SW MSDK library to check consumption?

BTW, could you explain the usage model of multiple Play-Stop in your application? If the idea is to have chosen time frames in the output stream then probably Play-Pause would be sufficient. If separate output streams are needed - then it depends on file writer if it is able to write to a new file each time. And for this scenario the graph could be destroyed and created each time, though this could introduce bigger latency..

-Nina

[Martin_Vanputten]

I will see if I can find a machine to run the automatedtest with just graphedit and basic setup using just the software library.

We cannot do just play pause and there are different resolutions, hertz, and other criteria needed to create the stream each time. I currently dispose of the graph and recreate it with new formats each time depending on the format selected in the system. From what I can tell the latency is very small when waiting... about 2 milliseconds, give or take.

[Nina_K_Intel]

Thanks, Marty,

I see now. Sound like a good workaround considering the 2ms latency.

Anyways, I will keep investigating the leak at my side too.

Regards,

Nina

[Nina_K_Intel]

There is a new driver available:http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Graphics&ProductLine=Processor+graphics&ProductProduct=2nd+Generation+Intel+Core+Processors+with+Intel+HD+Graphics+3000%2f2000&ProdId=3319&LineId=3310&FamilyId=39

It's HW MSDK has API 1.3. I was originally experimenting with that driver. The fix for the issue you reported will be likely integrated in one of the 1.3 future libraries anyway. Could you try upgrading the driver and test the patch on it? Since HW dll API version is same 1.3 as MSDK 2012 sw dll you can use the original patch with joined sessions. It should be more effective.

Regards,

Nina

[Martin_Vanputten]

Hi Nina,

This is perfect... I'll start testing once again and let you know the outcome.

Cheers.

[Martin_Vanputten]

Hi Nina,

Quick question about the drivers... are they valid for Windows Embedded?

[Nina_K_Intel]

Nope, sorry. Only Win7/Vista.

[Martin_Vanputten]

Hi Nina,

Just tested the driver... was able to install it on an embedded system. Tested with old encoder as well as the newly patched one. The old one still leaks... however the patched one works very well... our tests concluded over 500 recordings without the system crashing so we should be in good shape for now.

Things are looking good :)

Thanks for your support Nina, cheers!

[Nina_K_Intel]

Hey Marty,

Such a good piece of news just before I go to sleep :-) Thank you for cooperation and good luck!

Nina

[Martin_Vanputten]

Hi Nina,

I see an issue with the patched encoder... I've just ruled everything else out that would cause this new scenario and swapping the intel encoder back to its original version confirms my results.

Whenencoding with the new patched version to a file... the time stamp is wrong... and when playing the video back it plays in twice the speed. Something we did affected the file directly for playback.

Any thoughts as to what it could of been, hopefully theres a quick fix. As of right now with this fix... no file can be played back with accurate results.

Cheers.