Description
I am seeing poor video performance (stuttering and low frame rate) with the Meeting SDK
(version 5.7.6.1918) on a custom Android system based on the TI AM5728 processor.
This is a dual-core Cortex-A15 processor running at 1.5 GHz.
Based on the low performance, it appears that the Zoom SDK may be using a software-based
video codec. This platform does have a hardware-accelerated video codec available, by calling e.g.
MediaCodec.createByCodecName(“OMX.TI.DUCATI1.VIDEO.DECODER”).
Is it possible to configure the Zoom SDK to use the HW video codec?
Which Mobile Meeting SDK version?
5.7.6.1918
Smartphone (please complete the following information):
Since the processor used by your device is only slightly above the minimum system requirements for running the Zoom client, it is not surprising that the performance is less than ideal. While the requirements listed on that page are for the Zoom client, they should be pretty closely aligned with what is required for the SDK.
The codec used by the SDK is actually defined by a shared component which is also utilized by the Zoom client. For that reason, this behavior is inherited by the client and may not be possible to modify for the SDK (I also am unsure if our proprietary tech will work with that codec, but we can cross that bridge when we get to it). I’m happy to look into confirming this, but first I’d like to see if you can run some tests to get more information around your device’s performance and see if we can find a more immediate solution.
When you ran the SDK on your device, was this the sample app included in the SDK package or your own implementation?
Were you using the SDK’s default UI, or a custom meeting UI?
Are there any particular scenarios in which the performance issues are exacerbated? For example is it worse when using gallery view or active speaker view? What about when navigating the in-meeting menus?
How does the SDK performance compare to the performance of the client? If the client does not run into any issues on this device, that could indicate that there are optimizations that must be made in the SDK.
Of course, if you have any additional details not mentioned here that you think would be useful, let me know.
This is a customized app that a coworker developed; I believe he used the sample app as a starting point though.
We are extending the MeetingActivity class – does that answer the question?
Changing views doesn’t make a significant difference, nor does navigating in-meeting menus.
The performance of the official Zoom app is pretty similar.
I am seeing a maximum of about 15 frames per second in either direction.
It’s also not a steady 15 fps – sometimes there are longer delays between frames, more like 6-8 fps.
I believe (not 100%) sure that the video quality is running at 360p.
For comparison, we have also run a custom (non-Zoom) video streaming app on this same platform.
With that app, we have found that using the HW-accelerated H.264 codec gives much better performance.
Using the HW codec, we can stream 720p video at 30 fps with no problem.
Since you are using the default UI (the MeetingActivity you mentioned contains the default UI) and seeing similar performance when compared to the Zoom client, I’d like to see if we can rule out some variables and compare the performance to a very simple custom UI implementation. Enabling custom UI is done through a flag which prevents the MeetingActivity from being started. Would you be able to run a quick test with this mode, using a simple UI containing only one MobileRTCVideoView? I’m happy to help setup the test app for this if needed, just let me know.
I can definitely throw together an extremely basic app to test the video performance. Would it be alright if I sent that directly to the email associated with your developer forum account?
I was able to get the demo working on our device! Thanks for sending that over.
With the demo, I’m also seeing about 15 fps in both directions. It’s possibly a little steadier than with the full MeetingActivity (i.e. fewer drops below 10 fps) but I’d have to do more tests to be certain.
The processing appears to be CPU-bound, the same as before – top reports com.example.performancetest at 50-55% (i.e. 100-110% of one core, I believe).
My theory would still be that the bottleneck is the video encoding/decoding. Am I correct in assuming that the SDK is currently using a software-based video codec?
Thanks for checking that! It seems that it will be difficult to improve the performance on that device with the current implementation in the SDK. Since there was a slight improvement with a simple UI, it is possible that the Video SDK could perform even better. Do you think that you could consider using the Video SDK for your use case, or do you need access to the Zoom Meeting ecosystem?
Unfortunately since our streaming stack is mostly proprietary tech, I am limited in what information I can share. Right now, the best we can do is to investigate whether or not this is something that we could potentially improve in a future release. I’ll be sure to keep you updated on that front once we have additional information.
