Tutorial: persistent camera settings

[Steve Sisak]

At 2:33 PM -0400 4/11/05, Chris French wrote:
>On Apr 11, 2005, at 8:00 AM, Julien Letessier wrote:
>>On 22 Mar 2005, at 15:08, Chris French wrote:
>>>http://developer.apple.com/qa/qa2001/qa1286.html
>>
>>Do you have pointers on how to read the camera GUID using QuickTime ?
>
>This is all covered in the Apple sample code
>
>http://developer.apple.com/samplecode/SGDevices/SGDevices.html

Actually, before you get too far down this road, I need to point out 
that a lot of this applies to Apple's QuickTime IIDC driver, which 
has quite a number of "unique" features.

(In general, if you're writing code to deal with video digitizers, 
you'll need to special case Apple's IIDC driver -- kind of like 
modern web sites that frequently have to code paths: 
standards-compliant browsers and Internet Explorer)

I wanted to spend some time replying to this and generating some 
"best practice" sample code for doing things right.

One of the big issues is the relationship between digitizers and inputs.

The standard mechanism is to have a separate video digitizer 
component for each piece of independently controllable piece of 
hardware (which are usually dynamically registered) while "inputs" 
represent mutually-exclusive ways to connect to a digitizer 
(RCA/Component/S-video,TV tuner, etc.).

Since it represents a piece of hardware, a Video Digitizer component 
typically only allows one instance to be open at a time.

Unfortunately, Apple decided to implement the IIDC digitizer as a 
single component and have each camera appear as an input -- so the 
number of inputs can change over time, etc. -- also it's not clear 
what you'd do if you had an IIDC digitizer box that had more than one 
input.

Further, for USB devices, device unique IDs are optional (the Philips 
Vesta and ToUcam and later AME CU-001 cameras have them), but when 
present are an arbitrary Unicode string -- 64 bits are insufficient.

Unfortunately the author of the Apple IIDC driver had the ability to 
make changes to Quicktime to support his driver (there was a period 
where the image settings for all other drivers were not saved because 
the IIDC driver overrode the Image panel but neglected to call 
through if the selected inputs was not the Apple IIDC driver).

This resulted in even more mechanisms for naming inputs, associating 
with them with devices -- see the comment above 
VDGetDeviceNameAndFlags() for how it's supposed to work -- I also 
have a bunch of bugs open because a lot of what's documented doesn't 
actually work as documented.

The 1.1 version of the IOXperts drivers (as of about 1.1b48) are 
dynamically registered, one component per device and VDGetUniqueIDs() 
returns the FireWire Unique ID as the device (not input) id -- this 
call isn't implemented in older version (because it didn't exist at 
the time), but is avalable through our developer API.

There are a couple other Q&A's that present themselves as being 
globally applicable but really only refer to the Apple IIDC digitizer 
-- the most notable being 
<http://developer.apple.com/qa/qa2005/qa1403.html>

Any reasonable digitizer reports the actual sensor size from 
VDGetActiveSrcRect() -- Apple hard-codes 1600x1200 for no good reason.

(Actually, it side-steps the issue of needing to talk to a piece of 
hardware that might be in use by another application and the lack of 
a mechanism to be notified when it becomes available, but creates a 
mess for developers)

Then, again, we all know that the iSight is the only video input that 
matters. ;-)

More later, but I wanted to get started -- feel free to keep posting questions.

-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