Allocating and Releasing Videos

Hi guys,
Currently I am working on an installation, where I have couple of scenes, using different video material. I know that loading all videos in separate instance will take a lot of texture memory and may be won’t be enough. So I have build a Video pool (vector<ofVideoPlayer*>) where I have 5 slots and every time I change scenes, I load every scene videos again. I noticed that calling “allocate” on a texture, will actually destroy it first, if it’s allocated, so that should work for the videos too.

Everything is working for now, although I still have to do some more testing, but do you guys know any other way to do this?

Thanks,
Kamen

hi, kamend just iterate through your pool and call the destractor of each video !!
this releases the dynamically allocated memory, if you just say clear() or allocate it doesn’t release the actual object …especially if you use a vector of dynamically allocated objects instead of just automatic…

So do something like:

  
 vector<ofVideoPlayer*>::iterator its;  
    for(its = videos.begin(); its != videos.end(); its++){  
          
        (*its)->~ofVideoPlayer();  
            videos.erase(its);  
            break;  
                  
    }  
  

and if you want to delete a specific video, just extend the ofVideoplayer object add a boolean that if is true when the situation you want to delete the specific video occurs delete the video!

like something:

  
  
 vector<ofVideoPlayer*>::iterator its;  
    for(its = videos.begin(); its != videos.end(); its++){  
        if ((*its)->marked){  
        (*its)->~ofVideoPlayer();  
            videos.erase(its);  
            break;  
                }//ifmarked  
    }  
  
  
  

and ofcourse to add new videos:

  
  
ofVideoPlayer *vid = new ofVideoPlayer;  
    vid->loadMovie("m.mov");  
    vid->play();  
    //vid->marked=false;  
    videos.push_back(vid);  
  

Hi,
I figured out that I do not need to erase the objects, but just reuse them. Calling “loadMovie” does call “allocate” of the texture and, the texture gets cleared in the “allocate” block, before being initialized again.

That’s from ofTexture.cpp

  
  
void ofTexture::allocate(int w, int h, int internalGlDataType, bool bUseARBExtention){  
...  
// attempt to free the previous bound texture, if we can:  
clear();  
...  
  

Anyway, I tested the installation for around 10 hours with more then 200-300 scene transitions, using this method and everything is stable, so I guess there is no memory leaks.

yes ofcourse, it has minor memory leaks but it will never crash, I was confused because I thought you wanted to call the clear() function from the texture baseclass that is a private function and then delete the object.
it is worth to mention that you don’t really need a dynamically allocated vector of ofVideoplayer objects. (a memory pool) because you don’t really use the heap so, it’s better if you just declare them normally (in the stack) because then you will create a memory leak at the end of the program …when you close everything down… (it doesn’t really matter though -worst case scenario you will crash your pc)… you just need a static array of videoplayer objects… not a dynamic array , an array that is able to change size by deleting objects from it is not really needed here… but hey - it will do the job anyway!

I wish you the best of luck with your installation!!

oops, I guess that make sense :slight_smile: switched to static arrays. Thanks for the tip!

Hey all,
I just did a project where I needed a different video to play each scene as well, on OSX there is a memory leak with the regular quick time based video player for re-using an ofVideoPlayer object (or there was when I was developing it), and even though it is a small leak I couldn’t have that happening. I ened up just loading ALL of the videos in setup and keeping them in memory. I thought it would have destroyed the computer but since only one is playing at a time it wasn’t that bad, and didn’t use as much memory as I was expecting. The transitions between scenes were also faster because I no longer had to load the movie each transition, it was already prepped and waiting to play.

Anecdotally, I had about 50 videos, all 1080p, and it worked just fine on an ancient 2006 MBP.

The memory leak is still there, but I don’t think it will crash the program that easily, we talk about bytes and some of them are not related with loading the file anyway. To be honest though fearing of those leaks in the past I as well chose to load 20 240p videos in the setup for a project just like Tim did.
But If I was to do the project again I would use the code that I posted. it might be leaking some bytes every now and then but the allocations remain stable. keep loading movies in the same object causes a crash in my computer anyways. so I can’t really tell if it leaks more…