I updated to the newest video

Dave_S_3 · ‎11-19-2015

With this piece of test code memory seems to leak. Am I doing something wrong?

while(1)
{
mfxVersion min_version;

min_version.Major = 1;
min_version.Minor = 0;

m_mfxSession.Init(MFX_IMPL_HARDWARE_ANY, &min_version);
m_mfxSession.Close();
}

I'm using the video driver dated 5/25/2015, version 10.18.10.4226

Jiandong_Z_Intel · ‎11-19-2015

Hi There, Are you using Windows ? Media Server Studio or INDE ? if so. Please send mediasdk_system_analyzer log to me, you can find mediasdk_system_analyzer under following folder. \mediasdk\tools\mediasdk_system_analyzer. Thanks Zachary

Dave_S_3 · ‎11-20-2015

After about 8 hours the application with the while-loop was using over 1.4GB of memory.

Here's the output from the system analyzer:

Intel Media SDK System Analyzer (32 bit)

The following versions of Media SDK API are supported by platform/driver:

Version Target Supported Dec Enc
1.0 HW Yes X X [Adapter 1]
1.0 SW Yes X X
1.1 HW Yes X X [Adapter 1]
1.1 SW Yes X X
1.3 HW Yes X X [Adapter 1]
1.3 SW Yes X X
1.4 HW Yes X X [Adapter 1]
1.4 SW Yes X X
1.5 HW Yes X X [Adapter 1]
1.5 SW Yes X X
1.6 HW Yes X X [Adapter 1]
1.6 SW Yes X X
1.7 HW Yes X X [Adapter 1]
1.7 SW Yes X X
1.8 HW Yes X X [Adapter 1]
1.8 SW Yes X X

Graphics Devices:
Name Version State
Intel(R) HD Graphics 4000 10.18.10.4226 Active
AMD Radeon E6760 15.200.1045.0 Active

System info:
CPU: Intel(R) Core(TM) i5-3610ME CPU @ 2.70GHz
OS: Microsoft Windows Embedded Standard
Arch: 64-bit

Installed Media SDK packages (be patient...processing takes some time):

Installed Media SDK DirectShow filters:

Installed Intel Media Foundation Transforms:
Intel« Hardware M-JPEG Decoder MFT : {00C69F81-0524-48C0-A353-4DD9D54F9A6E}
Intel« Hardware VC-1 Decoder MFT : {059A5BAE-5D7A-4C5E-8F7A-BFD57D1D6AAA}
Intel« Hardware H.264 Decoder MFT : {45E5CE07-5AC7-4509-94E9-62DB27CF8F96}
Intel« Hardware MPEG-2 Decoder MFT : {CD5BA7FF-9071-40E9-A462-8DC5152B1776}
Intel« Quick Sync Video H.264 Encoder MFT : {4BE8D3C0-0515-4A37-AD55-E4BAE19AF471}
Intel« Hardware Preprocessing MFT : {EE69B504-1CBF-4EA6-8137-BB10F806B014}

Dave_S_3 · ‎11-20-2015

I updated to the newest video driver and media sdk libraries and it doesn't seem to have help any.

Intel Media SDK System Analyzer (32 bit)

The following versions of Media SDK API are supported by platform/driver:

Version Target Supported Dec Enc
1.0 HW Yes X X [Adapter 1]
1.0 SW Yes X X
1.1 HW Yes X X [Adapter 1]
1.1 SW Yes X X
1.3 HW Yes X X [Adapter 1]
1.3 SW Yes X X
1.4 HW Yes X X [Adapter 1]
1.4 SW Yes X X
1.5 HW Yes X X [Adapter 1]
1.5 SW Yes X X
1.6 HW Yes X X [Adapter 1]
1.6 SW Yes X X
1.7 HW Yes X X [Adapter 1]
1.7 SW Yes X X
1.8 HW Yes X X [Adapter 1]
1.8 SW Yes X X

Graphics Devices:
Name Version State
Intel(R) HD Graphics 4000 10.18.10.4276 Active
AMD Radeon E6760 15.200.1045.0 Active

System info:
CPU: Intel(R) Core(TM) i5-3610ME CPU @ 2.70GHz
OS: Microsoft Windows Embedded Standard
Arch: 64-bit

Installed Media SDK packages (be patient...processing takes some time):

Installed Media SDK DirectShow filters:

Installed Intel Media Foundation Transforms:
Intel« Hardware M-JPEG Decoder MFT : {00C69F81-0524-48C0-A353-4DD9D54F9A6E}
Intel« Hardware VC-1 Decoder MFT : {059A5BAE-5D7A-4C5E-8F7A-BFD57D1D6AAA}
Intel« Hardware H.264 Decoder MFT : {45E5CE07-5AC7-4509-94E9-62DB27CF8F96}
Intel« Hardware MPEG-2 Decoder MFT : {CD5BA7FF-9071-40E9-A462-8DC5152B1776}
Intel« Quick Sync Video H.264 Encoder MFT : {4BE8D3C0-0515-4A37-AD55-E4BAE19AF471}
Intel« Hardware Preprocessing MFT : {EE69B504-1CBF-4EA6-8137-BB10F806B014}

A co-worker has provided this call-stack of what could be leaking:

igdumdim32!OpenAdapter+0008E05E
igdumdim32!OpenAdapter+000AF689
igdumdim32!OpenAdapter+000D8B1E
igdumdim32!OpenAdapter+000D1FA9
igdumdim32!OpenAdapter+000EE976
igdumdim32!OpenAdapter+000C1A9B
igdumdim32!OpenAdapter+000C194E
igdumdim32!OpenAdapter+000BE3AF
igdumdim32!OpenAdapter+000CB4A3
igdumdim32!OpenAdapter+000B3E86
igdumdim32!OpenAdapter+000B3B48
igdumdim32!OpenAdapter+000A88DF
d3d9!Direct3DCreate9+00000DE7
d3d9!Direct3DCreate9+00000EF4
dxva2!OPMGetVideoOutputsFromIDirect3DDevice9Object+00002851
igfxcmrt32!CmThreadSpace_RT::SetThreadSpaceColorCount+0000136E
igfxcmrt32!CmDevice_RT::InitPrintBuffer+000000D7
igfxcmrt32!CmThreadSpace_RT::SetThreadSpaceColorCount+00000DDB
igfxcmrt32!CreateCmDeviceEx+0000001F
libmfxhw32!MFXVideoVPP_GetVPPStat+00055B6A
libmfxhw32!MFXVideoCORE_GetHandle+0000B40C
libmfxhw32!MFXVideoCORE_GetHandle+000094FD
libmfxhw32!MFXVideoVPP_GetVPPStat+00062C9B
libmfxhw32!MFXVideoDECODE_Init+00000156

I guess we would need better debug information to provide a more useful call stack but I believe that while loop is pretty easy to reproduce the issue.

Stern__Jason · ‎11-20-2015

Just a correction - while that call stack is present, this call stack appears in significantly more memory allocations:

       ntdll!RtlUlonglongByteSwap+00000B69
       d3d9!???+00000000 : 6B0D4D01
       d3d9!???+00000000 : 6B0D4D7D
       d3d9!???+00000000 : 6B0D4D38
       d3d9!DebugSetLevel+00073AE3
       d3d9!Direct3DCreate9Ex+0000695D
       d3d9!Direct3DCreate9Ex+00007766
       d3d9!Direct3DCreate9Ex+00003F40
       d3d9!Direct3DCreate9Ex+00009FF2
       d3d9!Direct3DCreate9Ex+0000B99C
       libmfxhw32!MFXVideoCORE_GetHandle+0000892C
       libmfxhw32!MFXVideoCORE_GetHandle+00009A3B
       libmfxhw32!MFXVideoCORE_GetHandle+000089D2
       libmfxhw32!MFXVideoCORE_GetHandle+00008ECF
       libmfxhw32!MFXVideoCORE_GetHandle+00008E78
       libmfxhw32!MFXVideoVPP_GetVPPStat+00064069
       libmfxhw32!MFXVideoDECODE_QueryIOSurf+00000189

My best guess is that a DirectX 9 resource is being allocated and not freed.

Jiandong_Z_Intel · ‎11-23-2015

Thanks for your information, I am reproducing this issue.

Does this issue only happened on 32-bit program ? or the same result happened on 64-bit program on your end ?

Thanks

Zachary

Jiandong_Z_Intel · ‎11-24-2015

Hi Dave S,

I tried to reproduce this issue by following code -

// testmemleak.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "mfxvideo++.h"


int _tmain(int argc, _TCHAR* argv[])
{
    MFXVideoSession         m_mfxSession;
    unsigned int            i = 0;

    printf("test start ...\n");

    while(1)
    {
        mfxVersion min_version;

        printf("test on %d\n", i++);

        min_version.Major = 1;
        min_version.Minor = 0;

        m_mfxSession.Init(MFX_IMPL_HARDWARE_ANY, &min_version);
        m_mfxSession.Close();

        //Sleep(1);
    }

    printf("test end ...\n");

	return 0;
}

And I can't reproduce this is on Graphic Driver 10.18.10.4226 and 10.18.10.4276, builded with Intel® Media SDK 2016.

Can you try Intel® Media SDK 2016 ? Let me know if the issue still happen on your end.

Please rebuild your test program with Intel® Media SDK 2016.

Thanks

Zachary

Dave_S_3 · ‎11-30-2015

Hi Zachary, we're already using the media sdk you referenced (2016). I don't believe we need the sdk dll (libmfxsw32.dll) for this test (?) but we are using the libmfx.lib for sure. We're only using 32-bit, never 64. The lib from the SDK I downloaded on 11/20/2015 has these specifics:

11/05/2015 05:20 PM 777,502 libmfx.lib

And when I put it into a 7zip archive it gives me a CRC of 2c54da6a. I've also attached it.

On our end we're going to try the very same test with a different platform.

Dave

Stern__Jason · ‎12-15-2015

Platform: Intel Core i5-3610ME @ 2.7GHz running both a dedicated Intel HD4000 and a dedicated AMD Radeon E6760 GPU running Windows 7 Embedded (x64).

The test: Modified the 32-bit version of the example project to do this in a never-ending loop:

Instantiate the Intel h.264 decoder.
Open a movie.
Decode multiple frames.
Dispose of the Intel h.264 decoder

The result: A slight memory leak from each instantiated Intel h.264 decoder.

Using gflags/UMDH, the two most common stack traces that appear to leak are:

// Each log entry has the following syntax:                                 
//                                                                          
// + BYTES_DELTA (NEW_BYTES - OLD_BYTES) NEW_COUNT allocs BackTrace TRACEID 
// + COUNT_DELTA (NEW_COUNT - OLD_COUNT) BackTrace TRACEID allocations      
//     ... stack trace ...                                                  
//                                                                          
// where:                                                                   
//                                                                          
//     BYTES_DELTA - increase in bytes between before and after log         
//     NEW_BYTES - bytes in after log                                       
//     OLD_BYTES - bytes in before log                                      
//     COUNT_DELTA - increase in allocations between before and after log   
//     NEW_COUNT - number of allocations in after log                       
//     OLD_COUNT - number of allocations in before log                      
//     TRACEID - decimal index of the stack trace in the trace database     
//         (can be used to search for allocation instances in the original  
//         UMDH logs).                                                      
// 

+    e6dc ( 9314b5c - 9306480)  7d825 allocs    BackTrace103939C
+      c5 ( 7d825 - 7d760) BackTrace103939C     allocations

       ntdll!RtlUlonglongByteSwap+00000B69
       <no module>!???+00000000 : 6B65D1E5
       <no module>!???+00000000 : 6B65D3FF
       atiumdag!XdxInitXopServices+004E7D5C
       atiumdag!XdxInitXopServices+004E52A7
       atiumdag!XdxInitXopServices+004CD2BA
       atiumdag!XdxInitXopServices+004C80FD
       atiumdag!XdxInitXopServices+004258A4
       atiumdag!XdxInitXopServices+003BC8E6
       IGT264Decoder!MFXVideoDECODE::Init+00000017 (d:\bronx\unity\tools\igt264decoderdll\ext\inc\intel\mfxvideo++.h, 111)
       IGT264Decoder!CDecodingPipeline::Init+000003C0 (d:\bronx\unity\tools\igt264decoderdll\src\intel\pipeline_decode.cpp, 168)
       IGT264Decoder!TIGT264IntelDecoder::Init+000000DD (d:\bronx\unity\tools\igt264decoderdll\src\igt264decoderinterface.cpp, 1429)
       IGT264Decoder!IGT264DecoderInterface::Init+00000355 (d:\bronx\unity\tools\igt264decoderdll\src\igt264decoderinterface.cpp, 2185)
       DecoderTest!TDecoder::Init+00000030 (d:\bronx\unity\tools\igt264decoderdll\src\decodertest.cpp, 174)
       DecoderTest!main+00000098 (d:\bronx\unity\tools\igt264decoderdll\src\decodertest.cpp, 282)
       DecoderTest!__tmainCRTStartup+00000122 (f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, 555)
       kernel32!BaseThreadInitThunk+00000012
       ntdll!RtlInitializeExceptionChain+00000063
       ntdll!RtlInitializeExceptionChain+00000036

And:

+    e5b0 ( 9314a30 - 9306480)  7d824 allocs    BackTrace11498A8
+      c4 ( 7d824 - 7d760) BackTrace11498A8     allocations

       ntdll!RtlUlonglongByteSwap+00000B69
       libmfxhw32!MFXVideoVPP_GetVPPStat+0030C935
       libmfxhw32!MFXVideoVPP_GetVPPStat+0030CB4F
       libmfxhw32!MFXVideoVPP_GetVPPStat+0012538C
       libmfxhw32!MFXVideoVPP_GetVPPStat+001228D7
       libmfxhw32!MFXVideoVPP_GetVPPStat+0010A8EA
       libmfxhw32!MFXVideoVPP_GetVPPStat+0010572D
       libmfxhw32!MFXVideoVPP_GetVPPStat+00062ED4
       libmfxhw32!MFXVideoDECODE_Init+00000156
       IGT264Decoder!MFXVideoDECODE::Init+00000017 (d:\bronx\unity\tools\igt264decoderdll\ext\inc\intel\mfxvideo++.h, 111)
       IGT264Decoder!CDecodingPipeline::Init+000003C0 (d:\bronx\unity\tools\igt264decoderdll\src\intel\pipeline_decode.cpp, 168)
       IGT264Decoder!TIGT264IntelDecoder::Init+000000DD (d:\bronx\unity\tools\igt264decoderdll\src\igt264decoderinterface.cpp, 1429)
       IGT264Decoder!IGT264DecoderInterface::Init+00000355 (d:\bronx\unity\tools\igt264decoderdll\src\igt264decoderinterface.cpp, 2185)
       DecoderTest!TDecoder::Init+00000030 (d:\bronx\unity\tools\igt264decoderdll\src\decodertest.cpp, 174)
       DecoderTest!main+00000098 (d:\bronx\unity\tools\igt264decoderdll\src\decodertest.cpp, 282)
       DecoderTest!__tmainCRTStartup+00000122 (f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, 555)
       kernel32!BaseThreadInitThunk+00000012
       ntdll!RtlInitializeExceptionChain+00000063
       ntdll!RtlInitializeExceptionChain+00000036

So it looks like there is a small leak on Intel’s side (stack trace #2), and then something is going on inside of the Media SDK that invokes AMD’s video driver instead of Intel’s, which looks like it might be causing a leak (stack trace #1).

Harshdeep_B_Intel · ‎12-15-2015

Hello Jason,

Thank you for detailed description of the issue. With every driver release supports 2 hardware generations (current and previous). Current is Skylake (6th gen) and previous is Broadwell (5th gen) along with Haswell (4th gen) Win10 support. You are using i5-3610ME (IvyBridge/3rd gen) processor which is three generations old. This is one of known issue in graphics driver for this platform and unfortunately we have limited support on 3rd gen and could take longer turn around time for fix in driver. Hence, to resolve this issue, I suggest following pointers 1) Workaround it in your application or 2) Upgrading to latest hardware.

Any further questions please start a new thread on Media forum - https://software.intel.com/en-us/forums/intel-media-sdk, it will be easier for us to track and respond.

Thanks,

Stern__Jason · ‎01-06-2016

Thanks, Harsh.

The Intel-specific leak is small enough that it likely would not have been caught had it not been for a larger leak in AMD's video driver when instantiating DirectX 9 instances. Ideally, Intel's Media SDK should iterate through all of the available adapters and select the one that maps to the Intel GPU when instantiating the DirectX 9 instance:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb147355(v=vs.85).aspx

This would eliminate issues caused by AMD or nVidia's drivers on multi-GPU environments, and seems like it should be a fairly straight-forward fix. But should that not be an option, is there any chance that Intel's Media SDK could be refactored such that there is a way where it only creates a single static DirectX instance throughout the library's lifetime? While that would not fix the underlying issue, it would prevent it from occurring multiple times throughout the application's lifetime.

Thanks,

Jason

Harshdeep_B_Intel · ‎01-06-2016

Hi Jason,

Thank you for your input and feedback, will pass it along to the team. In regard to the memory leak, I want to assure you concerned team is looking into issue and will be fixing this leak in decoder. But again as I mentioned above due to limited support,turnaround time for fix could be longer. Thank you for understanding.

Thanks,

Memory leak?