I am creating a C ++ library for use in iOS (yes, unfortunately, it must be C ++) that uses AVCaptureSession to capture video frames that are delivered via the captureOutput callback. The C ++ library is my final product. I have a cocoa touch app for testing / demo. So it looks like this:
(test application) <-----> (C ++ lib (AVFoundation callbacks))
The test application has user interface controls and is responsible for almost all graphics. The C ++ library maps frames to a UIView through OpenGL.
Are you with me? Good
Well, firstly, the user clicks on UIButton, which makes a call to my library. This call takes 10 seconds or more. Therefore, if I put a call directly behind the button, the user interface will be blocked until the library function returns:
-(IBAction)hBut:(id)sender{
[myLib foo];
}
This is not good. The next thing I tried is to create a thread to call lib:
-(void)callIntoLib{
[myLib foo];
}
-(IBAction)hBut:(id)sender{
[NSThread detach..:myLib selector:foo object:nil];
}
This no longer blocks the user interface, but now the video frame callback function never fires (AVCaptureSession captureOutput). It seems that the main NSRunLoop is blocked.
Then I tried the same thing, but with Grand Central Dispatch:
-(IBAction)hBut:(id)sender{
_myQueue = dispatch_queue_create("com.domain.me", NULL);
dispatch_async(_myQueue,
^{
[myLib foo];
});
}
This has the same behavior. That is, the callback for the video frames does not work. Lame
Why is the main NSRunLoop blocked in the second and third cases? Is there any way to associate queues with it?
It makes sense?