Hi,

In the cupcake baseline and beyond, the potential exists for an
application to create and configure a Camera object and then pass that
object to the media recorder to be used to deliver preview frames to
be encoded into a video file.  This is fine except for the fact that
the media recorder does a "reconnect" to the Camera object, thus
seemingly disconnecting the application from the camera object.

Does this "reconnect" prevent the application from any further
interaction with the camera device?

I'm pretty sure, but please correct me if I'm wrong, that at a minimum
the "reconnect" will prevent the application from being able to
receive any callbacks that may be of interest.  For instance, say an
implementation adds a new capability to the camera interface which
includes a callback to denote completion of a requested task.  When
the camera object is passed off to the media recorder the Application
seems to be losing access to these expanded features that maybe
desired during the capture of the video.  We have such an enhancement
planned, but I don't feel comfortable disclosing the details in a
public forum.

It would seem more appropriate, at least in my case, that the media
recorder "reconnect" be changed to a very specific "request frames"
call which would not take over all of the potential callbacks that
could occur, but simply tell Camera Services that the video engine
requests the preview frames.  With this Camera Services could continue
to service the application as it does when no video record use case is
running.  The addition would be that Camera Services would also have
an additional client to pass frames to, the video engine.  When Camera
Services receives a preview frame from HAL it would pass it to the
Surface Flinger, potentially pass it to the application (when
requested), and potentially send it to the video engine (also, when
requested).

In the case where the application does not provide a Camera object the
media recorder would still have to create it's own camera object.
That's a hook that seems very clean and clearly needed.

Comments?

Thanks,

Steve.

--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to