decode memory leak

[mao_h_]

When I used the Intel Media SDK 2014 R2 tutorials, the "simple_decode" program showed some memory leak. But the "simple_encode" program didn't have this problem.

Then I debugged the "simple_decode" program. I found that the memory wasn't freed completely in the Release() function which would invoke the vaTerminate() and close() functions to destroy the VAAPI display handle and close the gfx card file descriptor respectively. But on the contrary, the "simple_encode" could free the memory completely with the same Release() function.

In order to demonstrate this, my test is as follows.
I modified the "simple_decode" program slightly to see whether the Release() function could free all the memory. I inserted a "MSDK_SLEEP()" statement before the Release() function so that I had time to see how much memory had been used before the Release() function. I also inserted a dead while loop statement after the Release() function so that I could see how much memory had been freed by the Release() function. This code is:

printf("begin to sleep\n");
MSDK_SLEEP(5000);

printf("begin to release\n");
Release();
printf("after release\n");

while(1){
    ;
}

return 0;

My system is Ubuntu 12.04. Before I run the modified "simple_decode", I used the "free" command to see the memory usage(the memory unit is KB). The result(we primarily focused on the used memory and cached memory) was:
                   total        used           free     shared      buffers     cached
Mem:     8072004     892964    7179040            0     152168     429692
-/+ buffers/cache:     311104     7760900
Swap:    1998844             0     1998844

Then the program begun to run. My shell command was "sudo ./simple_decode -hw input.h264". I didn't set the ouput because the YUV output could consume much memory and impact our observation. After the "printf("begin to sleep\n")" statement had been executed, I used "free" command. The result was :
                    total       used           free     shared      buffers     cached
Mem:     8072004     939784    7132220            0     152192     472812
-/+ buffers/cache:     314780    7757224
Swap:    1998844              0    1998844  

We can see that program used about 46MB memory including about 42MB cached memory.
Then After the "printf("after release\n")" statement had been executed, I also used the "free" command. The result was:
                  total         used           free     shared      buffers     cached
Mem:    8072004      938428    7133576            0     152192     471244
-/+ buffers/cache:     314992    7757012
Swap:   1998844               0    1998844

We can see that the Release() just freed about 1MB memory.
At last, I terminated the program by Ctrl + C. Then I used the "free" command again. The result was:
                  total         used           free     shared      buffers     cached
Mem:    8072004      892220    7179784            0     152204     429692
-/+ buffers/cache:     310324    7761680
Swap:   1998844               0    1998844

We can see that the memory had been freed completely as the process finished.

Then I got another test in which I did the decoding continuously. I used a while loop statement and after the Release() function had been executed I restarted the decoding procudure. I could found that the used memory became more and more.

My guess: The Release() function in the "simple_decode" doesn't release the VAAPI display handle. 
I verified it by restarted the new decoding after Release() function instead of returning and finishing the process. I found that the "m_va_dpy" variant (which indicating the VAAPI display handle)changed over time. But in the "simple_encode" program, this variant just changed once(when you run the second round encoding, the variant would change). So the memory leaked as this. And I think the leaked memory is mainly in the cached memory.

I had searched this problem in the forum. I found that some people had ever posted this issue. I don't know whether it had been fixed. If not, some workarounds are also appreciated.

[Harshdeep_B_Intel]

Hi,

Thank you for bringing this to our notice, we will investigate further into this issue. In meantime, these simple tutorials are provided as a starting point for understanding media pipeline to develop applications. We highly suggest to look into our samples provided in Intel Media SDK 2015 package, which are regularly updated and can be a solution for the memory leak . 

Thanks,

[mao_h_]

Hi, Harsh Jain

Thanks for your reply.

My tutorial is "mediasdk-tutorials-0.0.3" which is the same as the tutorial of the Intel® Media Server Studio 2015(https://software.intel.com/en-us/intel-media-server-studio-support/code-samples).

Today I also tested the samples(which were released on 07/23/2014) of the Media SDK 2014 R2 for Linux Servers(I don't have the Intel® Media Server Studio 2015). The result was the same that the decoding still had the memory leak problem. In fact, the "sample_decode_drm" program also needed the same VAAPI function, vaTerminate(), as the "simple_decode" program did.

I think if something goes wrong with the VAAPI when you are doing decoding, then the samples of Intel® Media Server Studio 2015 may also has this problem. You may have a test in which you can use a while loop statement to decode repeatedly to see whether the memory would inclease continuously even though you have invoked the Release() function every time.

Regards,

Mao