Change webcam resolution

[Leandro De Mestico]

Hi,

I'm having issues sharing my webcam (own server and test server).

I'm getting "Error 1107: ICE negotiation failed" and testing in https://test.webrtc.org/ I get "FAILED ] getUserMedia failed with error: OverconstrainedError"

Where can I change webcam resolutions or what should I do to make it work?

_________________________________________________________________________________

________________________________Leandro De Mestico_____________________________

leandro.demestico@redtecnologica.org

_________________________________________________________________________________

[Paulo R. Lanzarin]

Webcam feeds on HTML5 are constrained only to an upper limit, so it shouldn't be a problem.
Paste the output of https://webrtchacks.github.io/WebRTC-Camera-Resolution/ to be sure (Quick scan).

What browser you're on? Mobile or desktop? If on chrome, please attach chrome://webrtc-internals dump.
If Firefox, about:firefox.

--
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.

[Paulo R. Lanzarin]

I'm sorry, if you're on Firefox I meant the about:webrtc page dump.

[Leandro De Mestico]

Hi Paulo, thanks for answer.

Quick scan:

firefox 61    HP Webcam: HP Webcam    4K(UHD)    16:9    3840x2160    640x480    fail: OverconstrainedError
firefox 61    HP Webcam: HP Webcam    1080p(FHD)    16:9    1920x1080    640x480    fail: OverconstrainedError
firefox 61    HP Webcam: HP Webcam    UXGA    4:3    1600x1200    640x480    fail: OverconstrainedError
firefox 61    HP Webcam: HP Webcam    720p(HD)    16:9    1280x720    640x480    fail: OverconstrainedError
firefox 61    HP Webcam: HP Webcam    SVGA    4:3    800x600    640x480    fail: OverconstrainedError
firefox 61    HP Webcam: HP Webcam    VGA    4:3    640x480    640x480    pass
firefox 61    HP Webcam: HP Webcam    360p(nHD)    16:9    640x360    640x360    pass
firefox 61    HP Webcam: HP Webcam    CIF    4:3    352x288    352x288    pass
firefox 61    HP Webcam: HP Webcam    QVGA    4:3    320x240    320x240    pass
firefox 61    HP Webcam: HP Webcam    QCIF    4:3    176x144    176x144    pass
firefox 61    HP Webcam: HP Webcam    QQVGA    4:3    160x120    160x120    pass

I'm getting this errors from firefox (fedora) and form chrome (android).

_________________________________________________________________________________

________________________________Leandro De Mestico_____________________________

leandro....@redtecnologica.org

Cel. 54 11 3916 4438

Horario de contacto: 10-16hs, emergencias 8-23hs (Cel.)

_________________________________________________________________________________

[Paulo R. Lanzarin]

Not a resolution problem. The dumps I requested will help us pinpoint the issue. Try to get both of them
from your fedora/firefox and android/chrome. The pages must be open before you share the webcam.

Thanks for the info.

s, 

Paulo.

[Leandro De Mestico]

Sorry, I didn't see your second email.

Firefox (full page attached):

_________________________________________________________________________________

________________________________Leandro De Mestico_____________________________

leandro....@redtecnologica.org

Cel. 54 11 3916 4438

Horario de contacto: 10-16hs, emergencias 8-23hs (Cel.)

_________________________________________________________________________________

[Paulo R. Lanzarin]

It seems the dump only got the audio stream... Can you please do it again with the following procedure:
1) Open about:webrtc 2) Share webcam, let it fail, 3) Refresh about:webrtc and generate dump.

Sorry to ask for it again :)

[Leandro De Mestico]

Chrome, android dump.

[Leandro De Mestico]

New dump from firefox:

PeerConnection ID: 1536953393642181 (id=4294968001 url=https://bbb-rt.ddns.net/html5client/users)

ICE Stats

Trickled candidates (arriving after answer) are highlighted in blue

Local Candidate	Remote Candidate	Component ID	ICE State	Priority	Nominated	Selected	Bytes sent	Bytes received
190.210.225.59:46674/udp(serverreflexive)	149.28.49.65:20196/udp(host)	1	succeeded	2830970935590911	true	true	239548	479110
192.168.1.199:57506/udp(host)	149.28.49.65:20196/udp(host)	1	failed	2830971808121343	false	false	0	0
192.168.1.148:46674/udp(host)	149.28.49.65:20196/udp(host)	1	inprogress	2830971807990271	false	false	0	0

ICE restarts: 0

ICE rollbacks: 0

All Raw Candidates

▲ hide raw candidates

Raw Local Candidate	Raw Remote Candidate
host(IP4:192.168.1.148:46674/UDP)	candidate:4323236299 1 udp 659136 149.28.49.65 20196 typ host generation 0
host(IP4:192.168.1.148:50076/TCP) active
host(IP4:192.168.1.199:57506/UDP)
host(IP4:192.168.1.199:60431/TCP) active
srflx(IP4:192.168.1.148:46674/UDP|stun.freeswitch.org:3478)
srflx(IP4:192.168.1.199:57506/UDP|stun.freeswitch.org:3478)

SDP

Local SDP (Offer)

v=0
o=mozilla...THIS_IS_SDPARTA-61.0.1 5283148017960676233 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 10:FD:D9:6F:CE:89:55:B3:51:07:EE:78:2F:8C:A2:50:06:0A:E4:11:F2:64:8B:A5:C5:D8:76:2E:37:78:A8:FC
a=group:BUNDLE sdparta_0
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 57506 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 190.210.225.59
a=candidate:0 1 UDP 2122252543 192.168.1.199 57506 typ host
a=candidate:2 1 UDP 2122187007 192.168.1.148 46674 typ host
a=candidate:4 1 TCP 2105524479 192.168.1.199 9 typ host tcptype active
a=candidate:5 1 TCP 2105458943 192.168.1.148 9 typ host tcptype active
a=candidate:0 2 UDP 2122252542 192.168.1.199 41077 typ host
a=candidate:2 2 UDP 2122187006 192.168.1.148 50398 typ host
a=candidate:4 2 TCP 2105524478 192.168.1.199 9 typ host tcptype active
a=candidate:5 2 TCP 2105458942 192.168.1.148 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 190.210.225.59 57506 typ srflx raddr 192.168.1.199 rport 57506
a=candidate:3 1 UDP 1685987327 190.210.225.59 46674 typ srflx raddr 192.168.1.148 rport 46674
a=candidate:1 2 UDP 1686052862 190.210.225.59 41077 typ srflx raddr 192.168.1.199 rport 41077
a=candidate:3 2 UDP 1685987326 190.210.225.59 50398 typ srflx raddr 192.168.1.148 rport 50398
a=sendrecv
a=end-of-candidates
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:8516541db34b2d926750dbc897d6bbf1
a=ice-ufrag:a8b5c024
a=mid:sdparta_0
a=msid:{3e9e7ff1-1c87-41f9-ae88-27e058d768fc} {1b80479f-bdca-46c3-b3f9-98d684e919ce}
a=rtcp:41077 IN IP4 190.210.225.59
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:531018676 cname:{502fed0d-b8b9-469d-a09a-bf21a8b56dfa}

Remote SDP (Answer)

v=0
o=FreeSWITCH 1536933198 1536933199 IN IP4 149.28.49.65
s=-
t=0 0
a=sendrecv
a=msid-semantic:WMS GYO1KW3RFqwRKKCL3E2PMjL7gDYI9E1F
m=audio 20196 RTP/SAVPF 109 101
c=IN IP4 149.28.49.65
a=candidate:4323236299 1 udp 659136 149.28.49.65 20196 typ host generation 0
a=sendrecv
a=end-of-candidates
a=fingerprint:sha-256 F1:9D:E1:E9:58:38:D8:E7:E8:1A:A8:8A:74:45:E7:75:DE:BE:FA:8C:FB:89:BC:BF:5A:43:4D:77:A5:BB:43:A4
a=fmtp:109 maxplaybackrate=0;stereo=1;useinbandfec=1
a=ice-pwd:WeGdvh02fuaNrTeRvlUg4V7g
a=ice-ufrag:ALhdVSa1lZzluqQN
a=ptime:20
a=rtcp:20196 IN IP4 149.28.49.65
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=setup:active
a=ssrc:3819117506 cname:sFx3rrLWH7EhI6TB
a=ssrc:3819117506 msid:GYO1KW3RFqwRKKCL3E2PMjL7gDYI9E1F a0
a=ssrc:3819117506 mslabel:GYO1KW3RFqwRKKCL3E2PMjL7gDYI9E1F
a=ssrc:3819117506 label:GYO1KW3RFqwRKKCL3E2PMjL7gDYI9E1Fa0

RTP Stats

outbound_rtcp_audio_0

Local: 00:36:35 GMT-0300 (-03) inbound-rtp SSRC: 531018676 Received: 1706 packets (168.29 Kb) Lost: 1 Jitter: 0.001 RTT: 198 ms

inbound_rtp_audio_1

Jitter-buffer delay: 39 ms

Local: 16:30:34 GMT-0300 (-03) inbound-rtp SSRC: 3819117506 Received: 1844 packets (443.57 Kb) Lost: 63 Jitter: 0.001

Remote: 16:30:34 GMT-0300 (-03) outbound-rtp SSRC: 3819117506 Sent: 1901 packets (453.58 Kb)

outbound_rtp_audio_0

Local: 16:30:34 GMT-0300 (-03) outbound-rtp SSRC: 531018676 Sent: 1922 packets (230.89 Kb)

Remote: 00:36:35 GMT-0300 (-03) inbound-rtp SSRC: 531018676 Received: 1706 packets (168.29 Kb) Lost: 1 Jitter: 0.001 RTT: 198 ms

inbound_rtcp_audio_1

Local: 16:30:34 GMT-0300 (-03) outbound-rtp SSRC: 3819117506 Sent: 1901 packets (453.58 Kb)

[ 4294967978 ] https://bbb-rt.ddns.net/html5client/users (closed) Fri Sep 14 2018 16:28:57 GMT-0300 (-03)

_________________________________________________________________________________

________________________________Leandro De Mestico_____________________________

leandro....@redtecnologica.org

Cel. 54 11 3916 4438

Horario de contacto: 10-16hs, emergencias 8-23hs (Cel.)

_________________________________________________________________________________

[Paulo R. Lanzarin]

Upon further investigation with Leandro, we found out that it's yet another case of the remote peer 
not having H.264 enabled.
For anyone reading this topic, I'll paste the recommendations I made on another similar one:

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.

[sanjay kumar]

Excellent work. This will help us a lot.

Thanks

NEXIO

[Henry L]

Thank you. It worked perfectly on my androids (6.0)

[Leandro De Mestico]

Paulo! I need you,

Since rc9 /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml has change. I'm not longer able to simple "false" H264, How should I disable this?

Thanks in advance!

Pd: sharing working on windows but not linux.

_________________________________________________________________________________

________________________________Leandro De Mestico Fefer_____________________________

Contacto: leandro....@redtecnologica.org

Tel. 54 11 3916 4438

Horario de contacto: 11-17hs, emergencias 8-23hs (Tel.)

      Dpto. Sistemas e Infraestructura

_________________________________________________________________________________

[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".

[Paulo R. Lanzarin]

Yes, the configuration has changed to follow a change on how we do the SDP pre and post-processing to uniformize codecs.
What Chad said is accurate. We can now also enforce VP8 instead of H.264 by putting 'VP8' in the fields.

[Leandro De Mestico]

Thanks to both of you! It works very well now with "ANY". Tomorrow I'll be testing VP8 :)

Regards,

_________________________________________________________________________________

________________________________Leandro De Mestico Fefer_____________________________

Contacto: leandro....@redtecnologica.org

Tel. 54 11 3916 4438

Horario de contacto: 11-17hs, emergencias 8-23hs (Tel.)

      Dpto. Sistemas e Infraestructura

_________________________________________________________________________________

[Sanjay Kumar]

We will appreciate if you can share the VP8 tests feedback.

Thanks

Sanjay Kumar

[JVieille]

Wouldn't be safer to set ANY by default as H264 appears to be a performance tweak at the cost of wider compatibility?

[Chad Pilkey]

Which codec you need the most depends on the location where most of your users are. In North America we have lots of iOS users and few people with Huawei devices, other places have much lower iOS usage and higher Huawei (or other Chinese phone) usage. I think ideally we would want the codec selection on the server to be dynamic and have a "main codec" and then if that isn't available on the client we could offer the backup options. Right now if we were to make "ANY" the default we would see a lot of transcoding because the desktop browsers are likely to select VP8 if the server offers it and we would want to avoid that if possible.