To meet the 9-month window, we have updated Meetings SDK from 5.0 to 5.5 and tried 5.7.6. We cannot move to 5.7.6 because on Android the video quality (send from Android to Zoom Client (mac or Windows) reduces to 270p or 180p. In addition, the Gallery layout was arbitrarily rearranged and now does not center top to bottom nor side to side.
Which Android Meeting SDK version?
5.0 → typical send and receive at 360p minimum
5.5 → typical send and receive at 360p but need to set deprecated ‘setEnable720p(true)’ param.
5.7 → typical send at 180-270p and receive at 360p
5.5 and 5.7 have the changed layout, which is only on android.
To Reproduce(If applicable)
Steps to reproduce the behavior:
To verify it wasn’t us, we used the ‘sample’ app that comes with the SDK
On 5.5, as the sample app is, the problem with only sending 180 / 270 is seen.
To fix, add setEnable720p(true)
I’ve tried testing this, but was unable to reproduce the behavior you are seeing regarding the lower resolution. Can you please clarify around how you are checking the sending/receiving ends of the resolution? Also, are you joining on multiple devices through the SDK or using a combination of the SDK and Zoom client to test?
In addition, the Gallery layout was arbitrarily rearranged and now does not center top to bottom nor side to side.
Any changes made to the default UI are dictated by the Zoom client’s design. If you have feedback regarding the functionality of the Zoom client, we would love to hear from you over at Sending feedback to Zoom - Zoom Support.
Hi Jon,
The simple test is to Start a zoom meeting using the Zoom Client on a computer. Join the meeting from the DUT which is running the sample app. Using the stats info pane on the client, compare send and receive.
– Following the Zoom requirements for “HD” video, we set the computer to maximize the window (green button on MacOS). We set view to Active Speaker.
– For the account used to Host the meeting, we try both PRO(named host) and FREE.
– Options for HD in settings are enabled.
– participants are always anonymous
We generally ‘see’ the quality and use the stats panel to verify. Happy to share logs or anything else.
Thanks for the additional information. I’m not sure why we are seeing different behavior with the same steps to reproduce. We’ll need the SDK logs to investigate further. If you weren’t aware, the SDK logs can be found at sdcard/Android/data/${YOUR_PACKAGE_NAME}/logs. The contents of the log file will be encrypted. Let me know if you run into any issues with retrieving the logs and I will be happy to help.
Hi Jon,
I’ve got two zipped log file directories (I know they rotate, but didn’t trust not including all).
Everything is same, as far as the meeting we’re joining. I didn’t make the one where we don’t use enable720p on the 5.5 sdk. Neither sends at 720p, but the 5.7 (connected two times) clearly does worse on the receive side. Thanks.
After investigating the logs, it seems that the SDK is sending 480p video. Since we’re unable to reproduce the behavior and do not see any evidence of the issue you are describing in the SDK logs, it is possible that this is an issue with the client you are using. To start, you could try updating the client to the latest version, but I would recommend reaching out to the regular support team through the Help Center.
If you have any additional evidence indicating that this is indeed an Android SDK issue, please let me know and we can investigate further.
Thanks @jon.zoom ,
Is it possible to query the SDK to see what reason it chooses the resolution? In these examples, the 5.7.6 SDK is advertising to RECEIVE only 360 or 270p, and at times only 180. The 5.5 SDK requests 360p. Is there a way to see if it ‘knows’ it is in full screen? Maybe the way we do things interferes with the SDK matching the conditions to request 720 (ie, full screen and active speaker mode).
Jerry
Unfortunately I do not believe something like this will be possible. The logic used to determine the bitrate is dynamic and somewhat complex, so it would not be easy to determine the reasoning for a given moment in time when it could potentially change a fraction of a second later. Yes, there are static factors such as account & meeting settings, but if what you are experiencing was a bug related to those settings, we would very likely see uniform behavior throughout the entire meeting rather than the fluctuations you have observed.
As always, please let me know if there is any additional information that will enable us to investigate this behavior further and I will do my best to help.
