WindowsSDK normal video render bug with many users

I have an interesting problem with the windows SDK using the custom UI, when I render many different videos at once some of the videos will not render if I request a large size for that video. So for example if I have 11 normal videos rendered on a single window of my application some of those videos will not render until I have resized them to a specific small size. To demonstrate this I have modified my app to fill the full window size with the video renderers and resize each video element as the window resizes. I have posted a link to a recording of this in action below.

There seems to be a magic number that each video must first be sized to before the video will start rendering. Additionally, that video size seems to change based on the number of participants in the meeting. For example, using the example I give below, once there are around 10 or 11 videos, any video renderers added after a certain point MUST first be resized (using the SetPos() function) to around 140px wide before they will start rendering. Once those videos are sized at or below 140px wide the video will begin rendering, at that point you can make the videos as large as you want.

I have recorded a video of this happening and posted below

Which Client Desktop SDK version?
C# Wrapper

To Reproduce(If applicable)
Steps to reproduce the behavior:
Here is a detailed description of the scenario:

  1. Render 11 Normal videos in one video container (see POSITION A below for exact render positions of each video)
  2. Notice as in the start of the attached screen recording the videos on the right panel do not render at this size (We never receive the video status event “Video_ON” for these users.)
  3. Change the video renderer positions to the updated POSITION B positions of each video
  4. Notice that the videos now correctly begin rendering. We receive a “Video_ON” video status event from the SDK for the videos that did not initially render
  5. We are now able to change all the video renderers back to their original larger position (POSITION A) and the videos continue to work

Video of the bug in action:

All I’m doing in this video when resizing the window is calling SetPos(newPos); on each INormalVideoRenderElement with the position RECT values mentioned below in the “Additional context” section

Device (please complete the following information):

  • OS: Windows 10 19041.804

Additional context
Render positions of each video:
POSITION A: Starting positions (Some videos do not render)
(Test50 Bright):RESIZING right:1784 bottom:206 left:1592 top:10
(Test47 Bright):RESIZING right:1784 bottom:991 left:1592 top:795
(Test48 Bright):RESIZING right:1784 bottom:598 left:1592 top:402
(Test45 Bright):RESIZING right:1054 bottom:498 left:538 top:3
(Test46 Bright):RESIZING right:1784 bottom:402 left:1592 top:206
(Test42 Bright):RESIZING right:1227 bottom:997 left:884 top:502
(Test40 Bright):RESIZING right:533 bottom:997 left:3 top:3
(Test43 Bright):RESIZING right:1573 bottom:498 left:1057 top:3
(Test41 Bright):RESIZING right:1574 bottom:997 left:1231 top:502
(Test49 Bright):RESIZING right:1784 bottom:795 left:1592 top:599
(Test44 Bright):RESIZING right:880 bottom:997 left:537 top:502

POSITION B: Resized positions (When the videos reach this size they all render properly)
(Test50 Bright):RESIZING right:1405 bottom:149 left:1269 top:10
(Test47 Bright):RESIZING right:1405 bottom:705 left:1269 top:566
(Test48 Bright):RESIZING right:1405 bottom:427 left:1269 top:288
(Test45 Bright):RESIZING right:839 bottom:356 left:428 top:2
(Test46 Bright):RESIZING right:1405 bottom:288 left:1269 top:149
(Test42 Bright):RESIZING right:977 bottom:713 left:704 top:359
(Test40 Bright):RESIZING right:424 bottom:712 left:2 top:2
(Test43 Bright):RESIZING right:1253 bottom:356 left:842 top:2
(Test41 Bright):RESIZING right:1253 bottom:713 left:980 top:359
(Test49 Bright):RESIZING right:1405 bottom:566 left:1269 top:427
(Test44 Bright):RESIZING right:701 bottom:713 left:428 top:359

1 Like

Hey @wcarle,

Thanks for using the dev forum! It is nice to see you again :slight_smile:

Thank you for providing the video! Hmm that is an interesting problem. Would you be able to send your SDK logs over to so that I can forward them to our engineers for investigation? Please include a link to this post in your email.


Thanks for the quick response @Michael_Condon !
Here’s a link to the log files from my debugging today:

The very last items in that log should be from when I took the attached video

1 Like

Hi @wcarle,

Thanks for providing the logs. We will investigate this and let you know once we have an update or need more information.


Just wanted to give an update, I spent all day trying to debug this. I was able to get the initial users in the meeting to render by doing the following:
Instead of looping through the users subscribing them then setting their position, I instead loop through and subscribe them first then later set the position. Essentially this was the difference:

This does not work:

    for (int i = 0; i < userCount; i++)

This does work:

    for (int i = 0; i < userCount; i++)
    for (int i = 0; i < userCount; i++)

However this only solves the problem for the users that are already in the meeting when my app joins. If a new user joins and their video position is too large then the video will not render until I set the position to a small size first.
Here is a recording of that behavior, as you can see, all the videos are rendering properly until a new user comes in. That new user’s video doesn’t render until I shrink it’s size via SetPos to roughly 458x765 as I am resizing the window:

Here are the logs for that latest test session as well if you’d like them:

1 Like

Hey @wcarle,

Thank you so much for the thorough explanation, videos, and logs! This makes our lives so much easier.
I have filed a bug report for this, and will let you know what I hear from the engineers about this.


@Michael_Condon Any movement on this? We’re running into this more and more as we add features to our app. Would love to know if there’s even a good workaround for this problem. Thanks!

Hey @wcarle,

I have not heard back about this yet, I will ping them again.