Dave, any comments on my last reply?
On Feb 19, 7:47 am, steve2641 <steve2...@gmail.com> wrote:
> We are not looking to allow the application to retrieve the preview
> frames during video recording. The callback I talk about is for
> another feature. I'll email you directly the general feature
> description.
>
> Another thought occurred to me, does the current architecture allow
> the displayed preview size to be different from the encoder video
> size? It seems as if this may not be the case, but maybe I'm mis-
> understand something here. Before I understood that the media
> recorder reconnects with camera services and effectively takes over
> from the application, I thought that the architecture could
> potentially allow the application to dictate the displayed frame size
> while the media recorder would dictate the video encoding frame size.
> A use case where these differing frame sizes could be useful is when
> encoding at very low resolution, say in order to send the video over
> MMS, but allowing the preview frame size to be larger so that the
> preview is not just a tiny box in the middle of a large display.
>
> Other than the frame size/format/rate, what other parameters would
> need to be locked down in order to maintain the camera services to
> media recorder contract? Could these parameters be passed from media
> recorder to camera services/HAL outside of the normal application path
> (camera parameters), thus indicating an active video encoding use case
> and allow HAL to prevent changes that might affect the video encode
> use case? This could prevent the need for reconnect and still allow
> Camera/App additions to function.
>
> Steve.
>
> On Feb 18, 10:54 am, Dave Sparks <davidspa...@android.com> wrote:
>
>
>
> > 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 -- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
