system: win8.1 x64
hardware: i5-6400 2.7GHZ HD Graphics 530
video driver: 18.104.22.16863
Intel Media Sdk and 265 plugin: MediaServerStudioProfessionalEvaluation2016
demo: sample_multi_transcode of Intel Media SDK Samples 2016 22.214.171.124
I'm used this demo for 265 to 264 transcoding, I'm setting HW and used api 1.19. I have used transcoding for 15 hours and four tasks togethor, it makes the memory increase 1.3G. then, if I call the delete all of the CTranscodingPipeline objects, the memory will reduce to more than 60MB.
I also tried to use this demo for 264 to 264 transcoding,but the result is same as above..
I have similar issue with 2 more customers who are seeing memory leak, see here - https://software.intel.com/en-us/forums/intel-media-sdk/topic/670446
So far I have not been able to reproduce the issue. Can you please send the cmd line and snapshot of the memory leak - memory at start of the session, at mid some point and before the session ends.
Thank you for your replay,I have upload tow pictures to the baidu cloud, url:http://yun.baidu.com/share/link?shareid=702743705&uk=3627248114#render-type=grid-view, I'm not sure you can see it, but if you can see it, you can find the memory increase 250MB in 1.5hours through system time.
My transcodes cmd is : -par aa.par -p 1.perf
the aa.par file content:
-i::h265 output0.h265 -o::h264 output0.h264 -f 30 -gop_size 30 -dist 1 -hw
-i::h265 output1.h265 -o::h264 output1.h264 -f 30 -gop_size 30 -dist 1 -hw
-i::h265 output2.h265 -o::h264 output2.h264 -f 30 -gop_size 30 -dist 1 -hw
-i::h265 output3.h265 -o::h264 output3.h264 -f 30 -gop_size 30 -dist 1 -hw
the source of sample_multi_transcode.exe, I hava changed two places.
1、file: sample_utils.cpp function: mfxStatus CSmplBitstreamWriter::WriteNextFrame(mfxBitstream *pMfxBitstream, bool isPrint)
//nBytesWritten = (mfxU32)fwrite(pMfxBitstream->Data + pMfxBitstream->DataOffset, 1, pMfxBitstream->DataLength, m_fSource);
//MSDK_CHECK_NOT_EQUAL(nBytesWritten, pMfxBitstream->DataLength, MFX_ERR_UNDEFINED_BEHAVIOR);
I modify it to make sure enough disk space
function:mfxStatus CSmplBitstreamReader::ReadNextFrame(mfxBitstream *pBS)
We were able to reproduce the issue at our end, thanks for sending the reproducer. Discussing this with the driver team and we are able to see improvements in the next driver release on limited scenarios. Will update as we make progress.