Description
Our application, using the Zoom SDK [Specify SDK version, e.g., Web SDK 2.x.x], experiences an issue where the initial video stream from certain webcams (specifically HIKVISION cameras) is delivered at 640x480 resolution. This 4:3 aspect ratio causes the video to appear distorted when displayed, as the expected resolution is 1280x720 (16:9).
Interestingly, if the camera is turned off and then back on during the same SDK session, the video stream subsequently and correctly provides the 1280x720 resolution.
This behavior is device-specific; other webcams (e.g., built-in laptop webcams, Logitech cameras) correctly stream at 1280x720 from the beginning.
Browser Console Error
N/A Which Web Video SDK version?
2.1.0
Screenshots
Device (please complete the following information):
I am experiencing an issue with my HIKVISION webcam concerning an unexpected change in video resolution. Specifically:
Initial Setup: When the webcam is first connected and initialized, the video stream received (e.g., in a browser or Zoom) has a resolution of 640x480.
After Power Cycling the Webcam: If I turn the webcam off and then on again, the subsequent video stream received has a higher resolution of 1280x720.
I suspect the issue might be related to how the browser or Zoom application handles or negotiates the video stream with the webcam after the device is re-initialized.
I found documentation for the Zoom Video SDK that references CaptureVideoOption. This option includes the ability to configure capture height and capture width in the startVideo function, but this is for version 2.2.0, while we are using version 2.1.0.
I would appreciate your assistance in identifying the cause and a potential solution for this problem.
This option includes the ability to configure capture height and capture width in the startVideo function, but this is for version 2.2.0, while we are using version 2.1.0.
We only keep the reference documentation for the latest version of the Video SDK Web on our website. However, most of the method parameters are inherited from previous versions.
If you want to be certain about what’s available, you can refer to the dist/types directory in the package. This contains the full type definitions for all methods and properties — and it’s also what our documentation is generated from.
By the way, it’s not recommended to set the capture width and height in the startVideo method unless you’re targeting a specific device with a customized resolution. In most cases, the hd or fullHd option should suffice.
I tried using the hd option, but it didn’t work.
Upon debugging by console logging the settings and constraints on the preview screen, I observed that the device’s capabilities are 1280x720, but the default setting being applied is 640x480. Consequently, the browser defaults to a 640x480 video stream. When this stream is assigned to a video element with a 16:9 aspect ratio via localVideotrack.start, the video appears stretched.
Next, I tried applying constraints directly to the localVideotrack on the preview screen (before joining the meeting), and it worked as expected—at least on the preview screen.
Here is the code I used:
await track.applyConstraints({
width: { ideal: 1280 },
height: { ideal: 720 },
frameRate: { ideal: 30 }
});
When I join the meeting, my code no longer uses localVideotrack directly but instead utilizes state.mediaStream.renderVideo(...). Even though localVideotrack is stopped, the video renders correctly (not stretched) most of the time. However, it still occasionally becomes stretched. I suspect that when the new constraints are applied in the meeting, the browser “remembers” these new constraints and applies them in subsequent sessions.
I don’t fully understand this inconsistent behavior. I would like to gain a deeper understanding of the underlying mechanism to ensure it works correctly 100% of the time in the future. Could you please help explain this or provide any relevant documentation?
