After updating to the SDK to 126.96.36.1990 we have found that right after the SDK is being successfully initialized, the Facetime camera turns on. This happens even before the user logs in. This seems to be a bit odd. Previous SDK version did activate the camera only when the user started a meeting.
Is this an intended behavior now or will this be fixed?
Which macOS Meeting SDK version?
To Reproduce(If applicable)
Steps to reproduce the behavior:
- Get a shared instance of the SDK: ZoomSDK* sdk = [ZoomSDK sharedSDK];
- Set domain to “zoom.us”: [sdk setZoomDomain:@“zoom.us”];
- Authorize an SDK: ZoomSDKError sdkAuthError = [[ZoomSDK sharedSDK].getAuthService sdkAuth:key appSecret:secret];
- The Facetime camera is being activated. The green LED is turned on.
Device (please complete the following information):
- Device: Apple iMac late 2017
- OS: macOS Big Sur 11.4
Hi @mcfly, thanks for the post.
I was not able to reproduce this behavior. On a fresh build with the SDK, the camera does not turn on and permission is not requested until after joining or starting a meeting. On subsequent runs, the camera light is not active until I can see my video preview in the meeting. Are you able to reproduce this using the SDK sample app? Is it possible that another application on your machine is attempting to use the camera?
Hi @jon.lieblich ,
This behavior is definitely caused by Zoom SDK because if I remove the initialization code, the camera is not turned on.
The SDK sample does not turn the camera on. After further investigation we have found that the camera was turned on after calling [setting enableCatchHDVideo:YES];.
Previous SDK version we used did not turn the camera on after this call.
So, actual steps are:
- Initialize SDK
- Authorize SDK
- In the authorization callback (onZoomSDKAuthReturn:) call:
[[[[ZoomSDK sharedSDK] getSettingService] getVideoSetting] enableCatchHDVideo:YES];
- The camera is being activated
Thanks for clarifying around your usage of the SDK. For the SDK’s video settings, they are meant to mimic the default UI’s setting window in which a video preview is active to show the changes as they are made. Since you were not seeing this behavior in an older version of the SDK, we’ll need to check whether or not a change was explicitly made for this, or if some of the behavior from the default UI leaked over into this method’s functionality. Can you please confirm the last version where this behaved differently?
Hi @jon.lieblich ,
The version where tis behaved differently is 5.5.12511.0420
Thanks for confirming the version. We’ll look into this and keep you updated.
Just so you are aware, I tested and confirmed that this behavior is also present on the newly released 5.9.0 version of the SDK.
Hi @jon.lieblich , thank you, waiting for updates
After looking into this, we have determined that the behavior that existed in the older version of the SDK is incorrect. Whenever there are changes made to the video settings of a user, it should be reflected in a video preview so that the changes are apparent to the end user.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.