HTML5 client - Webcam not working on Chrome/Android

[JVieille]

Whenever I whish to share the phone webcam, I get immedialely "Error on sharing webcam. Check permission", with no option to accept the camera sharing.

I added the permission for the Chrome app to use the camera, and Chrome is set to accept the use of the camera.

Thanks for help

[Chad Pilkey]

Do you see the same permission error if you try test.bigbluebutton.org?

[Paulo R. Lanzarin]

Hey,

The test that Chad mentioned should be helpful.
Could you also paste the output of https://webrtchacks.github.io/WebRTC-Camera-Resolution/ (Quick Scan option)
on the device you're having problems with?

s,

Paulo.

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

[JVieille]

The behaviour is the same with the bbb test page.

Below the camera quick scan test, which fails on all proposed resolutions.

Full scan gives pass results for all "square" resolutions, like 1080x1080

Quick Scan

Sizes: 4K(UHD) 1080p(FHD) UXGA 720p(HD) SVGA VGA 360p(nHD) CIF QVGA QCIF QQVGA

Full Scan

vertical resolution range: 
max: 1080 to min: 1

Jump to bottom of table

Browser	Device	Res Name	Ratio	Ask	Actual	Status
chrome 67	camera2 1, facing front	4K(UHD)	16:9	3840x2160	0x0	fail: OverconstrainedError
chrome 67	camera2 1, facing front	1080p(FHD)	16:9	1920x1080	1080x1920	fail: mismatch
chrome 67	camera2 1, facing front	UXGA	4:3	1600x1200	1200x1600	fail: mismatch
chrome 67	camera2 1, facing front	720p(HD)	16:9	1280x720	720x1280	fail: mismatch
chrome 67	camera2 1, facing front	SVGA	4:3	800x600	600x800	fail: mismatch
chrome 67	camera2 1, facing front	VGA	4:3	640x480	480x640	fail: mismatch
chrome 67	camera2 1, facing front	360p(nHD)	16:9	640x360	360x640	fail: mismatch
chrome 67	camera2 1, facing front	CIF	4:3	352x288	288x352	fail: mismatch
chrome 67	camera2 1, facing front	QVGA	4:3	320x240	240x320	fail: mismatch
chrome 67	camera2 1, facing front	QCIF	4:3	176x144	144x176	fail: mismatch
chrome 67	camera2 1, facing front	QQVGA	4:3	160x120	120x160	fail: mismatch
chrome 67	camera2 0, facing back	4K(UHD)	16:9	3840x2160	2160x3840	fail: mismatch
chrome 67	camera2 0, facing back	1080p(FHD)	16:9	1920x1080	1080x1920	fail: mismatch
chrome 67	camera2 0, facing back	UXGA	4:3	1600x1200	1200x1600	fail: mismatch
chrome 67	camera2 0, facing back	720p(HD)	16:9	1280x720	720x1280	fail: mismatch
chrome 67	camera2 0, facing back	SVGA	4:3	800x600	600x800	fail: mismatch
chrome 67	camera2 0, facing back	VGA	4:3	640x480	480x640	fail: mismatch
chrome 67	camera2 0, facing back	360p(nHD)	16:9	640x360	360x640	fail: mismatch
chrome 67	camera2 0, facing back	CIF	4:3	352x288	288x352	fail: mismatch
chrome 67	camera2 0, facing back	QVGA	4:3	320x240	240x320	fail: mismatch
chrome 67	camera2 0, facing back	QCIF	4:3	176x144	144x176	fail: mismatch
chrome 67	camera2 0, facing back	QQVGA	4:3	160x120	120x160	fail: mismatch

 

[Chad Pilkey]

When you load the client you should see a green lock in the top left corner. If you click the lock it should tell you what kinds of permissions you have given to the domain. Just double check that access hasn't accidentally been disallowed.

[JVieille]

It tells about tls/certificate.

Site parameters only mention Sound authorization, no mention of video/camera

[Paulo R. Lanzarin]

Could you go to Settings -> Site Settings -> Camera, clear all permissions related to BigBlueButton if there's any and try again? If it doesn't work, could you try disabling the Ask first toggle and try it again for testing purposes? Don't forget to reenable it after the test.

On Tue, Jul 24, 2018, 12:03 JVieille <jean.v...@gmail.com> wrote:

It tells about tls/certificate.

Site parameters only mention Sound authorization, no mention of video/camera

--

[JVieille]

There is only one site registered is webrtchacks (that I uded for the previous test) - no bbb

The option "Ask first" can only be changed by "blocked" 

[JVieille]

Any possible help?

Android/Chrome : The camera fails about permission whithout even asking for them

IoS/Safari : Permissions are asked for, but fail after accepting

[Mohamed Ben Rhouma]

Same here, I tested it with android tablet and an ipad, the camera keep relowding all the time and never show the video ,somtimes it fails with google chrome
after I accept permission.
I tested it also with an iphone7 evreything is fine with it

--

[Fred Dixon]

Hi Mohamed,

> Same here, I tested it with android tablet and an ipad, the camera keep relowding all the time and never show the video ,somtimes it fails with google chrome

after I accept permission.

Not sure if you've tried this already, can you do a quick test on 

  https://test.bigbluebutton.org/

with the iPad and let us know if you encounter the same issue.  Is the iPad running iOS 11+ (needed for support of WebRTC)?

Regards,.. Fred

--

BigBlueButton Developer

http://bigbluebutton.org/

@bigbluebutton

[JVieille]

I tried several phones under android and Ios with no success, either on my server or https://test.bigbluebutton.org/

Could it be a localization issue ? (not working in some foreign language - here French)

 

[JVieille]

Firefox on Android asks for permission, but fails after too

[JVieille]

Could you please help on this?

The Flash client prevented many users from connecting from their PC, all from their mobile phone.

On my side, the HTML5 client's video sharing currently only works on PCs.

I have asked other people to test, I'll report the findings.

Thanks again for this hard work.

[Fred Dixon]

Hi,

Based on the test at

>  https://webrtchacks.github.io/WebRTC-Camera-Resolution/

it looked like there was a mismatch with all the resolutions.  This may be an issue on our end.

> Quick Scan

> Sizes: 4K(UHD) 1080p(FHD) UXGA 720p(HD) SVGA VGA 360p(nHD) CIF QVGA QCIF QQVGA

It looks like all the resolutions resulted in a mismatch error.  This is likely causing issues with sharing of webcam in BigBlueButton HTML5 client as well.

> I tried several phones under android and Ios with no success, either on my server or https://test.bigbluebutton.org/

This is strange that they all fail.  I just tried a quick test on https://test.bigbluebutton.org/ with my iPhone 8 running iOS 11.4.1 on the Voadfone UK network and it was able to share webcams without error.

Can you confirm that your iPhone has iOS 11+.   

Regards,... Fred

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

[JVieille]

Hi Fred,

Thank you for taking care.

For whatever reason, it works now on iPhone. It is an Iphone 10, with IOS 11

My Android Huawei still fails.

 https://webrtchacks.github.io/WebRTC-Camera-Resolution/ report mismatches, but https://test.webrtc.org/ reports everything ok but one item: 

[ INFO ] Gathered candidate of Type: srflx Protocol: udp Address: 80.15.104.74

[ WARN ] Could not connect using reflexive candidates, likely due to the network environment/configuration.

[JVieille]

My phone runs android 7.0

I tried an older phone with android 5.1 

Summary of my tests:

- iPhone / IoS 11 / Safari : OK

- Android 7.0 / Chrome (Hawei) : fails immediately, complains about permissions

- the same / FF : asks for authorization and faills 

- Android 5.1 / Chrome (Acer): asks for permission and fails

[Fred Dixon]

Hi,

> For whatever reason, it works now on iPhone. It is an Iphone 10, with IOS 11

Glad to hear it's working with your iPhone.  

> My Android Huawei still fails.

There looks like something with mismatch on the resolution.  We'll get you to test again as we keep updating the HTML5 client.

Regards,... Fred

--

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

[JVieille]

I just tried to join a webrtc test room at https://appr.tc

It works perfectly with all my phones

[JVieille]

Video does not seem to correctly work yet.

We have tried other devices, with different problems.

- on my computer, the video fails to setuyp correctly. It is either to clear,; to dark, correct by chance.

- on my android phones, no video sharing is possible as already mentioned

- on different iOS phones, it works erratically

- the distant video is sometime black

...

As https://appr.tc perfectly works in all cases, I wonder if bbb html5 webrtc support might need some care?

Thanks, Jean

[Paulo R. Lanzarin]

Inline.

> on my computer, the video fails to setuyp correctly. It is either to clear,; to dark, correct by chance.

When you share your webcam, your own video is a local feed, so it's source quality. Being "too clear" or
"too dark" seems environmental, not something on our end (taking into account your description).
Our low bandwidth approach may highlight that, but there's not much to be done here. A screenshot would
be appreciated.

> on my android phones, no video sharing is possible as already mentioned
> on different iOS phones, it works erratically

Some work was done recently to try to address mobile incompatibilities. Expect an update soon.
Erratic behaviour is a sign of connectivity issues. When it does not work, what error does it show?
See below where I talk about STUN/TURN regarding connectivity issues.

>  the distant video is sometime black

This one is interesting, albeit hard to reproduce on my end. Do you see it on mobiles or your desktop?
If you're seeing it on desktop, could you try to reproduce it with chrome://webrtc-internals or about:webrtc (firefox)
open and attach a dump of those pages?

> As https://appr.tc perfectly works in all cases, I wonder if bbb html5 webrtc support might need some care?

Just a quick explanation: appr.tc, at least the public version, is peer-to-peer (whereas BigBlueButton uses a server-side
SFU approach) and provides a TURN server on its base setup. 
So the scenarios here are a tad different if you're using your server without a TURN (that might help with 
connectivity issues you might be seeing). Don't worry though, we're actively working on hardening any quirks we find.

I'd like to ask you for some info so we can try to assess some stuff:
  - Are you using your own server? If so, is it behind a NAT? Have you set up a STUN server on it, and, better yet, a TURN
server? (refer to http://docs.bigbluebutton.org/html/html5-install.html#2-install-html5-client for more info regarding STUN/TURN).
  - Are you running RC4? If so, the errors on mobiles you reported before about permission failures (below) still persist? Or are you getting a different error code?

>  Android 7.0 / Chrome (Hawei) : fails immediately, complains about permissions

> - the same / FF : asks for authorization and faills 

> - Android 5.1 / Chrome (Acer): asks for permission and fails

--

[JVieille]

Le lundi 27 août 2018 10:45:43 UTC+2, Paulo R. Lanzarin a écrit :

Inline.

> on my computer, the video fails to setuyp correctly. It is either to clear,; to dark, correct by chance.

When you share your webcam, your own video is a local feed, so it's source quality. Being "too clear" or
"too dark" seems environmental, not something on our end (taking into account your description).
Our low bandwidth approach may highlight that, but there's not much to be done here. A screenshot would
be appreciated.

 

+BBB is the only situation video does not self-tune.

However, checking again, this also occur also with the Flash client, and seeminly only on Opera/Chrome browsers

 

> on my android phones, no video sharing is possible as already mentioned
> on different iOS phones, it works erratically

Some work was done recently to try to address mobile incompatibilities. Expect an update soon.
Erratic behaviour is a sign of connectivity issues. When it does not work, what error does it show?

+ missing/incorrect permission (see in the thread) - don't even ask for them.

 

See below where I talk about STUN/TURN regarding connectivity issues.

>  the distant video is sometime black
This one is interesting, albeit hard to reproduce on my end. Do you see it on mobiles or your desktop?
If you're seeing it on desktop, could you try to reproduce it with chrome://webrtc-internals or about:webrtc (firefox)
open and attach a dump of those pages?

+Seen on both mobiles and desktop

 

> As https://appr.tc perfectly works in all cases, I wonder if bbb html5 webrtc support might need some care?
Just a quick explanation: appr.tc, at least the public version, is peer-to-peer (whereas BigBlueButton uses a server-side
SFU approach) and provides a TURN server on its base setup. 
So the scenarios here are a tad different if you're using your server without a TURN (that might help with 
connectivity issues you might be seeing). Don't worry though, we're actively working on hardening any quirks we find.

I'd like to ask you for some info so we can try to assess some stuff:
  - Are you using your own server? If so, is it behind a NAT? Have you set up a STUN server on it, and, better yet, a TURN
server? (refer to http://docs.bigbluebutton.org/html/html5-install.html#2-install-html5-client for more info regarding STUN/TURN).

+It is a dedicated server with its own IP, I am pretty sure it is not  behind a NAT - any test I could do to be sure?

  - Are you running RC4? If so, the errors on mobiles you reported before about permission failures (below) still persist? Or are you getting a different error code?

+I don't know where to look for BBB version. The HTML5 client's "About" tells "440", Flash n"923, bbb-conf --version reports the following:

[root@bbb ~]# bbb-conf --version

ii  bbb-apps                              1:2.0.0-51                                 amd64        BigBlueButton applications for Red5
ii  bbb-apps-akka                         2.0.0-144                                  all          BigBlueButton Apps (Akka)
ii  bbb-apps-screenshare                  1:2.0.0-40                                 amd64        BigBlueButton screenshare module for Red5
ii  bbb-apps-sip                          1:2.0.0-14                                 amd64        BigBlueButton SIP module for Red5
ii  bbb-apps-video                        1:2.0.0-28                                 amd64        BigBlueButton video module for Red5
ii  bbb-apps-video-broadcast              1:2.0.0-8                                  amd64        BigBlueButton video broadcast module for Red5
ii  bbb-check                             1:2.0.0-14                                 amd64        Client check package for BigBlueButton
ii  bbb-client                            1:2.0.0-373                                amd64        BigBlueButton Flash client
ii  bbb-config                            1:2.0.0-72                                 amd64        BigBlueButton configuration utilities
ii  bbb-demo                              1:2.0.0-14                                 amd64        BigBlueButton API demos
ii  bbb-freeswitch-core                   2:2.0.0-46                                 amd64        BigBlueButton build of FreeSWITCH
ii  bbb-freeswitch-sounds                 1:1.6.7-9                                  amd64        FreeSWITCH Sounds
ii  bbb-fsesl-akka                        2.0.0-26                                   all          BigBlueButton FS-ESL (Akka)
ii  bbb-html5                             1:2.0.0-440                                amd64        The HTML5 components for BigBlueButton
ii  bbb-mkclean                           1:0.8.7-4                                  amd64        Clean and optimize Matroska and WebM files
ii  bbb-playback-presentation             1:2.0.0-27                                 amd64        BigBluebutton playback of presentation
ii  bbb-record-core                       1:2.0.0-32                                 amd64        BigBlueButton record and playback
ii  bbb-red5                              1:1.0.8-40                                 amd64        The Red5 server for BigBlueButton
ii  bbb-swftools                          1:0.9.2-2                                  amd64        The swftools files for BigBlueButton
ii  bbb-transcode-akka                    2.0.0-6                                    all          BigBlueButton Transcoder
ii  bbb-web                               1:2.0.0-85                                 amd64        BigBlueButton API
ii  bbb-webhooks                          1:2.0.0-10                                 amd64        BigBlueButton Webhooks
ii  bbb-webrtc-sfu                        1:2.0.0-58                                 amd64        BigBlueButton WebRTC SFU 

ii bigbluebutton 1:2.0.0-13 amd64 Open source web conferencing platform (bbb) 

 

>  Android 7.0 / Chrome (Hawei) : fails immediately, complains about permissions

> - the same / FF : asks for authorization and faills 

> - Android 5.1 / Chrome (Acer): asks for permission and fails

On Mon, Aug 27, 2018 at 5:16 AM JVieille <jean.v...@gmail.com> wrote:

Video does not seem to correctly work yet.

We have tried other devices, with different problems.

- on my computer, the video fails to setuyp correctly. It is either to clear,; to dark, correct by chance.

- on my android phones, no video sharing is possible as already mentioned

- on different iOS phones, it works erratically

- the distant video is sometime black

...

As https://appr.tc perfectly works in all cases, I wonder if bbb html5 webrtc support might need some care?

Thanks, Jean

Le lundi 13 août 2018 12:33:21 UTC+2, JVieille a écrit :

I just tried to join a webrtc test room at https://appr.tc

It works perfectly with all my phones

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-setup+unsub...@googlegroups.com.

[JVieille]

Following the latest HTML5 client update (RC5), there are some changes.

Now, the webcam sharing authorisation is asked for (never before), then it fails with an explicit error:

Error when sharing the webcam

ERROR 1107 ICE NEGOCIATION FAILED 

Recall:

- using Android 8.0.0, Chrome

- same behaviour on either my server or test.bigbluebutton.org.

I found these potentially related issues:

https://github.com/bigbluebutton/bigbluebutton/issues/6011

https://groups.google.com/forum/#!searchin/bigbluebutton-dev/ice$201107/bigbluebutton-dev/CvbLCQ3tHSg/Fc8YiibkCgAJ

https://groups.google.com/forum/#!searchin/bigbluebutton-dev/ice$201107/bigbluebutton-dev/xMh_av0yLIc/lEtXLZN6AQAJ 

[jaa...@gmail.com]

Hey sir. I have a problem with webcamsharing on mobilephones. On pc works fine

Error when sharing the webcam

ERROR 1107 ICE NEGOCIATION FAILED 

Recall:

- using Android 8.0.0, Chrome firefox (huawei p10), and iphone

[Fred Dixon]

Hi JVille and Jaami3a,

Thanks for sharing the reports.  Is there any difference between connecting the phone to a wireless network and connecting to a cellular network?

Regards,... Fred

--

You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-s...@googlegroups.com.

To post to this group, send email to bigbluebu...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-setup.
For more options, visit https://groups.google.com/d/optout.

[Paulo R. Lanzarin]

JVille and Jammi3a,

Along with what Fred asked, two points:
1 -  The stable version of Firefox for Android has a bug on the H.264 encoder/decoder that prevents it
from working with WebRTC. I'm looking into it on FF for Android Nightly, but it seems we can't do much on the stable version.
If you don't need to support Safari/iOS devices, you could consider disabling H.264 enforcement
(which will allow VP8 for instance) by turning webcam-force-h264 to false on  /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml.
That'll get your FF for Android working at the expense of Safari/iOS support.
2 - Regarding Chrome on Android: Chrome provides a really good debugging utility for WebRTC that
allows us to debug it with a bit more detail. If you can, try sharing your webcam and triggering a failure with
a tab open on chrome://webrtc-internals on your device. After trying to share, please switch back to the
webrtc-internals tab, go to the top of the page at Create Dump -> Download the PeerConnection....
This will make your browser download a debug file that you can attach here so we can have a look at what's messing
with Chrome (might be firewall, ICE negotiation, lack of appropriate codec...)

s,

Paulo. 

[jaa...@gmail.com]

Hi Paulo,

Thank you for your respond. In the attachement , i uploaded the debug file of webcamsharing(webcam-force-h264=true) for you. After that I turned webcam-force-h264 to false. Sharing webcam works fine on Android Version 7(chrome and firefox).

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-setup+unsub...@googlegroups.com.

To post to this group, send email to bigbluebu...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-setup.
For more options, visit https://groups.google.com/d/optout.

--

BigBlueButton Developer

http://bigbluebutton.org/

@bigbluebutton

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-setup+unsub...@googlegroups.com.

[jaa...@gmail.com]

Hi Fred,

No diffrence if i change my connection  to a cellular network. I did what Paul said.  to turn 

webcam-force-h264: false

It works fine on android (chrome and firefox), But in iphone didn't works. I sended the debug file of  android chrome to Paul for  webcamsharing when webcam-force-h264 was true  . 

On Wednesday, September 12, 2018 at 2:27:22 AM UTC+2, Fred Dixon wrote:

Hi JVille and Jaami3a,

Thanks for sharing the reports.  Is there any difference between connecting the phone to a wireless network and connecting to a cellular network?

Regards,... Fred

On Tue, Sep 11, 2018 at 5:39 PM <jaa...@gmail.com> wrote:

Hey sir. I have a problem with webcamsharing on mobilephones. On pc works fine

Error when sharing the webcam

ERROR 1107 ICE NEGOCIATION FAILED 

Recall:

- using Android 8.0.0, Chrome firefox (huawei p10), and iphone

- same behaviour on either my server or test.bigbluebutton.org. 

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-setup+unsub...@googlegroups.com.

To post to this group, send email to bigbluebu...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-setup.
For more options, visit https://groups.google.com/d/optout.

[jaa...@gmail.com]

I get this 

I get this 

sudo su - kurento | gst-inspect-1.5 | grep -i h264

$ No command 'gst-inspect-1.5' found, did you mean:

 Command 'gst-inspect-1.0' from package 'gstreamer1.0-tools' (main)

gst-inspect-1.5: command not found

sudo su - root | gst-inspect-1.5 | grep -i h264

No command 'gst-inspect-1.5' found, did you mean:

 Command 'gst-inspect-1.0' from package 'gstreamer1.0-tools' (main)

gst-inspect-1.5: command not found

Do need install openwebrtc-gst-plugins of this link https://github.com/Kurento/openwebrtc-gst-plugins.git ?

On Wednesday, September 12, 2018 at 2:53:45 AM UTC+2, Paulo R. Lanzarin wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-setup+unsub...@googlegroups.com.

To post to this group, send email to bigbluebu...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-setup.
For more options, visit https://groups.google.com/d/optout.

--

BigBlueButton Developer

http://bigbluebutton.org/

@bigbluebutton

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-setup+unsub...@googlegroups.com.

[JVieille]

Hi Fred, 

no difference

Thanks

[JVieille]

Hi Paulo,

I attached the dump after a failing attempt to share the video

Turnng the H264 flag to false solves the issue for Android.

Thanks for pointing out this issue.

[Paulo R. Lanzarin]

Jean,

Just to pinpoint the issue here: your mobile browser's webrtc implementation is not picking up the h264 encoder/decoder, hence the failure with h264 enforcement enabled.

As to why it isn't available I can't pinpoint. It is, however, a browser issue. I'll try to make the toast error more clear for that case, though.

--

[JVieille]

So why does this work?

https://appr.tc?vrc=H264&vsc=H264 n- maybe not enforcing ? ("prefered" coding parameters)

I understand that Chrome/Android does not necessarily support H264 depending on hardware and that IoS does not support VP8

So Webrtc does not allow IoS and Android Users to communicate.

This situation seems to last for years, any way to get around that issue, some fallback ?

 

[Paulo R. Lanzarin]

appr.tc with vrc=H264 only suggests H.264 as the preferred codec, instead of
trying to force it (how we do), so it'll pick up VP8 or VP9 nonetheless and work.

When webcam-h264-force is enabled, we force it because we want to avoid H.264 <-> VP8
transcoding server-side, which potentially will cause a high load on the server. 
appr.tc does not do this because, as I have already said, it's a peer-to-peer implementation
so there's no worrying about load on server-side.

So Webrtc does not allow IoS and Android Users to communicate.

This assumption is incorrect. WebRTC does allow it. What happens is that some Android devices + browser seem
to have problems with the H.264 setup, rendering them faulty for communication with iOS
devices unless there's transcoding involved. In my experience, though, the number of
Android devices that support H.264 properly with WebRTC is the majority (excluding when there's some widespread bug, like the one on the current

FF for Android release).

--

[JVieille]

Thanks for the detailed answer!

Somewhat happy to be among the one percent concerned... 

[Paulo R. Lanzarin]

Also, missed this part: 

This situation seems to last for years, any way to get around that issue, some fallback ?

On our end, the fallback currently is to disable h264 enforcement as explained before. If you're willing
to handle any transcoding costs (and hiccups) that might come to fruition when somebody without H.264
comes into play, it's a way.

Moreover,  don't read my explanation about the h.264 pitfalls as "we stop here". Development is ongoing,
I'm brewing some ways to increase the interoperability as far as we can and I expect that with further
development the number of endpoints supported will expand. tl;dr.: we'll keep working on it :).

On Fri, Sep 14, 2018, 13:01 JVieille <jean.v...@gmail.com> wrote:

Thanks for the detailed answer!

Somewhat happy to be among the one percent concerned... 

--

[JVieille]

On our end, the fallback currently is to disable h264 enforcement as explained before. If you're willing
to handle any transcoding costs (and hiccups) that might come to fruition when somebody without H.264
comes into play, it's a way.

*Do you mean "turning webcam-force-h264 to false on  /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml.

That'll get your FF for Android working at the expense of Safari/iOS support."

Hence changing this setting would prevent IoS to share video?

I would have thought that this setting addresses clients individually, so H264 capable devices get it while other fall back (and suck resources)?

 

[Paulo R. Lanzarin]

I was not precise in that phrase, sorry. The option addresses clients individually, yes. See:

webcam-force-h264: true will force H264 and any device that doesn't have it will fail to share or view videos.
webcam-force-h264: false will let the process go untouched. If there's VP8 in the SDP as the preferred codec, it'll pick
VP8. If there's only H264, it'll pick H264. So iOS devices will be able to join. There'll be transcoding between VP8 and H264
if deemed necessary, though. 

--

[JVieille]

Perfect.

Maybe this needs to be mentionned in the install page http://docs.bigbluebutton.org/html/html5-install.html

[Fred Dixon]

Hi Jean,

> Maybe this needs to be mentionned in the install page http://docs.bigbluebutton.org/html/html5-install.html

Can you let us know if this works for your setup first and then we'll add to the docs.

Regards,... Fred

On Sat, Sep 15, 2018 at 3:01 AM JVieille <jean.v...@gmail.com> wrote:

Perfect.

Maybe this needs to be mentionned in the install page http://docs.bigbluebutton.org/html/html5-install.html

--

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

[JVieille]

This is perfect, both android and ios devices can share and see videos

 

However, 2 settings are actually concerned as desk sharing is also affected.

Something like that ?

When experiencing  video support issues with certain Android mobile devices (Namely Huawei...) , you can turn off h264 enforcement at tyhe cost of server load in  /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml :

webcam-force-h264: false

screenshare-force-h264: false

[JVieille]

Still not working on my Huawei android. This might still be the H264 issue, but I don't find where to unforce this protocol, the setting place has changed apparently.

Thanks for help

Le lundi 23 juillet 2018 09:33:24 UTC+2, JVieille a écrit :

Whenever I whish to share the phone webcam, I get immedialely "Error on sharing webcam. Check permission", with no option to accept the camera sharing.

I added the permission for the Chrome app to use the camera, and Chrome is set to accept the use of the camera.

Thanks for help

[Nicolas Ducoulombier LDD]

Le 06/02/2019 à 08:18, JVieille a écrit :

Still not working on my Huawei android. This might still be the H264 issue, but I don't find where to unforce this protocol, the setting place has changed apparently.

Thanks for help

it's in /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml

It was indicated here https://groups.google.com/forum/#!msg/bigbluebutton-dev/9POq7LzhjIQ/HG_VQJ63CQAJ

On /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml, there's an

option called webcam-force-h264. Turning it to false on your server and then restarting bbb-webrtc-sfu
 should get your cams working if there's no H.264 avaiable in your client.
A quick explanation on the config option:

• webcam-force-h264: true will force H264 and any device that doesn't have it will fail to share or view videos.

• webcam-force-h264: false will let the process go untouched. If there's VP8 in the SDP as the preferred codec, it'll pick VP8. If there's only H264, it'll pick H264. So iOS devices will be able to join. There'll be transcoding between VP8 and H264 if deemed necessary, though.

Best regards

--
Nicolas

[Chad Pilkey]

The new version of the SFU in BBB 2.0-RC10 has a naming change on the codec choice. The comments in the SFU's default.yml contain explanations on how to use the new properties, but it seems that yq strips out comments from the YAMLs. The original file with comments can be found here, https://github.com/bigbluebutton/bbb-webrtc-sfu/blob/master/config/default.example.yml#L86-L95. The new value to use is "codec_video_main: ANY" and "codec_video_content: ANY".