summaryrefslogtreecommitdiffstats
path: root/include/media/stagefright/CameraSourceTimeLapse.h
Commit message (Collapse)AuthorAgeFilesLines
* Don't call virtual functions in the destructor for audio and camera source ↵James Dong2012-02-021-3/+0
| | | | | | classes Change-Id: Ia74ffc1c0cbd7971697f5e3c476e340ec5c7727a
* Fix log spamming during time lapse video recordingJames Dong2011-11-211-4/+0
| | | | | | Change-Id: I4fc0809203684ebb02eaf217d7abad00aefc898f related-to-bug: 5626569
* Do not support still image capture mode for timelapse video recordingJames Dong2011-07-241-76/+0
| | | | | | related-to-bug: 4973779 Change-Id: Ica665217ab10247b2242acc4e93d4fe9f83e3f45
* Add framework support for camcorder zoom.Wu-cheng Li2011-06-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of ICameraRecordingProxy and ICameraRecordingProxyListener is to allow applications using the camera during recording. Camera service allows only one client at a time. Since camcorder application needs to own the camera to do things like zoom, the media recorder cannot access the camera directly during recording. So ICameraRecordingProxy is a proxy of ICamera, which allows the media recorder to start/stop the recording and release recording frames. ICameraRecordingProxyListener is an interface that allows the recorder to receive video frames during recording. ICameraRecordingProxy startRecording() stopRecording() releaseRecordingFrame() ICameraRecordingProxyListener dataCallbackTimestamp() The camcorder app opens the camera and starts the preview. The app passes ICamera and ICameraRecordingProxy to the media recorder by MediaRecorder::setCamera(). The recorder uses ICamera to setup the camera in MediaRecorder::start(). After setup, the recorder disconnects from camera service. The recorder calls ICameraRecordingProxy::startRecording() and passes a ICameraRecordingProxyListener to the app. The app connects back to camera service and starts the recording. The app owns the camera and can do things like zoom. The media recorder receives the video frames from the listener and releases them by ICameraRecordingProxy::releaseRecordingFrame. The recorder calls ICameraRecordingProxy::stopRecording() to stop the recording. The call sequences are as follows: 1. The app: Camera.unlock(). 2. The app: MediaRecorder.setCamera(). 3. Start recording (1) The app: MediaRecorder.start(). (2) The recorder: ICamera.unlock() and ICamera.disconnect(). (3) The recorder: ICameraRecordingProxy.startRecording(). (4) The app: ICamera.reconnect(). (5) The app: ICamera.startRecording(). 4. During recording (1) The recorder: receive frames from ICameraRecordingProxyListener.dataCallbackTimestamp() (2) The recorder: release frames by ICameraRecordingProxy.releaseRecordingFrame(). 5. Stop recording (1) The app: MediaRecorder.stop() (2) The recorder: ICameraRecordingProxy.stopRecording(). (3) The app: ICamera.stopRecording(). bug:2644213 Change-Id: I15269397defc25cbbcae16abc071c8349c123122
* Use video output if necessary for timelapse video recordingJames Dong2011-01-041-3/+3
| | | | Change-Id: I88d0cc824f0fbf8b2f392fbc23c69b5bfefda1b8
* Move Camera specific logic out from StagefrightRecorder to CameraSourceJames Dong2010-10-081-13/+14
| | | | | | | o updated comments and streamlined the logic in checkVideoSize() and checkFrameRate() as suggested Change-Id: I49d04ac7998d4a215997aa63555dfb6e814e38d3
* Implemented frequent read returns for quick stop in time lapse.Nipun Kwatra2010-09-171-1/+60
| | | | | | | | | | | | | | | | | | | If the frame capture interval is large, read will block for a long time. Due to the way the mediaRecorder framework works, a stop() call from mediaRecorder waits until the read returns, causing a long wait for stop() to return. To avoid this, we return a copy of the last read frame with the same time stamp if a frame is not available quickly. This keeps the read() call from blocking too long. This method is triggered when startQuickReadReturns() is called on CameraSourceTimeLapse. In the still camera case, also using waitRelative on Condition instaed of sleeping, so that we can wake it up. Also for the idle check instead of sleeping, we now wait on a condition variable, which is woken up when the last takePicture callback gets called. Change-Id: Ia74386e175536aee0f44ae2f8b114c353d3d72f5
* Moving decision to use still camera to CameraSourceTimeLapseNipun Kwatra2010-09-031-3/+6
| | | | | | | | | | | | CameraSourceTimeLapse now decides whether to use still or video camera automatically. It checks if the passed in size is a valid preview size and if it is, then uses the video camera else uses the still camera. Removed from StagefrightRecorder the support to set parameter useStillCameraForTimeLapse. Change-Id: I71f5b0fc7080ca524792381efe918d22e41a7f36
* Implementing getSupportedPictureSizesNipun Kwatra2010-08-021-3/+5
| | | | | | | Go through all the supported picture sizes and choose the smallest one with both dimensions higher than the passed in video width and height. Change-Id: I4e9fe7a6384a0feeb9e069239ec68c70fb5f3033
* Support for video size to be different from captured picture size.Nipun Kwatra2010-07-291-0/+33
| | | | | | | | | Adding support to allow video size to be different than the supported picture sizes. A picture size larger than the demanded video size is chosen. Captured pictures are then cropped to the size of the desired video size. Cropping is done from the the center portion of the picture. Change-Id: I6bcbe16f94b6ecbcf28b7f46826a81b4b6b8cbc3
* Allowing setting of time lapse parameters through MediaRecorder.javaNipun Kwatra2010-07-221-0/+3
| | | | | | | | added setTimeLapseParameters() to MediaRecorder.java and SetParameter support in StagefrightRecorder to allow enabling time lapse and setting the corresponding parameters. Change-Id: I509040aa71f8d3fc37337b0894a81d9c0fd7a40a
* Restart preview after each takePicture is done.Nipun Kwatra2010-07-201-1/+14
| | | | | | | | | Preview is called when CAMERA_MSG_COMPRESSED_IMAGE is recieved by dataCallback(). It needs to be started as a new thread so that the callback can return, and the camera can know that takePicture() is done. Change-Id: I4d0febbc993aac43b37f9f4a824e9c7b8785f19e
* Adding support for timelapse capture using still camera's takepicture.Nipun Kwatra2010-07-191-0/+129
Also moving entire implementation into a new class CameraSourceTimeLapse which inherits from CameraSource. For timelapse capture using still camera, we start a thread which runs a loop in which it calls Camera::takePicture() and then sleeps until the next frame should be captured. The function dataCallback() handles the callback from the camera with the raw image data. This function copies the data and creates an artificial timestamp corresponding to one frame time ahead of the last encoded frame's time stamp. It then calls dataCallbackTimestamp() of the base class which will think that it recieved the frame from a video camera and proceed as usual. For moving the implementation to the subclass CameraSourceTimeLapse, added a few virtual functions to CameraSource, which do the current thing for the base class, but specialized things for CameraSourceTimeLapse. E.g. startCameraRecording() in the base class just calls mCamera->startRecording(), while in CameraSourceTimeLapse it may start a thread for the still camera case. Change-Id: Ib787f24bd2e1f41681513f0257e1c4ca10a2b4de
generated by cgit v1.1 at 2024-07-13 07:53:29 +0000