BigBlueButton video rendering on android webview

[apurva...@tpv-tech.com]

Hi,

We have a Ubuntu 16.04 based server with default bigbluebutton installation (done using bbb-install.sh) . We are using the HTML5 client to join meetings from android mobile device.

1. When we use the default Chrome browser - we are able to see the video from other participants on the mobile device. Other participants may be either on Chrome/Firefox on a Windows/Linux laptop.

2. When we use an android webview based application and try to join the same meeting - the video is not rendered at all. We just see a default play button.

We have enabled the following settings on webview:

* setJavaScriptEnabled

* setDomStorageEnabled

* setMediaPlaybackRequiresUserGesture

Is this a known issue? Are there any solutions / workarounds that can make it work on android using webview. 

Regards,

Apurva

[Fred Dixon]

Hi Apurva,

I'm not an Android developer, but did some googling and found this

   https://github.com/fluttercommunity/flutter_webview_plugin/issues/138

Regards,... Fred

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

--

BigBlueButton Developer

http://bigbluebutton.org/

@bigbluebutton

[apurva...@tpv-tech.com]

Hi Fred,

Thanks for the quick response. We have already enabled the specified permissions for the android app. Those permissions are required for allowing the android application to access the camera / mic on the device.

Our issue is that the android webview is not able to render the "remote video". Further investigation seems to reveal an isuse with ICE candidates. Please refer to the attached image where we have compared the server side log between the working case (on Android Chrome) vs. non-working case (on Android Webview). It seems that the ICE candidates were not "offered" for the webview clien:

We are hosting this server on EC2 and we have made changes to enable IPv6 with BBB according to http://docs.bigbluebutton.org/install/install.html#configure-bigbluebuttonfreeswitch-to-support-ipv6 

Are there any other known areas / configurations that we need to do?

Regards,

Apurva

[Fred Dixon]

Hi Apurva,

While I'm not an Android developer, hopefully others who are can chime in and help out with your question.

Regards,.. Fred

[apurva...@tpv-tech.com]

Hi Fred,

As mentioned earlier - this is does not appear to be related to an android application part. The issue seems to be related to an incomplete list of ICE servers offered for the webview based client. The "right" part of the image shows the ICE candidates offered to webview client, while the left side shows the ICE candidates offered to the Chrome browser.

Based on your recent announcement, we also tried installing a separate TURN server. But with that we are seeing timeout errors (1006) consistently.

We are using html5 client as we want to be able to use the application on a mobile platform. 

Our suspicion is related to discovery of STUN servers - which is managed by the NodeJS scripts inside BigBlueButton html5 client. Could you please help us check on this?

Regards,

Apurva

[Chad Pilkey]

Both of the clients would be grabbing the STUN servers from the same location on the server. You should see a request to "https://<server>/bigbluebutton/api/stuns?sessionToken=<token>" in your browser's network tab. The gathering of ICE candidates is handed off to the browser code and it handles all of the actual gathering. That ICE gathering call is often sandboxed or protected. I've never tried to load the HTML5 client in a webview, but I would look to the webview logs for any other errors or security warnings before that SDP is logged.

[apurva...@tpv-tech.com]

Hi,

After some debugging, we realized that android webview/webrtc combination doesn't work if video stream is h.264 encoded. Kurento was configured to force h.264 video streams from all participating devices. 

Once we disabled this configuration - the android webview/webrtc combination started working well. 

We changed the following configuration for this purpose

file: /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml

webcam-force-h264: false

screenshare-force-h264: false

Does this change have any additional impact, other than the obvious impact of load caused by transcoding?

Regards,

Apurva

[Chad Pilkey]

The transcoding load and delay should be the only impact.

[Paulo R. Lanzarin]

Just complementing what Chad said: occasional transcoding. VP8 will be preferred, h264 should only happen on iOS (for now).