ofQTKitPlayer crash with ofxCocoaWindow

[ascorbin]

always after a while this crashes:

//--------------------------------------------------------------
void testApp::setup() {

mov.loadMovie("movies/#4.6.mov", OF_QTKIT_DECODE_TEXTURE_ONLY);
mov.play();
}

//--------------------------------------------------------------
void testApp::update() {

mov.update();

mov.setPosition(ofRandom(1.0));
}

//--------------------------------------------------------------
void testApp::draw() {

mov.draw(20, 20, 320, 160);
}

a multithread/openGL problem?

[obviousjim]

I've noticed sometimes that with ofxCocoa update will get called before
before setup finishes executing.

Perhaps flag bSetupFinished or check mov.isLoaded() in update and see if
that helps?

On Saturday, December 29, 2012, Owi Mahn wrote:

always after a while this crashes:

//--------------------------------------------------------------
void testApp::setup() {

mov.loadMovie("movies/#4https://github.com/openframeworks/openFrameworks/issues/4.6.mov",
OF_QTKIT_DECODE_TEXTURE_ONLY);
mov.play();
}

//--------------------------------------------------------------
void testApp::update() {

mov.update();

mov.setPosition(ofRandom(1.0));
}

//--------------------------------------------------------------
void testApp::draw() {

mov.draw(20, 20, 320, 160);
}

a multithread/openGL problem?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1778.

• James

[ascorbin]

hm, apple says (1) allocate all QTMovie objects on the main thread. (http://developer.apple.com/library/mac/#technotes/tn2138/_index.html)
but with ofxCocoa which one is the main thread? it seems that the movies are attached to the CVDisplayLink-Thread...
how to allocate them ? ...

[ascorbin]

must be somewhere here (but im too stupid for that...) http://developer.apple.com/library/mac/#technotes/tn2138/_index.html:
Using QTMovie objects on background threads?

Q:

I just read the article TN2125: Thread-safe programming in QuickTime , but it doesn't say anything about QTKit. How do I safely use QTMovie objects on a background thread?

A:

Observe the following guidelines when working with QTMovie objects on background threads:

(1) allocate all QTMovie objects on the main thread.

The reason for this is quite simple: a QTMovie is always associated with a movie controller component instance, and currently no movie controller components are thread-safe. While a non-nil QTMovie can indeed be created on a background thread, the associated movie controller will always be NULL. This by itself is not fatal; many operations can be performed on a QTMovie object that has been initialized on a background thread. But certain operations will not work correctly, including most all of the notifications and even asynchronous movie-loading. That's why allocating a QTMovie on a background thread is not advised.

(2) if you want to operate on a QTMovie on a different thread, detach it from the current thread using the Movie Toolbox C API DetachMovieFromCurrentThread (on the QuickTime movie associated with that QTMovie as gotten with the quickTimeMovie: method); then attach it to the different thread using AttachMovieToCurrentThread. Also, to workaround a bug in QTKit we recommend you call the private method setIdling: here to make sure the movie is not tasked on a background thread.

(3) call EnterMoviesOnThread before you make any other QuickTime or QTKit calls on a secondary thread.

(4) call ExitMoviesOnThread before exiting a thread you have made QuickTIme calls on.

(5) be prepared to handle errors from any of those calls; some movies cannot be moved to secondary threads (this is codec specific).

QTKit does not do any of this automatically for you, but we are working on some new APIs that will perhaps make this process easier (or at least more Cocoa-like).

Here's a short code snippet showing how to perform a movie export on a background thread:

• (void)doExportOnThread:(QTMovie *)movie
  {
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

  EnterMoviesOnThread(0);
  AttachMovieToCurrentThread([movie quickTimeMovie]);

  // To workaround a bug in QTKit we need to call the private
  // method setIdling: to make sure the movie is not tasked on
  // a background thread
  if ([movie respondsToSelector:@selector(setIdling:)])
  [movie setIdling:NO];

  // do export
  [movie writeToFile:....];

  DetachMovieFromCurrentThread([movie quickTimeMovie]);
  ExitMoviesOnThread();

  [pool release];
  }

[ascorbin]

ok, i have found something: it works solid with NSTimer instead of CVDisplayLink, but animation isn't so nicely fluid, maybe a combination of both or let CVDisplayLink trigger the main thread, next days i post some code...
greetings ascorbin

[ascorbin]

yey SOLVED: https://github.com/ascorbin/ofxCocoaWindow

gretings

[obviousjim]

Great! i am curious if there is a performance hit with this.

@julapy what do you think about pulling this into the main ofxCocoaWindow?

On Mon, Dec 31, 2012 at 12:10 AM, Owi Mahn [email protected] wrote:

yey SOLVED: https://github.com/ascorbin/ofxCocoaWindow

gretings

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1778#issuecomment-11773845.

• James

[julapy]

it sounds to me like a similar issue that ive seen on iOS, where the CVDisplayLink was causing a bunch of issues but is working fine with NSTimer...
im away on holidays atm but will review this next week when I get back.

[kylemcdonald]

Because QTKit and QuickTime are deprecated by Apple as of 10.9, we are focusing on AVF. Follow #2283 for developments. Remaining QTKit and QuickTime-specific issues will be closed with wont-fix, but bugfix PRs will be accepted.