Memory leak for DirectShow H264 Encoder Filter (with SDK 2.0.12.24071)

[dashut]

I'm currently running a few tests on the H264 Encoder (h264_enc_filter.dll) that comes with the Intel Media SDK 2.0.12.24071 and I found the following:

1. When I use the the Encoder "h264_enc_filter.dll" after installing Media SDK 2.0.12.24071 everything works as expected.

2. If I compile the "h264_enc_filter.dll" ("C:\\Program Files (x86)\\Intel\\Media SDK\\2.0.12.24071\\samples\\sample_plugins\\dshow\\sample_filters.sln" project: "h264_enc_filter") and then I register this dll (with regsvr32.exe): there's a noticeable memory leak and after about 20-30 seconds the filter consumes about 2GB of memory and crashes.

I have tried compiling in release and also debug: but still the memory leak remains.

I'm using GraphEdit.exe and taking an AVI file, then taking the Video pin connecting to the h264 Encoder and adding a null renderer. Like I said: if I take the default "h264_enc_filter.dll" that comes with the SDK then everything is okay, but if I compile it on my own and then use it: then there's a memory leak (I compile it without touching the code!).

What I currently intend to do is try out the SDK 3.0 beta, and hope that this is solved, however, is there any tip on how to solve it with the released SDK 2.0 (I just don't want to work with a beta release even if it works there)?
[added/edited:] Just tried SDK 3.0 beta5: and I can't compile the "h264_enc_filter" project! there are errors in compilation + tried using the "h264_enc_filter.dll" that comes already compiled: but that doesn't open in GraphEdit.exe! (although it does with SDK 2.0)...

Thanks, Dashut.

[dashut]

Looks like it's my mistake: I guess the second time I tried the SDK 2.0 (after failing with SDK 3 beta5): I forgot to register the DLL and I was using the "old" one I had - which I modified....

And the "old" one had time stamps modifications, which caused the memory leak (unknown why: but reverting the change worked!).

The original code is:

if (rtStart != -1e7)
{
rtEnd = (REFERENCE_TIME)(rtStart + (1.0 / m_pTimeManager->GetFrameRate()) * 1e7);
}
else
{
// if time stamp is invalid we calculate it basing on frame rate
hr = m_pTimeManager->GetTime(&rtStart, &rtEnd);
CHECK_RESULT_P_RET(hr, S_OK);
}

and my code was:

//if (rtStart != -1e7)
// {
// rtEnd = (REFERENCE_TIME)(rtStart + (1.0 / m_pTimeManager->GetFrameRate()) * 1e7);
// }
// else
{
// if time stamp is invalid we calculate it basing on frame rate
hr = m_pTimeManager->GetTime(&rtStart, &rtEnd);
CHECK_RESULT_P_RET(hr, S_OK);
}

because I wanted time stamps that would start from zero. I don't understand why this should cause a memory leak: but it did.

About SDK 3 beta5: I still can't compile it: so I returned back to SDK 2.0 (which now seems to work for me).

Sorry for the confusion, Dashut.

[Petter_L_Intel]

Glad to hear you resolved the memory leak issue. It's not an issue we have seen on our side.

I would guess the issue you're having with regards to compiling beta5 may be related to WindowsSDK base classes (are you referencing them in the same way as in the 2.0 samples?)? Can you provide some more info on how the compile fails?

Regards,

Petter