Re: shoring up the Sequence Grabber - Part 1.

Since we are on this thread, here are my top 5 changes needed. This is  Part one because the @#%#$$%$%  List mom won't allow e-mails bigger than 12 kilobytes of text.

1) You really need to overhaul the SGPanel resource situation for GUI. Currently to add a SGPanel to a VDIG means using Resedit (on PowerPC) or Resourcer (both PPC/Intel) to edit the .rsrc file, then using derez tools to extract the text and then paste the .r text into your .r file and then build it to see what it looks like when used within the SGPanel. Also don't do what you did for CoreAudio either - which was provide basic get/set API calls,  but no defined GUI for it. Expecting each VDIG developer to create their own interface or get each Application developer to write their own method is stupid and causes horrendous confusion. I have filed an enhancement request ( Radar #4144580 June 2005 ) - nothing has been done and I don't waste my time filing more requests if I see no interest from Apple.

2) Secondly, the method for how the VDIG and the SG communicate on VDIG capabilities is not working.  Back in the 1990's devices barely supported 1 video size, now a days I work with USB2 and FW800 cameras that deliver 4000 x 4000 pixels down to 1x80 pixels (line scanners) in 8, 10,12, 14 and 16 bit depths and maybe 8 different video formats. Where it falls apart is:

a) Devices may be able to deliver multiple video formats (i.e. YUV422. mono 8, Bayer, YUV411, YUV444, ARGB24, Mono16, RGB48  etc. etc.). Currently the only way to even hint that this is available is by returning multiple types in VDGetCompressionTypes() and hope someone looks at what you return, or via trial and error in the VDSetCompression() call. The SG or an end user should be able to request a list of 4 char codecs types and bit depths that you support for a given video size. Windows figured this out in the mid 1990's - Apple never did.

b) VDIGS and Devices may be able to single sizes, continuously variable sizes or support multiple discrete sizes of video, so the VDIG should be able to deliver a list of supported sizes. Also we need to be able to indicate we can support any size to, so that we don't wind up returning a list of sizes in 2 pixel increments for say 4000 x 4000 to 1x80 in 2 increments. Again, windows figured this out in the mid 1990's - Apple never did.

c) We need to be able to indicate bit depths we can deliver,  what endian we can deliver and also if the data is Progressive, interlaced frames or Interlaced fields. Although CPIX resource for Codecs would probably help, it may be a bit vague because many of the cameras I work with are capable of delivering 8 formats out, however they may only deliver say Mono 8 at sizes to say 640x480 and not at 768x576 for example.

Milton J. Aupperle
President
ASC - Aupperle Services and Contracting
Mac Software (Drivers, Components and Application) Specialist
#1005 - 815 14th Avenue. S.W.
Calgary Alberta Canada T2R0N5
1-(403)-229-9456
email@hidden
www.outcastsoft.com