Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

QTCaptureSession stopRunning order dependence

I've found something quite odd about QTCaptureSession. My app is a Java app using native methods (JNI) to access QuickTime. On Leopard the current JVM (1.5) is normally run as a 32-bit process (although it can be run as 64-bit). The "new" JVM (1.6) is 64-bit only, but is not yet the default JVM, although Apple is expected to make it the default relatively soon. As a result, I need to build my native library to run in both 32-bit and 64-bit processes. I wrote an Objective-C class to manage the process, it has instance variables for the QTCaptureSession, QTCaptureInput, QTCaptureVideoPreviewOutput, and a buffer where I blit frame data to in my captureOutput:didOutputVideoFrame:withSampleBuffer:fromConnection delegate method.

I have found that QTCaptureSession stopRunning has some odd behaviour when run in 32-bit mode only. Specifically, I have found that when:
- the QTCaptureDevice is a UVC camera, and
- the code is run in a 32-bit process, and
- the device is the input of a running QTCaptureSession, and
- my code calls stopRunning before removing the session input, and
- I later restart the session (after adding an input back in)
frame data being fed to my output delegate method arrives very slowly -- it is like the frames are still being captured at 30 FPS, but I'm getting them initially at about 3-5 FPS, but quickly dropping off to less than 1 FPS. After about 15-30 seconds of this the rate recovers, but it remains behind by the time spent in this odd mode. I found that even if I removed everything from the session, closed the input device and released all the QTKit objects, and created a new session, input and output, it still exhibited the same odd behaviour. The FireWire iSight does not exhibit this behaviour, only UVC cameras (and all 4 UVC cameras I tried behaved the same). I found that unplugging the UVC camera and plugging it back in caused a QTCaptureSession that had been exhibiting this behaviour to behave as if the QTCaptureSession had never been opened, but after stopping the QTCaptureSession and restarting it (i.e. stopRunning, removeInput, wait, addInput, startRunning) the dropped back to a crawl again.

Changing my code to remove the input before stopping the session rectified the issue, i.e.:
[session stopSession];
[session removeInput:input];
[[input device] close];
[input release];
input = nil;

exhibits the problem, but:
    [session removeInput:input];
    [[input device] close];
    [input release];
    input = nil;
    [session stopSession];

does not exhibit the problem. Is this order dependence expected? And why do 32-bit and 64-bit processes differ in this regard?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-API mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quicktime-api/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.