opentok-react-native
opentok-react-native copied to clipboard
Phone gets very hot quickly during the video call
Apologies for not using the standard bug template, but somewhat this issue seems a bit different:
While testing video calls on various iOS and Android phones, we've noticed the phone gets very hot quickly.
It seems to directly correlate with number of video streams, but it gets very warm already even with 2 participants.
It seems it's much warmer comparing to other video chat apps (Zoom, Skype, Facetime, Messenger).
Has anyone else observed it?
@og2t Thanks for filing an issue. Could you please share some of the following information?
- Device & OS version
- SDK version
- OTRN version
Hi Manik, here are the details:
- Device & OS version:
iPhone X/6, iOS 12.3.1 - SDK version:
2.16.0 - OTRN version:
0.11.1
Thanks! /Tomek
This also happens with my Samsung Galaxy S10.
I also get this issue, using an iPhone XS and an iPhone 6. I'm just using the iOS SDK version 2.14.2 - not using react native.
@og2t Using the video camera and subscribing streams consumes memory and increases the CPU usage. Could you confirm if this is happening to you when you run a native iOS sample app using Opentok iOS SDK? You can test the opentok demo app.
This is also an issue with us, and it seems to most deeply impact Android devices. I'll also add that for longer sessions (~20-30+ minutes) some of the client devices would stop the call, and it seems to correlate with temperature (the phone gets difficult to hold).
One thing I am trying is switching from the VP8 codec to the H.264 codec in the TokBox console (https://tokbox.com/account/). It supposedly uses less CPU, especially on iOS (https://tokbox.com/developer/guides/codecs/)? I'll let you all know if it makes a difference, but @og2t @knavu2 @yusuftor you may try too if you wish, and we can share what we find out on this thread.
@sunweiyang Interesting with the codec switch, didn't know about that. Please let us know your findings.
There are several tradeoffs when using H264 v VP8. H264 support on Android devices isn't very great. You also won't be able to leverage TokBox Scalable video with H264.
Some things you can do to improve CPU & battery consumption is:
- If you know the rendering size, do not capture HD qualities since it's very likely that you won't be rendering HD on the subscriber side.
- If it's for multiparty, we'll leverage TokBox Scalable Video, but you can optimize this further by requesting a lower resolution for the subscribers if you are rendering in a smaller view. This helps because you will not receive as high of a bitrate meaning less consumption of bandwidth and less computing on the decoding of the stream. Also will help since there won't be any downscaling of the image (less CPU)
We don't support these properties in this library at the moment, but if this is a priority, I can help get it added. Hope this helps :)
TokBox Scalable Video: https://tokbox.com/developer/guides/scalable-video/
@msach22 How do we have subscribers request lower resolution? And what do you mean by "capture HD qualities"? I don't see this documented (but I could have accidentally missed something).
My understanding so far is that OpenTok intelligently selects a video resolution based on the current connection quality of the clients. Is the current built-in logic not performing well for certain low-bandwidth situations? And if that's the case, is there a way to optimize this sliding scale?
EDIT: @msach22 I missed the fact that you said these props aren't supported in this library yet. Yes please!
@sunweiyang When you are creating the publisher, you have that ability to specify the resolution - I was suggesting that if you are not going to be rendering in a big view, then you may not need to capture at 1280x720 (HD).
OpenTok does intelligently route different qualities based subscriber, but it gives you the best quality available. Now, if you application is rendering in smaller views, you do not need to receive HD - you can set a preferred resolution to receive VGA or even QVGA.
@msach22 Can you please add these props(resolution & frameRate) which aren't supported in this library?
@anshulsinghla I was able to set the resolution and audioBitrate props for OTPublisher. I don't think I see a way to set frame rate, but I could be wrong.
@sunweiyang I'm working on a PR that will add this feature on the Subscriber component 👍
@sunweiyang How did you set the resolution and audioBitrate and does this help you?
@ankitbishtapollo Documentation is here in opentok-react-native's docs directory: https://github.com/opentok/opentok-react-native/blob/master/docs/OTPublisher.md
<OTPublisher
...
resolution={"640x480"}
audioBitrate={30000}
...
/>
We're still collecting data, but so far it does suggest at least some improvement.
@sunweiyang Thanks for sharing and also if you find something relevant to this ticket. Please share with us.
@msach22 Even with resolution lowered to 640x480 and audioBitrate lowered to 20000 (2 users per session, using VP8 codec), phones are still becoming too hot to hold after around 25 minutes, especially on Android. Are there any other things that we can do?
@sunweiyang In general, phones can run hot with video chat especially on lower end devices - WebRTC is known to be computationally expensive. In general, I would not lower the audio bitrate because it might lead to poor audio quality especially when there is packet loss. Is there any specific device this is happening on? We can try to profile it internally and see if we can improve some areas.
For multiparty apps, it will help to use the preferredResolution & preferredFrameRate APIs (we're working on releasing this for React Native).
@msach22 Thanks for looking into it internally, that's fantastic. We have reports of this happening in the past week for phones ranging from Samsung Galaxy S8 (released March 2017) to Pixel 4 XL (released October 2019). We're using opentok-react-native 0.14 and RN 0.62.2, with OTPublisher at 640x480 resolution, 20000 audioBitrate, 2 users per session, and VP8 codec.
In our own testing with our suite of devices, Android generally heats up more significantly than iOS, but both are experiencing heating noticeably more than other mobile video apps (i.e. Skype, Zoom, Messenger, etc.).
Final question: to clarify, OTPublisher's resolution prop isn't the same as the preferredResolution API you mentioned?
EDIT: I should mention that ideally we'd define a maximum resolution/audio bitrate to not be exceeded, and also have OpenTok step down the resolution/bitrate even further as needed based on network conditions. Do the OTPublisher resolution and audioBitrate props not do this?
Facing same issue. Using 4G Jio network with Oneplus 6. Experienced the same issue on the Oneplus 7T. No special app running in the background, normal apps like Whatsapp etc. Before I started the call with 15% battery. Battery current: less than ~300 ma Battery temperature - ~36 C ~3 min into the call - 2 % battery Consumed, the phone was heated up Battery current: 1065 ma Battery Temp: 41.4 C
~5 min into the call - 5% battery consumed, the phone was super hot Battery Current: 1554 ma battery temp: 44.8 C.
@sunweiyang Final question: to clarify, OTPublisher's resolution prop isn't the same as the preferredResolution API you mentioned?
OTPublisher is the resolution that is acquired by your device and sent to our media server (if you're using Routed Session).
Once the stream is processed by our media server, it has to sent it back to all the subscribers of the session. The media server will send different qualities to the subscribers based on bandwidth estimation and other factors Opentok Simulcast
But, the developer can programmatically set which resolution and frameRate wants to receive for each subscriber using preferredResolution and preferredFrameRate
@enricop89 Can you tell me how to use setPreferredResolution please?
@ankitbishtapollo setPreferredResolution is not currently supported.
I'm currently working on a PR to add the option on the OTSubscriber.
<OTPublisher properties={{ resolution: '640x480', }} eventHandlers={publisherEventHandlers} />
I was manually setting resolution like this but I dont see ant changes on the video quality. Not sure, if its a correct ways to lower down the resolution.
@enricop89 Any early scope of your PR approval?
I am publishing with 640x480 resolution but I dont see much impact. There has only been a slight improvement but its still heating. If anybody has fixed this or has seen much improvement then please let me know.
@anandpaithankar1 feel free to test #434
@anandpaithankar1 feel free to test #434
Maybe its for @anand-opentok
lol sorry it was for @ankitbishtapollo