Memory management about ofxhapplayer

[bangnoise]

Using the code in your OF forum post I can't recreate the problem (it works for me) - although you don't provide your header so I can't tell how you're setting up the array of ofxHapPlayers.

The movies all start playing when you call .play() (obviously) so maybe the second and third have finished by the time the first finishes?

[bangnoise]

To answer your question though, you can't load a lot of movies at once - they each have video memory associated with them. I guess it might be useful to have a method to clear the texture resource but keep the movie loaded.

[dmelladom]

Hi! Thanks for your answer.
The problem that I am facing is the following:

1. Create an array, lets say of 10 positions, of ofxHapPlayer
2. In setup, inside a for loop, load a clip in each position and play it (maybe that's the first mistake)
3. In update, update only a portion of the clips in the array, let's say only the first one, becouse I want to play that clip first and once it is over, play the others
4. In draw, draw that clip
5. Loop 3) and 4) until first clip is over and then try to play the second clip
   -> Then, that clip at [1] of the array is not available.
   I thought that calling play do not totally play the clip, it has to be updated and drawn to play each frame.

The solution I am using is a dinamyc array of pointers. I can load a hundred clips and make different size vectors/arrays of pointers that play them. That works OK, I am playing around 40 clips at the same time from a pool of 100 clips. I am testing now to wait and call play only one the clip is going to be played, which looks like it will work, as suggested in that OF forum post.
In that case, why there is an play and update methods? Which is the propouse of two different method to play? Adapt it to OF idiosyncrasy?

In addition, when you call loadMovie, it looks like only part of the clip is loaded into memory and each time you call to update, another fraction is loaded. Only when you call close method, that memory is freed

[bangnoise]

You misunderstand play() and update().

play() gives the command, once, to start playing, and immediately does so according to the loop, rate, etc settings. If one second later you ask for the current frame, you will get the frame one second into the movie.

update() tells the player that if it needs to, it can do any internal work required to manage playback. Calling it or not is up to you - if you don't call it, then any work needed may be deferred until you perform other actions on the movie. It is good practice to call it in your ofApp::update() function for every player, regardless of play/loaded state.

I'm going to close this issue because it sounds like things are working as they should, but continue to comment if you have any further questions.

[dmelladom]

Thanks a lot Tom!
I would like to say that I am having amazing results using your
implementation of the HAP codec. I guess that by this time there is no
64bits version planned since QT is still 32bits, but that would be great.
I want to thank you your support and code. Is there any way I could promote
your coding? Unfortunatelly, there is no money I could use, but if you can
think of anything, let me know.
Best,
Diego

2015-02-11 11:30 GMT+01:00 Tom Butterworth [email protected]:

You misunderstand play() and update().

play() gives the command, once, to start playing, and immediately does so
according to the loop, rate, etc settings. If one second later you ask for
the current frame, you will get the frame one second into the movie.

update() tells the player that if it needs to, it can do any internal
work required to manage playback. Calling it or not is up to you - if you
don't call it, then any work needed may be deferred until you perform other
actions on the movie. It is good practice to call it in your
ofApp::update() function for every player, regardless of play/loaded
state.

I'm going to close this issue because it sounds like things are working as
they should, but continue to comment if you have any further questions.

—
Reply to this email directly or view it on GitHub
#5 (comment)
.