Description
Continue following https://devforum.zoom.us/t/the-canvas-video-occasionally-freezes/129584
We’ve observed that in version 2.1.0, when rendering video using canvas, the VM occasionally fails to decode new video frames, resulting in the video freezing.
We would like to know:
Can we detect when the video has frozen so we can handle it appropriately?
When this issue occurs, will calling stopRenderVideo followed by renderVideo resolve the video freeze?
What I meant to ask is:
In the current version, we still encounter the issue of video freezing—whether we use canvas or video-player—when WebRTC is not enabled. This seems to be caused by the VM occasionally failing to decode new video frames.
From what we understand, in the upcoming release, this issue will be resolved for bothcanvas and video-player even when WebRTC is disabled.
Is that correct?
Since we’re currently unable to enable WebRTC and the fixed version has not been released yet, we’re exploring a workaround for this issue.
Could you help us clarify the following questions?
Is there a way to detect when the video has frozen so we can handle it appropriately?
When the freeze occurs, does calling stopRenderVideo followed by renderVideo help recover the video?
If you have any other suggested workarounds, we’d greatly appreciate your recommendations.
Thank you again for your continued support!
We’re currently trying to reproduce this issue using a virtual machine. We’ve spent quite a bit of time on it but haven’t been successful so far. Would you be able to share your VM configuration details with us? This includes hardware specs, OS version, and browser version information.
@vic.yang If there’s any progress, please keep us informed. Also, if there’s a way to detect when a video has frozen, it would be very helpful—whether through a ZoomSDK API or any client-side way suggestion you can recommend?
We’re attempting to detect video freezing by sampling pixels at specific positions from the canvas created by ZoomSDK inside the shadow root, comparing them over a period of time. If the pixels remain unchanged, we consider the video frozen and try to re-render it. Do you think this approach would work?
@vic.yang
We’re also encountering this error with a regular user (not using a Virtual Machine):
Uncaught TypeError: Cannot set property rotation of #‹VideoFrame> which has only a getter
js_primitives.dart: 28
cOlba414-fe96-402b-b..-ac3d0e09538c: 22948 @*
at Object.render (e01ba414-fe96-402b-b..3d0e09538c:22948:51) at e.onmessage (e01ba414-fe96-402b-b...3d0e09538c: 21317:35)
Is this the same issue as the bug mentioned above? Does this help in your investigation?
Here’s the session ID of the meeting: wsv6yAK/TM2v8bFimXw/nw==
Additionally, we’ve noticed that the video freeze (black screen) issue tends to happen more frequently with the main video player, while the smaller video players are usually unaffected. Could this be related to the display size or resolution of the video player?
I had the same issue when resizing the container to add or remove active video participants. The root cause in my case was leftover video-player elements inside the video-player-container. After resizing and re-rendering, if the container still had old video-player elements, the video would freeze or fail to render properly.
Make sure to clear out all existing video-player elements from the container before rendering the updated list of participants. That fixed the issue for me.
Issue with remote video on Chrome 137.
It’s a known issue that we have fixed in Video SDK Web 2.2.0.
Are you referring to this error?
‘Uncaught TypeError: Cannot set property rotation of #‹VideoFrame> which has only a getter’
Additionally, is there any progress on the investigation into the video freeze issue on VM?
We’ve observed that the freeze (black screen) tends to occur more often with the main video player, while smaller video players usually remain unaffected. Could this behavior be related to the video player’s display size or resolution? (As shown in the image above.)
Could you please help us check the following session ID: wsv6yAK/TM2v8bFimXw/nw==?
Although we’ve enabled WebRTC for the bot user (using Chrome version 134) and are using attachVideo to render the stream onto the video player (as mentioned here), the video of user 16778240 appeared completely black on the bot user’s side.
After analyzing the logs, the bot User(16784384) never called attachVideo to render the video of User 16778240 while they were in the session. It only attempted to call attachVideoafter User 16778240 had already left the session, at which point the method threw an error indicating that the user is not sending video.
Aside from this case, rendering video using attachVideo for User 16783360 and User 16782336 worked without issues.