Description
We’re running into a new issue with the latest macOS SDK (v5.7.6.1333) where we are losing the virtual background between calls to start and stop video.
Which Desktop Meeting SDK version?
v5.7.6.1333
To Reproduce(If applicable)
Steps to reproduce the behavior:
Go to Virtual Background Settings and select a background
Start the user’s video
Result: The background is not used
With user video on, select a virtual background. Once the settings dialog is opened, the background is now visible and will work as long as the video stays on.
5: Stop video and start it again
Result:
The virtual background is no longer visible. It is lost every time the video is started and stopped.
Device (please complete the following information):
Device: Macbook Pro (16 inch 2019), Also all know mac users are reporting this
OS: macOS Big Sur 11.6
Additional context
This issue did not occur until upgrading to the latest ZoomSDK
Just to follow up on this, I tried virtual backgrounds in the sample app and it is completely broken there too. I also get a dialog message that virtual background is still loading but it never does.
Hi @nathancq, thanks for bringing this to our attention.
After some testing, there definitely seems to be some strange behavior around virtual backgrounds when using the default UI. We’ll need to investigate this further and get back to you as soon as we have any updates.
Just to clarify though, is the behavior you mentioned seeing in the sample app not the same as what you are seeing in your own app?
Hi Jon, thanks for looking into this. It’s actually a little bit worse in the sample app. I can’t seem to get VB to apply at all there. In our custom app, I can get the VB to apply but it no longer works once video is started and stopped. At one point, VB would no longer apply in our app either but I was able to get it to come back after toggling “use greenscreen” off and on. I think it’s the same issue affecting both however. One of our devs reported seeing an error in the console that could be related: unknown hint identifier ‘kCGImageSourceTypeIdentifierHint:public.data’
Thanks for confirming. We have identified a fix for the behavior in the sample app, but it is not clear whether or not this will resolve the behavior you are seeing since it is slightly different. The SDK version with a fix for this should be available relatively soon, so be sure to let me know if the issue that is present in your application is still reproducible.
In case you weren’t already aware, you can find the most up-to-date release information in #new-releases or over on our release notes page.
