Leopard, BTV Pro, 1.1.2b1 and Equinox 6.7.2

[Steve Sisak]

Hi David,

You sum up one of my current dilemmas well....

At 2:10 PM -0500 3/5/08, David Bleser wrote:
>    Jeff Phillips confirmed the issue I brought up with the use of your
>webcam driver and Equinox 6.7.2 running under Leopard. There is no
>control of the webcam as your interface is not displayed. This is
>because Darryl from Microprojects has told us that Apple has not
>provided developers with API's to control third party webcams under OS X
>10.5.

I assume he means via the QTKit Capture API -- the Sequence Grabber 
APIs still work fine (or at least as well as they ever did) on 
Leopard, but anyone using the new API is pretty much stuck with 
whatever Apple thought should be exposed and there's currently no way 
for 3rd parties to extend it.

>Darryl would like to help but is not up to the task of writing his
>own kernel extensions for Leopard.

There's no reason to write any kernel extensions -- the QTKit API 
uses the Sequence Grabber internally and there's a documented API for 
accessing the Sequence Grabber instance controlling a given video 
input.

He should Google "site:lists.apple.com SGSettingsDialog QTKit" or
"site:lists.apple.com QTCaptureDeviceLegacySequenceGrabberAttribute"

Here is a description of the situation:

<http://lists.apple.com/archives/QuickTime-API/2008/Feb/msg00240.html>

Here is an example with a code snippet for bringing up the SGSettingsDialog:

<http://lists.apple.com/archives/quicktime-api/2007/Nov/msg00065.html>

>    So how does one control a USB webcam for astrophotography  using
>Leopard?

Stick to the Sequence Grabber or Video Digitzer API's, which still 
work for all devices or use the escape mechanism above -- if 
QTCaptureDeviceLegacySequenceGrabberAttribute is non-null, then they 
can access additional properties, otherwise they're stuck with what 
Apple has exposed.

>Could one use the Macam or the IoXperts drivers with Equinox 6.7.2 
>running under Leopard? No. Equinox will not present the camera 
>control interface for the reasons just stated.

See above -- I'd be glad to work with the Equinox developers if 
they'd provide me with a copy of their software and spend some time 
working over issues.

We also expose a bunch of device specific attributes that would be 
useful to them.

At the moment, these are implemented as a custom API:

<http://www.ioxperts.com/APIDocumentation.html>

Which is used by our SGPanel components to talk to our Video 
Digitizer -- everything that's visible in the custom settings is 
available through this API.

I haven't documented all of the selectors because I'd like to clean 
them up, but make them available to application developers on request.

I'd really like to, and would be willing to, rewrite this API in a 
public manner using QuickTime Component Properties, which are more 
general (and postdate our internal API by 5 years or so).

Part of this task would be to define the public properties and 
exactly what they mean, so that they can be shared between devices.

>Well, how about using BTV pro, which Jeff and Steve suggested to capture
>video under OS X 10.5?  Yes, the beta version of BTV pro, which hasn't
>seen any further development since 2006, will manage to capture video
>from a USB camera like the Philips SPC900N. The BTV pro interface  for
>USB Webcam capture is way inferior to the Equinox interface that worked
>under Tiger.

I don't see any reason Equinox couldn't make that API work for 
non-Apple devices using the method described above. At the moment, it 
is the only device API available to 3rd party developers.

>Is it the job of Steve Sisak to provide an interface that will appear in
>Equinox? I don't think so. The IoXperts beta driver Steve provides
>allows the camera to be seen by BTV Pro and Equinox. Steve provides the
>interface for camera control for capture apps. But it is up to the
>capture apps to make Steve's interface operational through the use of
>well API's or kernel extensions.

We provide one -- called SGPanel components that use the standard 
QuickTIme API defined since 1987 or so. (The last major update to the 
Video Digitizer API was in 1991)

Also, if any developers on the list would like it, I have code (used 
by IOXperts Camera Control) to host SGPanel Components in an HIView, 
which could be embedded in another application.

I've tried not compete with application vendors, but it may be time 
to include a stripped-down capture program with the driver, just so 
there's something useful in the box.

Feedback on what it should be are welcome.

>    So if there is any finger pointing here, it is me, pointing the
>finger at myself for getting involved in this Byzantine USB driver
>nightmare. I am getting off the merry-go-round and getting a DMK
>firewire camera and using AStro IIDC control software. I think Steve
>Jobs would agree.

Going to a single vendor solution might not be a bad idea -- Milton 
(author of Astro IIDC) and I are probably the last independent 
commercial video driver developers left. He chose to leave QuickTime 
and develop a solution outside it (which may have been a better idea).

>    Steve has a lot more people to satisfy than just the members of the
>tiny astrocamera segment like myself, so we need to cut him as much
>slack as possible in this huge undertaking of his to create drivers for
>every conceivable USB and FW application of importance.

Nevertheless, this is one of the areas where a 3rd party can provide 
value -- otherwise you might as well stick with Apple's free drivers.

We've tried to stick strictly to published APIs and will always 
accept feature requests from users and application developers -- 
there's always the issue of finite time in a day and the need to make 
a living, but anything that can be cast as a general solution (or the 
comes with funding) is welcome.

>    Steve, this sounds like a "case closed" to me, although I would
>appreciate any comments on this diatribe you might like to add.

I could go on a long diatribe as well, but hopefully the above would 
be enough for the Equinox developers to get settings working again -- 
I'd be glad to work with them directly if they contact me.

In the long term, I've got some thinking to do about the viability of 
the 3rd party video driver business and everything depends on what 
Apple does with the QTKit capture device API and wether it's frozen 
before it's seeded to developers for critical review.

I have a genuine fear that it will end up like the "Image Capture 
Architecture" which is the API for controlling digital cameras and 
scanners which, after something like 5 years of shipping, still has 
no way to support a sheet feeder on a scanner. (And I filed that bug 
report on the first day I saw the API)

Would people be interested in a clean (but general) open source API 
for capturing video that didn't come from Apple? (I have a partially 
complete C++ replacement for the sequence grabber sitting around here 
that I could dust off and finish if there were interest)

Thoughts?

Anyway, I completely feel your pain.

-Steve
-- 
_________________________________________________________________________
Steve Sisak, CTO                                 steve.sisak at ioxperts.com
IOXperts, Inc.                                     voice: +1 617 876-2572
87 Bristol St #3A                                    fax: +1 617 876-2337
Cambridge, MA 02139                               mobile: +1 617 388-6476