Fixed a race condition where some recording frames may not be released.
When startRecording() is called before setListener(), recording frames
are sent right after startRecording(), but there is no listener to
release the recording frames. This causes the hang in media server.
bug - 3166356
Change-Id: I19366ca682ef9f6b847590c190c30a15ed32b8e4
diff --git a/media/libstagefright/CameraSource.cpp b/media/libstagefright/CameraSource.cpp
index b8450fb..d9ff723 100644
--- a/media/libstagefright/CameraSource.cpp
+++ b/media/libstagefright/CameraSource.cpp
@@ -495,26 +495,6 @@
mIsMetaDataStoredInVideoBuffers = true;
}
- /*
- * mCamera->startRecording() signals camera hal to make
- * available the video buffers (for instance, allocation
- * of the video buffers may be triggered when camera hal's
- * startRecording() method is called). Making available these
- * video buffers earlier (before calling start()) is critical,
- * if one wants to configure omx video encoders to use these
- * buffers for passing video frame data during video recording
- * without the need to memcpy the video frame data stored
- * in these buffers. Eliminating memcpy for video frame data
- * is crucial in performance for HD quality video recording
- * applications.
- *
- * Based on OMX IL spec, configuring the omx video encoders
- * must occur in loaded state. When start() is called, omx
- * video encoders are already in idle state, which is too
- * late. Thus, we must call mCamera->startRecording() earlier.
- */
- startCameraRecording();
-
IPCThreadState::self()->restoreCallingIdentity(token);
int64_t glitchDurationUs = (1000000LL / mVideoFrameRate);
@@ -565,8 +545,11 @@
mStartTimeUs = startTimeUs;
}
+ // Call setListener first before calling startCameraRecording()
+ // to avoid recording frames being dropped.
int64_t token = IPCThreadState::self()->clearCallingIdentity();
mCamera->setListener(new CameraSourceListener(this));
+ startCameraRecording();
IPCThreadState::self()->restoreCallingIdentity(token);
mStarted = true;