Is hw transcode has memory leak in sample_multi_transcode？

[cheng_y_]

I'm using Media SDK(Media SDK 2013) for the H.264 transcode .

I modify the sample_multi_transcode.cpp like this (11.png) , 

int _tmain(int argc,TCHAR *argv[])
{
for(int i = 0 ; i < 10 ; i ++)
{
mfxStatus sts;
Launcher transcode;
sts = transcode.Init(argc,argv);
MSDK_CHECK_PARSE_RESULT(sts,MFX_ERR_NONE,1);

transcode.Run();
sts = transcode.ProcessResult();
MSDK_CHECK_RESULT(sts,MFX_ERR_NONE,1);
}

return 0; ---------------  break point ;
}

when I is use the cmd line "sample_multi_transcode.exe -sw -i::h264 1080P306M.h264 -o::h264 output2.h264 -w 320 -h 288 ", the 

sample_multi_transcode.exe virtual memory is ok ,about 150M. 

but use the cmd line         "sample_multi_transcode.exe -hw -i::h264 1080P306M.h264 -o::h264 output2.h264 -w 320 -h 288" ,the 

sample_multi_transcode.exe virtual memory is 1.2G(12.png) ! 

------------------ 

System Information 
------------------ 
Time of this report: 6/17/2013, 14:16:29 
       Machine name: USER-PC 
   Operating System: Windows 7 pro 32-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_rtm.101119-1850) 
           Language: Chinese (Simplified) (Regional Setting: Chinese (Simplified)) 
System Manufacturer: Dell Inc. 
       System Model: OptiPlex 790 
               BIOS: Default System BIOS 
          Processor: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (8 CPUs), ~3.4GHz 
             Memory: 4096MB RAM 
Available OS Memory: 3242MB RAM 
          Page File: 2835MB used, 3644MB available 
        Windows Dir: C:\Windows 
    DirectX Version: DirectX 11 
DX Setup Parameters: Not found 
   User DPI Setting: Using System DPI 
 System DPI Setting: 96 DPI (100 percent) 
    DWM DPI Scaling: Disabled 
     DxDiag Version: 6.01.7601.17514 32bit Unicode 

--------------- 
Display Devices 
--------------- 
          Card name: Intel(R) HD Graphics 
       Manufacturer: Intel Corporation 
          Chip type: Intel(R) HD Graphics Family 
           DAC type: Internal 
         Device Key: Enum\PCI\VEN_8086&DEV_0102&SUBSYS_04AD1028&REV_09 
     Display Memory: 1428 MB 
   Dedicated Memory: 64 MB 
      Shared Memory: 1364 MB 
       Current Mode: 1280 x 1024 (32 bit) (75Hz) 
      Monitor Model: LXB-L17C 
         Monitor Id: LEN0901 
        Native Mode: 1280 x 1024(p) (75.025Hz) 
        Output Type: HD15 
        Driver Name: igdumd32.dll,igd10umd32.dll,igd10umd32.dll 
Driver File Version: 9.17.0010.3062 (English) 
     Driver Version: 9.17.10.3062 
        DDI Version: 10.1 
       Driver Model: WDDM 1.1 
  Driver Attributes: Final Retail 
   Driver Date/Size: 3/8/2013 19:10:10, 11049472 bytes 
        WHQL Logo'd: Yes 
    WHQL Date Stamp: 
  Device Identifier: {D7B78E66-4242-11CF-6E78-A724B7C2C435} 
          Vendor ID: 0x8086 
          Device ID: 0x0102 
          SubSys ID: 0x04AD1028 
        Revision ID: 0x0009 
 Driver Strong Name: oem20.inf:Intel.Mfg:iSNBD0:9.17.10.3062:pci\ven_8086&dev_0102 

[Petter_L_Intel]

Hi,

The title of the forum post indicates that you are observing a memory leak, but the following details you provide does not mention leak but instead total consumed memory when running your workload.   Can you expand on what you mean by memory leak?

Regarding total memory usage. HW accelerated codecs are expected to consume more memory than SW codecs, especially if using system memory to store surfaces.

However, I would not recommend using "virtual memory" as your metric since it is misleading. Instead please, use metric such as "private bytes" or similar. It will give you a more accurate representation of the true size of the allocated memory.

Regards,
Petter 

[cheng_y_]

Thanks for your response.

 the codes:

{ 

mfxStatus sts;

 Launcher transcode;

 sts = transcode.Init(argc,argv);

MSDK_CHECK_PARSE_RESULT(sts,MFX_ERR_NONE,1);

 transcode.Run();

sts = transcode.ProcessResult();

MSDK_CHECK_RESULT(sts,MFX_ERR_NONE,1);

}

 leak 70M memory everytime when using the "-hw" cmd line ,and I use the "for(...)" keyword , making the private bytes grow up to 1.0G .

 then I debug the Pipeline_transcode.cpp , m_pmfxDEC->Close() and m_pmfxENC->Close() not free the memory which the Init(...) malloc.

 ------------------------------------------------------------------------------------------------------------------------------------

 void CTranscodingPipeline::Close()

{

 if (m_pmfxDEC.get())

 m_pmfxDEC->Close();

if (m_pmfxENC.get())

m_pmfxENC->Close();

if (m_pmfxVPP.get())

m_pmfxVPP->Close();

 FreeVppDoNotUse();

FreeMVCSeqDesc();

m_EncExtParams.clear();

 m_DecExtParams.clear();

m_VppExtParams.clear();

 if (m_bIsJoinSession)

 {

//m_pmfxSession->DisjoinSession()

; m_bIsJoinSession = false;

} // free allocated surfaces AFTER closing components

FreeFrames();

m_bIsInit = false;

} // void CTranscodingPipeline::Close()

[Petter_L_Intel]

Hi Cheng,

thanks for providing further details. Your use case is clear to us now.

I can confirm the memory leak. It turns out that the decoder resources are not freed at session destruction, as would be expected.

We are working on finding the root cause for the issue and will keep you updated as soon as we have more info to share.

Thanks for helping us make the Intel Media SDK better.

BTW. In the meantime, there is an alternate Media SDK opaque transcode sample as part of the Media SDK tutorial (http://software.intel.com/en-us/articles/intel-media-sdk-tutorial). This sample does not showcase the memory leak you have observed.

Regards,
Petter 

[cheng_y_]

Thanks.

My project transcode 1080P h264 video to cif h264 video ,so I must use the vppresize

 however this issue still exist in "simple_5_transcode_opaque - async - vppresize" sample .

The issue is blocking my product release, I need your help,Could you fix it ASAP? 

 Thanks a lot.

[Petter_L_Intel]

Hi Cheng,

sorry to hear that this issue is blocking product release. We are working on resolving the issue as soon as possible.

I can confirm that the issue occurs using the tutorial sample you refer to. Thanks for making us aware of this.

Just a heads up. The issue may turn out to be related to 15.28 graphics driver branch (required for your 2nd generation Core Processor) which is rarely updated, so if this is the case a fix may involve quite long wait. We'll determine if this is the case shortly.

The issue is connected to the "opaque" memory use case. A workaround is to explicitly use D3D memory surfaces instead. Not sure if this is feasible for your application, but I strongly suggest you explore this path as a backup.

Regards,
Petter 

[cheng_y_]

thank you very much !