Unable to get valid video data(`yuv`) using Meeting SDK for Linux when subscribed to `RAW_DATA_TYPE_SHARE`

Meeting SDK
1

Meeting SDK Type and Version
zoom-meeting-sdk-linux_x86_64-6.1.1.493

Description

I cloned meetingsdk-headless-linux-sample from github and created an application that allows a bot to record audio and video using the Meeting SDK for Linux.

Then, to capture screen sharing data as well, I added the following line to perform the recording:

err = m_videoHelper->subscribe(uid, RAW_DATA_TYPE_SHARE);

However, I thought that the recorded data might not be valid. When I examined the contents of the data, it looked like this:

% head -c 100 out/meeting-video.yuv | xxd 
00000000: dddd dddd dddd dddd dddd dddd dddd dddd  ................
00000010: dddd dddd dddd dddd dddd dddd dddd dddd  ................
00000020: dddd dddd dddd dddd dddd dddd dddd dddd  ................
00000030: dddd dddd dddd dddd dddd dddd dddd dddd  ................
00000040: dddd dddd dddd dddd dddd dddd dddd dddd  ................
00000050: dddd dddd dddd dddd dddd dddd dddd dddd  ................
00000060: dddd dddd                                ....

When I save the user’s video like this:

err = m_videoHelper->subscribe(uid, RAW_DATA_TYPE_VIDEO);

The data is valid, and I can convert it to mp4 and view the user’s video properly. Is there some additional configuration needed to successfully capture the screen sharing data?

Would you like me to provide any analysis or explanation of this situation?

cc: @chunsiong.zoom

2

@ka.baseball1997 you need to use 2 seperate methods to capture 2 “videos”. One is user video, one is sharescreen

3

Hey @ka.baseball1997 ,

As Chun Siong mentioned, you’ll want to use two separate methods for capturing 2 videos.

Concretely, you’ll likely want to use multiple ZoomSDKRendererDelegate’s, where one of these is subscribing specifically to the screenshare.

For instance:
videoHelper->subscribe(userID, RAW_DATA_TYPE_SHARE);

If you didn’t want to worry about these sorts of details, another alternative is to use the Recall.ai API for your meeting bots instead. It’s a simple 3rd party API that lets you use meeting bots to get raw audio/video from meetings without you needing to spend months to build, scale and maintain these bots.

Let me know if you have any questions!