thanks for the responses. i just fixed my YUV situation. the problem wasn't my code, seems like i had a corrupted YUV movie for some reason. worked fine on a fresh capture from the emulator. i had moved this functionality off the phone, but at least now i have the option of handling the YUV stream directly should the need arise.
i was going to report that setPreviewSize() doesn't work on the emulator or the G1, but thanks to your post i will go back and retry using the other pixel format. i'm encountering other problems on the G1, such as the VM dying in Camera due to lack of memory (far below me, my footprint is nonexistent). but maybe your discovery will reduce the chance of that happening, too. i really hope that the restriction on MovieRecorder is lifted soon, or at least Camera gets some attention, so that video capture stops being the bear it currently is. >Actually, what I wrote before was when setting PixelFormat.JPEG, for >which I noticed that setPreviewSize() took no effect whatsoever and >always resulted in a default size of 176 x 144. I now found that if I >select PixelFormat.YCbCr_422_SP, which may correspond to yuv422sp from >its naming resemblence, setPreviewSize() finally *does* take effect >like it should. However, in SDK 1.0 r1 there is just no API for >setting the preview *position*, so this resizing advance remains of >limited value unless one instead renders the wrongly positioned live >preview invisible, and uses its byte array (image content) to a create >a visible bitmap at the desired screen location. This works for me in >the emulator (I'm still messing with the decoded color map). Still, it >looks more like an ugly hack based on an ad hoc reverse engineered >yuv422sp data format (boy, I'm beginning to love Java ME again where >none of this misery is needed). The preview image data array still has >a size of 2 bytes per pixel in my case. > >On Oct 25, 7:59 pm, blindfold <[EMAIL PROTECTED]> wrote: >> I'm not even sure whether Android's yuv422sp preview format represents >> any decent standard format, because with a previous SDK M5 RC15 we got >> a color preview on the emulator screen, whereas nowadays with SDK 1.0 >> r1 it shows as greyscale only. Moreover, although the preview array >> for me shows a size corresponding to 176 x 144 at 16 bpp (namely 50688 >> bytes), I get a nice clean greyscale image if I just save the preview >> image as a raw binary file and next import it into for instance >> IrfanView as a 176 x 144 8 bpp (1 byte per pixel greyscale) headerless >> raw image file, thus brutally discarding the second half of the byte >> array! By loading the file as 16 bpp I can see that there is color >> info in the second half of the file, but as far as reproducing the >> greyscale emulator preview is concerned, simply treating the (first >> half of the) byte array as 176 x 144 8 bpp pure greyscale encoding >> seems to suffice. >> >> I wonder what byte array the physical G1 generates as preview image... >> I still haven't had any answers from the Android Team on my various >> camera questions lately, while camera based image processing in >> Android currently has some serious unresolved issues. >> >> Regards > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
