Description
While exploring the Meeting SDK Electron Wrapper, we are consistently encountering the SDKRawDataError.SDKRawDataError_NO_SHARE_DATA error from zoomRawData.Subscribe. Below is the relevant portion of the code I am using (in src\assets\ts\rawdata\video.ts line 43):
const handleSubscribeVideo = (resolution: number, recv_handle: number, subscribeId: number) => {
let obj = {resolution, recv_handle}
let ret = zoomRawData.SetRawDataResolution(obj)
let subscribeObj = {
subscribeId,
rawdataType: ZoomSDKRawDataType.RAW_DATA_TYPE_VIDEO,
recv_handle: recv_handle
}
ret = zoomRawData.Subscribe(subscribeObj)
if (ret == SDKRawDataError.SDKRawDataError_SUCCESS || ret == SDKRawDataError.SDKRawDataError_NO_VIDEO_DATA) {
subscribedVideoList.value[recv_handle] = zoomMeetingParticipants.GetUserInfoByUserID(subscribeId)
}
}
I was wondering if there is any permission that I might be missing in order to access and display the raw video stream here.
Could you please help me understand if any additional configuration or permissions are required from my end?
@Sarang before you can subscribe to raw data (video, audio or sharescreen), you will need to have recording permissions, and then you will need to call startrawrecording before you and subscribe to the stream.
I have successfully implemented startRawRecording and also added the RequestLocalRecordingPrivilege method to request local recording permission.
After this implementation, I am able to see participant names appearing on the tiles. However, the video frames are not being rendered. The tiles remain black while only the participant names are visible.
From the logs, I can see that onRawDataStatusChanged is triggered with a success status. However, the onRenderVideoRawDataReceived callback—which should provide the video frames for rendering—is never triggered.
There are no errors being reported in the logs.
Could you please help me understand what might be missing here?
@Sarang did you implement an instance of IZoomSDKRenderer? You will need to pass the IZoomRendererDelegate and IZoomSDKRenderer into the createRenderer method in zoom_rawdata_api.h.
This is the windows sample, but it works in the similar workflow for the different platforms
SetonRawDataStatusChangedCB fires with RawData_On (0), confirming the SDK is sending data
The Problem:
After all the above succeed, SetRenderVideoRawDataCB sometimes never fires — no video frames reach the renderer process. This happens intermittently; sometimes it works, sometimes it doesn’t.
What We’ve Traced:
We believe the issue is in the native addon’s pipe server/client architecture:
The SDK’s IZoomRendererDelegate::onRawDataFrameReceived delivers YUV420 frames to ZoomNodeRawDataHelperMgr::onRawDataFrameReceived
That function checks _g_video_pipe_server._uv_ipc_server.HasClientConnected() before sending data
If the pipe client (in the renderer process) hasn’t connected yet, frames are silently dropped with no error or log
After StartRawRecording, the pipe server may be recreated or reset, but the pipe client in the renderer process doesn’t know it needs to reconnect
My Workaround:
We stop and restart the pipe client (StopVideoClient / StartVideoClient) after StartRawRecording succeeds, re-register SetRenderVideoRawDataCB, and add a 1-second delay before calling Subscribe. This improves reliability but doesn’t guarantee it, because there’s no way to verify the pipe client has actually connected before subscribing.
Questions:
Is there a callback or method to confirm the pipe client has successfully connected to the pipe server before subscribing?
Is there a recommended initialization order between StartRawRecording, CreateRenderer, pipe client start, and Subscribe that avoids this race condition?
Should onRawDataFrameReceived queue/buffer frames when the pipe client isn’t connected yet, rather than dropping them silently?
Is there an SDK configuration to auto-reconnect the pipe client when the pipe server restarts?
The pipe client has no connection confirmation mechanism and silently drops frames.
I also checked the Windows SDK wrapper, and the intermittent frame dropping we are experiencing only exists in the Electron SDK because of the pipe IPC layer. The Windows SDK delivers frames directly via callback with no intermediary. So this problem is specifically in the Electron SDK’s pipe architecture.
If you have any guidance on the correct initialization sequence or a more reliable way to synchronize the pipe client connection, that would greatly help me.