Meeting SDK Type and Version
Meeting SDK for Linux, x86_64, 6.7.5.7391. Headless bot, no UI. Our client is a port of the official meetingsdk-headless-linux-sample.
Description
We publish a composited branded tile from a headless bot via IZoomSDKVideoSourceHelper::setExternalVideoSource, sending I420 frames with sendVideoFrame at 1280x720.
When a viewer pins the bot’s tile it is delivered at 1280x720. The same tile in gallery view is delivered at 640x360. The 720p layer is therefore published and Zoom will serve it, gallery viewers request the smaller layer.
The HD video guidance says equal-sized gallery tiles are expected to render at 360p. However, a third-party notetaker bot, also a Meeting SDK app publishing raw video, is delivered 1280x720 at gallery tile size, same receiving client, same meeting size, same displayed tile size, unpinned. A sender can evidently influence which layer a small tile receives.
Two questions
-
Is this specific to the LINUX Meeting SDK? Do the Windows or macOS Meeting SDKs behave differently for an external video source in gallery view? We can only test Linux.
-
What determines which simulcast layer a gallery viewer requests for a stream published from an external video source, and what on the sending side influences it?
Error
No error. Every call returns SDKERR_SUCCESS. Capability negotiation is correct:
onInitialize suggest=1280x720@25
cap[0] 320x180@25
cap[1] 640x480@25
cap[2] 1280x720@25
video send: 1280x720
Troubleshooting Routes
All settings below confirmed applied by reading the value back, not by trusting the return code. All delivered 640x360 in gallery:
• EnableHDVideo(true): IsHDVideoEnabled() returns true
• EnableAlwaysUseOriginalSizeVideo(true): IsAlwaysUseOriginalSizeVideo() returns true
• SetVideoQualityPreference Custom 5..10: delivered 7fps
• SetVideoQualityPreference Custom 19..20: delivered 21-23fps
• SetVideoQualityPreference named mode 1: delivered 25fps
• SetVideoQualityPreference named mode 2: delivered 25fps
• Writing suggest_cap.frame back in onInitialize: ignored, delivered 24fps
• Joining with a ZAK vs joining anonymously: identical
• Sending a completely STATIC frame: no captions, no animated indicator, every frame byte-identical to the last. Identical result. Content is not the variable either.
Account is Zoom Workplace Pro with Meeting-HD Video Quality enabled and locked on at account level. Receiver statistics show 0.0% packet loss, 214 ms latency, so this is not bandwidth adaptation. Zoom Support closed our case as “configuration-related” without identifying which configuration.
Existing threads searched, none of which answer this:
• Meeting SDK (Linux) doesn’t propose HD video capability,
/t/meeting-sdk-linux-doesnt-propose-hd-video-capability/103660
Resolved by requesting a “Meeting SDK For Web 720p” account flag. That reporter also called EnableAlwaysUseOriginalSizeVideo(true), exactly as we do, but their support_cap_list topped out at 640x480. Ours proposes 1280x720 and we send it, so whatever gated them is not gating us.
• Linux SDK resolution with single user max at 360p,
/t/linux-sdk-resolution-with-single-user-max-at-360p/109063
unresolved. Concerns RECEIVING raw data at 640x360 rather than sending. Staff asked the reporter to retry with 3 users; no explanation given. A reply lists full-screen window as an HD prerequisite, which is consistent with our pinned reading, but nothing addresses gallery.
• video output is only 640x360,
/t/video-output-is-only-640x360/136911
same symptom on an account with HD enabled. ZERO replies.
The closest match is the first, and its diagnostic, “does the SDK propose 720p?” comes back positive for us, so whatever gated that reporter is not gating us. None of the five explains why a gallery viewer receives 640x360 from one Meeting SDK sender and 1280x720 from another under identical conditions.
How To Reproduce
-
Build meetingsdk-headless-linux-sample with an external video source registered via setExternalVideoSource, sending 1280x720 I420 frames.
-
Join a meeting with it. Auth: Meeting SDK app (General App), JWT SDK signature, SDK_UT_WITHOUT_LOGIN. A ZAK makes no difference.
-
One human joins with camera OFF, so the Zoom client’s single reported Receive stream is unambiguously the bot’s.
-
On that human’s Zoom desktop client (macOS 6.x): Settings → Statistics → Video → Receive, gallery view. Reads 640x360.
-
Pin the bot’s tile. Read again. Reads 1280x720.
No errors at any step. The only variable between 4 and 5 is pinning.