I don't want to add another API to MediaRecorder. We can add another parameter to the setParameter interface in the camera HAL to indicate if the call comes from the owner of the camera. The camera driver is then responsible for preventing other callers from changing anything that might affect the owner's use case. This provides flexibility to vendors to add new features without explicitly adding them to a whitelist in the CameraService or the MediaRecorder.
Which callback did you want to get at the application level? It's not practical to bring the video frames back to the app because the encoder node needs to control the release of frames. On Feb 18, 7:21 am, steve2641 <steve2...@gmail.com> wrote: > Dave, > > Can you explain a little further on what you mean when you say "enable > a subset of safe API's"? > > Since a good percentage of the interface configuration is handled by > the Camera Parameters, and the Camera Parameters are pretty much an > direct interface between the App and the Camera HAL, I'm not sure how > the framework could limit these interactions without having a direct > hand in how the Camera HAL processes the parameter changes. > > Also, in my case I need the app to continue to receive an additional > camera callback. Will this be handled by this future release? The > other thought we had was adding the controls and callbacks for this > new feature to the Media Recorder API as well as the Camera API, but > generally we don't like the idea of having to duplicate the > interfaces. Would it make any sense to have a secondary API (say > Camera Effects) for those camera related features that are common > between the two use cases and should/could be usable by the > application in both cases? > > Steve. > > On Feb 17, 10:00 am, Dave Sparks <davidspa...@android.com> wrote: > > > 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.- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
