- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page