openframeworks / openFrameworks

openFrameworks is a community-developed cross platform toolkit for creative coding in C++.
http://openframeworks.cc
Other
9.97k stars 2.55k forks source link

ofVideoPlayer on Raspberry Pi remains in memory after destruction #4891

Open kr15h opened 8 years ago

kr15h commented 8 years ago

I am building an application for the Pi where I create a new video player and destroy the old one every now and then. Even though I am destroying the previous video player the memory usage keeps growing.

Here is the create code:

_video = new ofVideoPlayer();
_video->load(fileName);
_video->setLoopState(OF_LOOP_NORMAL);
_video->play();

Destroy code in the destructor:

_video->stop();
_video->close();
delete _video;
kr15h commented 8 years ago

Before loading the video used memory is was 66MB. After loading the video the memory was 77MB. After unloading the video, the used memory drops only by 4 MB, it goes back to 73MB.

bakercp commented 8 years ago

Does anything change if you don't use new and delete.

If _video is a member var, you shouldn't need to create it on the heap using new since we have the load() function, etc.

kr15h commented 8 years ago

I just changed the code to to have two ofVideoPlayer as member variables. Not using new and delete now, only close() and load(). The problem still persists, on Mac and RPi.

kr15h commented 8 years ago

In 10 minutes the memory usage went up from 56 MB to 101MB by loading and unloading a video approximately once per minute.

kr15h commented 8 years ago

And you can find the full code here: https://github.com/fablabberlin/infoScreen

kr15h commented 8 years ago

Here is a comparison. Memory usage during 10 min uptime increases by 38MB.

Before

before

After

after

arturoc commented 8 years ago

i'm testing on linux desktop (don't have a PI at hand right now) and it's completely stable. usually when the application starts and loads the video memory usage can grow for a while and never go back to the exact number it allocated, gstreamer seems to allocate some memory that it keeps allocated as long as you are using it but other than that it stays stable for me at between 33 - 35 Mb with the fingers video from the player example.

can you post a small example that leaks memory for you?

kr15h commented 8 years ago

I will do an additional test on the Raspberry Pi. Behold.

kr15h commented 8 years ago

OK. Made a test with loading and unloading two videos. Git repository HERE. In the main branch I allocate video players on the heap. In the test-stack branch I use the same video player for loading and unloading.

kr15h commented 8 years ago

In the heap case on the Raspberry Pi the memory usage increased from 61MB to 222MB in ~2.5 minutes.

kr15h commented 8 years ago

The same with the stack allocation. From 61MB to 191MB in ~2.5 minutes.

The memory keeps growing also when running the examples on Mac. I wonder whether the same problem persists if I use ofxOMXPlayer on the Pi. Will try later.

kr15h commented 8 years ago

Here are some images.

Heap allocation

screen shot 2016-02-23 at 00 15 08 screen shot 2016-02-23 at 00 17 47

Stack allocation

screen shot 2016-02-23 at 00 33 58 screen shot 2016-02-23 at 00 36 31

Forgot that it is still running.. And then.

screen shot 2016-02-23 at 00 42 58

And now the Pi starts to behave strange. Video freezes in the middle etc.

screen shot 2016-02-23 at 00 47 57

And it crashed once the swap memory got filled up.

kr15h commented 8 years ago

Replaced ofVideoPlayer with ofxOMXPlayer and the application does not eat memory anymore.

arturoc commented 8 years ago

just tested this and i'm not seen any leak after half an hour running, it might be that some internal buffer in gstreamer is growing because it can't keep up. something to take into account when using the normal video player in linux is to use native pixels format before loading so there's no color space conversion in the cpu.

anyway, i'll try to reproduce this at some point but i'm going to move it back to 0.10