We cannot allow the application to make any changes to the camera that could potentially violate the contract between the camera and the media recorder. For example, let's say that the video frame size is set to CIF, and the application changes it to QCIF in the middle of a recording. This will cause the encoder to read beyond the end of the frame and probably crash the media server process.
In a future release, we will enable a subset of safe API's that the application can use while video recording is in progress. On Feb 17, 6:20 am, steve2641 <steve2...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
