-
Notifications
You must be signed in to change notification settings - Fork 51
[camera] Implement pausePreview and resumePreview #260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
b1cc2c8
to
7ddcf77
Compare
8d2cf22
to
b14ab23
Compare
if (self->is_preview_paused_) { | ||
media_packet_destroy(packet); | ||
self->prepared_packet_ = nullptr; | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simply discard the prepared packet when is_preview_paused_
is true, without stopping the preview itself (camera_stop_preview
).
How do you like this approach? @bbrto21
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! but the relationship between Is_preview_paused_
and StopCameraPreview
seems ambiguous. how about adding some comments?
Remark: Preview affects the state of the camera device. also it always pause the preview before start recording using StopCameraPreview
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I can safely call StopCameraPreview
and StartCameraPreview
at any time and it makes more sense to you, I'll change the implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm totally fine with current Implementation. but I'll check the safety when I get back to the office :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this change on a TM1 device today, but it didn't work as expected, because the capture API requires the camera state to be CAMERA_STATE_PREVIEW
before capturing. Even if I call StartCameraPreview
before calling StartCameraCapture
and call StopCameraPreview
again after the capture is finished, the call to StopCameraPreview
results in an Invalid state
error for unknown reason.
The problem of the current implementation is that the preview textures are not delivered to Flutter even when the user is recording a video. This is inconsistent with the Android side implementation. Let's revisit this issue when it's needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! 👍
Another issue: Switching between camera devices (front and back cameras) leads to app freezing on TM1 devices quite frequently. The issue is not related to this PR. |
* [camera] Update camera to 0.9.4 * Implement pausePreview and resumePreview
@swift-kim in this PR the test driver was deleted. however, no new test drivers were added. should we add new one? |
@bbrto21 Basically we don't need test drivers for most of our plugins, because we now run tests with |
pausePreview
andresumePreview
. (Added in camera_platform_interface 2.1.0.)@bbrto21 The example app doesn't quite work smoothly on TM1, even with #258 applied to video_player_tizen. Could you take a look?