[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
QuickTime Video Capture Archive Note
Since it doesn't look like I'll be able to finish up my work on Mac OS X
video capture, I wanted to dump some notes into the archive so that
someone can continue my work. I've committed my latest files to CVS so
they're saved.
From Milton Aupperle <milton at outcastsoft dot com>:
> If it's an iBOT (or basically any other FW WebCam they all use the same
> TI Chip Set)- it depends on what the VDIG Driver is outputting. The
> WEbCam iiDC/DCAM cameras can output YUV as 4:4:4 (160x120 3.75 to 60
> fps), 4:2:2 (320x240/640x480 at 1.875 to 30/15 fps), 4:1:1 (640x480
> 3.75 to 30 fps), RGB24 (640x480 1.875 to 15 fps) and MonoChrome
> (640x480 3.75 to 30 or 60?? FPS). The parameters are not slectable in
> the IOXpert / iBOT drivers.
>
> The 4:2:2 format is actually "k422YpCbCr8CodecType" or "'2vuy'".
>
> In the "SonofMungGrab.c" in the Call "InitializeMungData" I simply
> changed the
>
> err = QTNewGWorld(&(pMungData->pGWorld), // returned GWorld
> k32ARGBPixelFormat, // pixel format
> &inBounds, // bounds
> 0, // color table
> NULL, // GDHandle
> 0); // flags
>
> "k32ARGBPixelFormat" to "k422YpCbCr8CodecType" format - then
> uncommented the "Draw ing Frame Rate Text Code" (cause QuickDraw
> doesn't understand Gworlds that are not RGB32, RGB16 or RGB8 format)
> and the Video displayed perfectly fine (an ADs Pyro using my Driver) -
> and it was delivered as "2vuy" (YCbCrY) format.
>
> What you need to do is verify what the Camera is outputting format wise
> it's "Native" format. There are several ways of Doing it, but within
> the "SonofMungGrab" sample, you need to check the call
> "MungGrabDataProc" and then see what the "(**imageDesc).cType field
> value is (probably '2vuy' or 'yuvs or 'yuvu'). Then you know for sure
> what YUV format (and YUV ordering is cause of byte swapping for
> little - big endian output).
>
> PS: FYI - I can not get the ADS Pyro to output usable RGB24 data yet
> (no problem with YUV 4:4:4 and YUV 4:1:1 I transcode into 4:4:4:4 or
> YUV4:2:2 as the data packets arrive) - I think that may be broken in
> the TI Chip Set or perhaps it's just this camera. But for whatever
> reason I can not yet get it to work.
>
> 2) Either convert it yourself into YUV (RGB to YUV can be done in a
> variety of ways using simple math or even Altive if your up for a
> challenge) or use the Compresion Manager to do it (See Convert Movie
> Junior for info on this).
>
> Note that there is no Compressor or Decompressor available for YUV
> 4:2:0 or 4:1:1 formats, so you'll have to do those yourself. The PixMap
> for those formats exist, but NOT the Codecs to Compress/Decompress them.
Rob Shaw's postings in the quicktime-api discussion list at
http://lists.apple.com/ has information on how he used the lower-level
Video Digitizer (VDIG) API to grab frames. I think this may actually be
the way to go, because the Sequence Grabber API is more for movies (i.e.
image sequences) and frames are compressed and may not be "complete"
without "key frames".
Kevin Mark responded to Rob Shaw and wrote:
> I believe it is 'yuv2' format, but the ImageDescription you get back in
> the code example above will let you know. You should be able to
> manipulate the pixels directly in the data buffer returned without
> drawing into a GWorld first in that case.
The function call SGGrabPict should not be used. It is way too slow.
I believe grabbing PixMaps out of a GWorld should be done in sgDataProc,
while grabbing frames should be done with a sequence grabber in
sgGrabComplete (a video bottleneck). However, if using the VDIG API,
then neither of those may be necessary and the calls described in Rob
Shaw's postings to set a destination buffer and directly call a frame
capture in VideoCaptureMacOSX::capture() looks like the way to go.
Postings on Google Groups seemed to indicate that you should not
directly use the VDIG API, and that this might actually fail on newer
machines. I have not been able to verify this or receive confirmation
from Apple that it would be a "wrong" thing to use the VDIG API. Rob
Shaw's machine was an older A/V series Mac which seemed to be the last
series to have some serious A/V hardware support built-in. The 7600,
8600, etc. or whatever series. (I used to have one...these were the
machines where speech recognition was first introduced and I could start
working with my monitor off :)
Later,
Wes