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.

[Nina_K_Intel]

Hi Marty,

I will investigate. Sure there must be a fix for this. I'll get back to you as soon as I find the rootcause.

regards,

Nina

[Nina_K_Intel]

Marty,

I'm not able to reporduce the problem. Don't see any dfference so far. But I use MSDK Muxer so it can be different form your setup. I will check timestamps directly tomorrow.

Meanwhile - could you check timestamps values at your side, after VPPFrameAsync in old and new code? The patch doesn't touch timestamps in any way. The only difference is that HW VPP is replaced by SW VPP. Could be that they calculate differently.

Please also double check your code for other changes..

Thanks,

Nina

[Martin_Vanputten]

Hi Nina,

To fix the playback issue, I looked through some of your changes in base_encoder.cpp and the while loop in SetAcceleration to disjoin the vpp session seems to be causing it... commenting out the loop fixes the playback but then it eats up the memory again... I'll continue to diagnose.

Cheers.



EDIT:

Commenting out just the MFX_THREAD_WAIT in that loop will fix the playback issue.... however still a memory issue.

I also debugged the video source a bit... it says its UYVY however it almost looks like the encoder is pulling it in as RGB32. Thoughts?

[Nina_K_Intel]

Hi Marty,

This is really strange. THREAD_WAIT and that loop should not be affecting timestamps anyhow. Having RGB32 as encoder filter input can lead to memory problem if CSCPlugin is invoked (in case of bottom up RGB32). Can you checked whether it is invoked or not?

Nina

[Martin_Vanputten]

Just to confirm I have all the RIGHT changes in my encoder base file... can you send your modified copy so that I can compare with me own?

[Nina_K_Intel]

Sure, I'll send you by e-mail.

Nina