ofQtVideoPlayer & closeMovie()

I hope I put my question into the right department.

If I try to close a movie with closeMovie() the program crashes and the Xcode debugger gives me this: 0x9489b038 <+0072> lbz r0,228(r2)
I don’t know if it’s much help for you.



thanks for posting that!

I’ll look into it and let you know.
We don’t use closeMovie very often so that’s prob why we didn’t notice it!


Hey Monkee,

So I tested it out and the same thing happened to me when I closed the movie in the movieGrabberExample.

The problem is that once we close the movie we should not call movie.idle(), movie.getpixels() or movie.draw() anymore as the movie no longer exists so the app crashes.

If you use closeMovie you should also do something where you change a bool value at the same time.


isMovieOpen = false;  
Then in update and draw etc  
if(isMovieOpen) movie.idle();  
if(isMovieOpen) movie.draw(0, 0);  

That way once you have close you movie you stop calling its functions.

But we will update the videoPlayer so that it behaves a little more gracefully in these sorts of situations.


i have another problem: after a loadMovie and a subsequent closeMovie i want to load another movie using loadMovie into the object, but i get an access violation at:

openFrameworksApp.exe!ofVideoPlayer::loadMovie(char * name=0x004a4868) Line 155 + 0x1b bytes C++

did you ever consider re-using the object?

sorry for these questions, it’s maybe better if i just start digging into the OF code myself and propose changes…

no - don’t worry… that’s *exactly* what we need to hear about as we develop the code.

we have made alot of changes to the video player from the 0.02 release version and I think that they address many of the concerns you have. We’ll test it out a bit and get it into the SVN so you can try it too, and we will try to get the next release out soon too …

thanks !

Hey Mieg,

No problem! Thanks for letting us know!
Actually the videoPlayer will have a major overhall for the next version! It will be faster, more memory effecient etc and we will make sure that this issue is fixed as well. It certainly should be able to load another movie after the first one is closed.

Once we have the fix in the svn we will send you the changes so you can use it before the release.


I have similar problems. My OF application needs to loads quickly a movie after a movie (same way than here: I did try with different Codecs (DV/Sorenson/Mpg4) but I always got the same problem: a dirty black frame before movie starts - and it take a long time 'till the new movie starts to play (almost a second…). Do you think it would improve in the new release? Or should I do something else with my code?

Thanks a lot,

PD/ This is the script I’m using to update():

char *p;


case 0:
v = videoDeque[0];
p = &v[0];

case 5:
v = videoDeque[1];
p = &v[0];

case 10:
v = videoDeque[2];
p = &v[0];

case 15:
sec = 0;

}//end switch

Yeah this is something we encountered when working on the Liners performance (Especially on a mac) as a result zach hacked together some code that treated the file more like a stream of data, which greatly reduced the load times of each movie. This will make it into the next release in a much cleaner state.

For now instead of loading each movie when it is needed think about creating a bunch of movie objects and loading them all at the start and then just toggling which is is being idled and displayed.


Thanks for your answer. If you want me to test the new release with different compression settings-codec-etc I will be happy to do that - I use to work with video-syntagmas articulated by algorithms.

Cool - will do. As soon as it is in svn I will post the link.


we are still working on it, but there is a new version of ofVideoPlayer here:


you can download the files here:


the biggest change is that there is a “play()” command and an “stop()” command - movies don’t automatically play when you load them. When they play, they will use their speed and position properties better so that there should be less delay when they start. Also, there should be fixes for the bugs mentioned:

a) reloading new quicktimes in the same videoPlayer object
b) black frame at the start

as for the delay on loading, I think this is really an issue with quicktime and the type of movie it is, but we have code in liners for using a thread to load (so that the app doesn’t hang too long). We can take alook at posting that somewhere for you if you need it.

can you try this code out (maybe make a new 0.02 folder “0.02b” libs and apps so that you don’t break your other apps) and let us know if it helps with any of the issues?


hi zach,
i tried the new videoplayer but i think more is changed. my compiler is complaining about line 68 of ofVideoPlayer.h:

syntax error: identifier ‘string’

can you send me the file where your definition of ‘string’ is?



after changing ‘string’ to ‘char *’ i also received the following errors:

Error 1 error C3861: ‘ofToDataPath’: identifier not found libs\openframeworks\video\ofvideoplayer.cpp 165

Error 2 error C2228: left of ‘.c_str’ must have class/struct/union libs\openframeworks\video\ofvideoplayer.cpp 187

where can i access the svn repository?

grtz - michael

Hey Mieg,

put in your ofConstants.h

using namespace std;

then for the video player you can just comment out that line that has ofToDataPath.

oh and also put it back to string (from char *)

yeah – the svn is kind of a moving target these days as we ramp up for 0.03. I have made some broader simplifications and corrections for the video code (try to also get ready to integrate the FOBs based linux player code), also good destructors, deallocation, etc.

thanks for being patient while things are changing and for the feedback!