Will someone please send an example of how to process the camera
preview with a filter in the camera preview callback:
Camera.PreviewCallback.onPreviewFrame.

Here is what I learned from posts on this forum:

1. Don't use SURFACE_TYPE_PUSH_BUFFERS
// Comment out PUSH_BUFFERS in order to hide surface.
// mHolder.setType(SurfaceHolder.SURFACE_TYPE_PUSH_BUFFERS);
This solution does hide the camera preview - good.
I'm not sure which surface type to use instead.  I've been using
nothing or SURFACE_TYPE_NORMAL, which I assume is the default.

2. The preview data is delivered in a version of YCbCr_422_SP or
YCbCr_420_SP, which is different on the emulator and on the G1
device.  I have been receiving buffers that are exactly 1.5 times the
size of the image (i.e. bytes = w * h * 3 / 2).  I have not yet
decoded the data, as I still have bigger fish to fry.

This is what I have learned:

1. I can generate a small int[] data buffer using 4 byte Colors.  I
can turn it into a Bitmap with Bitmap.setPixels.  I can display it
from within the onPreviewFrame callback.  The goal here is to convert
the YCbCr_422_SP byte data into an int[] array with per-pixel
calculations, convert that into a Bitmap, and display through an
ImageView object.

2. If I process every frame, then the application on emulator or G1
cannot trap the Back key and never quits.  It finally exception
terminates.  Furthermore, for the G1 device, the camera is left in a
state that it will never run again by any application without power
cycle of the device.  This makes sense considering that
mCamera.stopCamera() or mCamera.release() never get called.

3. I can generate and display a 160x120 image at almost 10 frames per
second, even considering the skipped frames.  So far so good.

4. G1 phone always delivers 480x320 size frames.  The emulator
delivers an odd size that is taller than it is wide (I don't remember
exactly - something like 312x80 - yes, that bizarre).  This is checked
by reading the parameters in the camera object returned to the
onPreviewFrame callback:
Camera.Parameters params = camera.getParameters();
Camera.Size camSz = params.getPreviewSize();

Here are my problems:

1. Test generated data displays correctly and fast (I alternate
colored frames and can see them switching quickly on the screen of G1,
slower on emulator).  When I try to convert the byte data from the
camera all of it looks black.  I've looked at various offsets within
each expected set of 6 bytes for each 2 pixels.  I need help with the
decoding, but I worry that I am receiving empty buffers.

2. If I process larger frames or do too much processing or Log()
output in the onPreviewFrame callback, then the application stops
receiving any callbacks.

3. I have tried using a boolean lock variable to ensure that there are
no reentrant calls to onPreviewFrame.  This did not help - besides, I
don't think Android would enter the callback this way.

4. I believe that processing breaks down whenever I spend too much
time in the onPreviewFrame function.  Therefore, I think I could solve
my problems with a Thread for either the camera, the processing of
frames captured in the onPreviewFrame callback, or both.
Unfortunately, in order to process each frame in a different thread,
I'd incurr an extra copy of the YUV_422 byte[] buffer from
onCameraFrame into the Thread prior to processing.  Between this and
skipping frames that overlap the frame-processing thread, this might
drastically reduce the filter/display speed.

So, as a new Android programmer (who finds it a lot more like J2ME
than he had hoped) before launching into another several days of
battling with Bitmaps, Viewables, Surfaces, and now Threads, would
someone please give me their solution or partial solution to for
displaying data from onPreviewFrame.  I want the mechanics of Android
architecture as much or more than I'd like the YUV decoder.

Several people on this list have done this and complained about
speed.  One poster has so far only extracted the luminance data.  All
these solutions are good enough for me.  Please send via this list or
direct to dmanpearl_at_gmail_dot_com.

Thank you ever so much!

 - David

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to