Description
After updating to the SDK to 5.7.6.1340 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?
macOS 11.4
SDK v.5.7.6.1340
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):
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.zoom ,
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];
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?
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.