[jitsi-users] Screensharing freeze on Chrome with last stable jitsi-meet


#1

Hi Jitsi Community,

We've recently upgrade our Jitsi-meet platform from an old 1.0.1108 to the last stable one (1.0.2098).
All seems to be good and users are happy with the new version excepting the screensharing feature.

Many users report us screensharing issues with Chrome.
The screensharing stream work for few times and suddenly block on the received part, turning into gray mode.

After studying error conferences we found that instabilities appear more often when :
user deny camera use before starting screensharing and network had some few packet lost (for example in WiFi network)

Many of our user use JItsi-meet for screensharing only.

I made some test with the meet.jit.si and Chrome 60 on these test cases :

case 1 :
- 2 users with P2P disabled (https://meet.jit.si/echo42#config.p2p.enabled=false) and camera sharing previously blocked
- User A share its screen to user B
- Simulate some packet loss on user A network (using "sudo tc qdisc add dev eth1 root netem loss 10%" on linux)
- Stop packet loss

case 2:
- 2 users with P2P disabled (https://meet.jit.si/echo42#config.p2p.enabled=false) and camera allowed to be used by jitsi-meet
- User A share its screen to user B
- Simulate some packet loss on user A network (using "sudo tc qdisc add dev eth1 root netem loss 10%" on linux)
- stop packet loss

In the 2 tests when packet loss start , User B send nack and PLI request.

In test 1 :
User A receive only nack request and every time a PLI is send by B we have this error on Chrome :
[1:26:0911/111507.216237:ERROR:channel.cc(828)] Failed to unprotect audio RTCP packet: size=26, type=206
[1:26:0911/111507.216529:ERROR:channel.cc(828)] Failed to unprotect video RTCP packet: size=26, type=206
After stopping packet loss simulation : unprotect Error continue and no PLI are received by A the screensharing stream never restart on user B

In test 2:
User A receive Nack and PLI and we don't have error.
After stopping packet loss simulation : screensharing stream restart after a few time.

Do someone have some ideas or videobridge settings to have a more stable solution for screensharing ?

Best Regards,
Damien Fétis


#2

Hi!

Hi Jitsi Community,

We've recently upgrade our Jitsi-meet platform from an old 1.0.1108 to the last stable one (1.0.2098).
All seems to be good and users are happy with the new version excepting the screensharing feature.

Many users report us screensharing issues with Chrome.
The screensharing stream work for few times and suddenly block on the received part, turning into gray mode.

After studying error conferences we found that instabilities appear more often when :
   user deny camera use before starting screensharing and network had some few packet lost (for example in WiFi network)

Many of our user use JItsi-meet for screensharing only.

I made some test with the meet.jit.si and Chrome 60 on these test cases :

case 1 :
- 2 users with P2P disabled (https://meet.jit.si/echo42#config.p2p.enabled=false) and camera sharing previously blocked
- User A share its screen to user B
- Simulate some packet loss on user A network (using "sudo tc qdisc add dev eth1 root netem loss 10%" on linux)
- Stop packet loss

case 2:
- 2 users with P2P disabled (https://meet.jit.si/echo42#config.p2p.enabled=false) and camera allowed to be used by jitsi-meet
- User A share its screen to user B
- Simulate some packet loss on user A network (using "sudo tc qdisc add dev eth1 root netem loss 10%" on linux)
- stop packet loss

In the 2 tests when packet loss start , User B send nack and PLI request.

In test 1 :
User A receive only nack request and every time a PLI is send by B we have this error on Chrome :
[1:26:0911/111507.216237:ERROR:channel.cc(828)] Failed to unprotect audio RTCP packet: size=26, type=206
[1:26:0911/111507.216529:ERROR:channel.cc(828)] Failed to unprotect video RTCP packet: size=26, type=206
After stopping packet loss simulation : unprotect Error continue and no PLI are received by A the screensharing stream never restart on user B

In test 2:
User A receive Nack and PLI and we don't have error.
After stopping packet loss simulation : screensharing stream restart after a few time.

Thanks for your detailed analysis.

Do someone have some ideas or videobridge settings to have a more stable solution for screensharing ?

I’m afraid there is nothing we can do at the moment, AFAIK. When using video we can lower the simulcast layer so you get a lower resolution video stream in case there is packet loss, but screen sharing doesn’t (yet) use simulcast, so there is no layer we can drop. As a result, when packet loss is detected we will disable the video stream and you’ll see the “Video was disabled to save bandwidth” message.

Chrome is implementing simulcast for screen sharing streams too, so once it lands we should be able to take advantage of it.

Cheers,

···

On Sep 11, 2017, at 15:57, Damien FETIS <damien.fetis@renater.fr> wrote:

--
Saúl


#3

Hi Saúl,
thank you for response and information about simulcast future implementation for screensharing.

I have continued to do some tests and what I notice is :

When camera is not activated before screen sharing RTCP PLI feedback send by receiving part cause a Chrome error "unprotect RTCP packet" in the sender user.
So RTCP feedback stream seems to be broken in this case.

When Camera is activated before peerconnection negotiation all is OK and sending PLI are correctly decoded and a Key frame is send.

This behavior doesn't appear when we are on p2p mode between users, so it seems their are some issue in RTCP transmission from the videobridge.

Regards,
Damien.

----- Mail original -----

···

De: "Saúl Ibarra Corretgé" <scorretge@atlassian.com>
À: "Jitsi Users" <users@jitsi.org>
Envoyé: Mercredi 13 Septembre 2017 10:09:34
Objet: Re: [jitsi-users] Screensharing freeze on Chrome with last stable jitsi-meet

Hi!

On Sep 11, 2017, at 15:57, Damien FETIS <damien.fetis@renater.fr> wrote:

Hi Jitsi Community,

We've recently upgrade our Jitsi-meet platform from an old 1.0.1108 to the last stable one (1.0.2098).
All seems to be good and users are happy with the new version excepting the screensharing feature.

Many users report us screensharing issues with Chrome.
The screensharing stream work for few times and suddenly block on the received part, turning into gray mode.

After studying error conferences we found that instabilities appear more often when :
   user deny camera use before starting screensharing and network had some few packet lost (for example in WiFi network)

Many of our user use JItsi-meet for screensharing only.

I made some test with the meet.jit.si and Chrome 60 on these test cases :

case 1 :
- 2 users with P2P disabled (https://meet.jit.si/echo42#config.p2p.enabled=false) and camera sharing previously blocked
- User A share its screen to user B
- Simulate some packet loss on user A network (using "sudo tc qdisc add dev eth1 root netem loss 10%" on linux)
- Stop packet loss

case 2:
- 2 users with P2P disabled (https://meet.jit.si/echo42#config.p2p.enabled=false) and camera allowed to be used by jitsi-meet
- User A share its screen to user B
- Simulate some packet loss on user A network (using "sudo tc qdisc add dev eth1 root netem loss 10%" on linux)
- stop packet loss

In the 2 tests when packet loss start , User B send nack and PLI request.

In test 1 :
User A receive only nack request and every time a PLI is send by B we have this error on Chrome :
[1:26:0911/111507.216237:ERROR:channel.cc(828)] Failed to unprotect audio RTCP packet: size=26, type=206
[1:26:0911/111507.216529:ERROR:channel.cc(828)] Failed to unprotect video RTCP packet: size=26, type=206
After stopping packet loss simulation : unprotect Error continue and no PLI are received by A the screensharing stream never restart on user B

In test 2:
User A receive Nack and PLI and we don't have error.
After stopping packet loss simulation : screensharing stream restart after a few time.

Thanks for your detailed analysis.

Do someone have some ideas or videobridge settings to have a more stable solution for screensharing ?

I’m afraid there is nothing we can do at the moment, AFAIK. When using video we can lower the simulcast layer so you get a lower resolution video stream in case there is packet loss, but screen sharing doesn’t (yet) use simulcast, so there is no layer we can drop. As a result, when packet loss is detected we will disable the video stream and you’ll see the “Video was disabled to save bandwidth” message.

Chrome is implementing simulcast for screen sharing streams too, so once it lands we should be able to take advantage of it.

Cheers,

--
Saúl

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

Hi Saúl,
thank you for response and information about simulcast future implementation for screensharing.

I have continued to do some tests and what I notice is :

When camera is not activated before screen sharing RTCP PLI feedback send by receiving part cause a Chrome error "unprotect RTCP packet" in the sender user.
So RTCP feedback stream seems to be broken in this case.

When Camera is activated before peerconnection negotiation all is OK and sending PLI are correctly decoded and a Key frame is send.

This behavior doesn't appear when we are on p2p mode between users, so it seems their are some issue in RTCP transmission from the videobridge.

Thanks for you analysis! Calling in the cavalry! (George is in CC).

Cheers,

···

On Sep 14, 2017, at 11:10, Damien FETIS <damien.fetis@renater.fr> wrote:

Regards,
Damien.

----- Mail original -----
De: "Saúl Ibarra Corretgé" <scorretge@atlassian.com>
À: "Jitsi Users" <users@jitsi.org>
Envoyé: Mercredi 13 Septembre 2017 10:09:34
Objet: Re: [jitsi-users] Screensharing freeze on Chrome with last stable jitsi-meet

Hi!

On Sep 11, 2017, at 15:57, Damien FETIS <damien.fetis@renater.fr> wrote:

Hi Jitsi Community,

We've recently upgrade our Jitsi-meet platform from an old 1.0.1108 to the last stable one (1.0.2098).
All seems to be good and users are happy with the new version excepting the screensharing feature.

Many users report us screensharing issues with Chrome.
The screensharing stream work for few times and suddenly block on the received part, turning into gray mode.

After studying error conferences we found that instabilities appear more often when :
  user deny camera use before starting screensharing and network had some few packet lost (for example in WiFi network)

Many of our user use JItsi-meet for screensharing only.

I made some test with the meet.jit.si and Chrome 60 on these test cases :

case 1 :
- 2 users with P2P disabled (https://urldefense.proofpoint.com/v2/url?u=https-3A__meet.jit.si_echo42-23config.p2p.enabled-3Dfalse&d=DwIGaQ&c=wBUwXtM9sKhff6UeHOQgvw&r=-T6Cew-S4Ei-6rhDWu1AY-o1ETORq5uAicdns9fSwgI&m=yiRfdhOzE-Q-HAUhzb7nattwdizOiyb2rvQ1V_p0G90&s=tGnI5izVUbnvOXZFvcDYRXi5WEYnD4CijWyH1l9dgQY&e=) and camera sharing previously blocked
- User A share its screen to user B
- Simulate some packet loss on user A network (using "sudo tc qdisc add dev eth1 root netem loss 10%" on linux)
- Stop packet loss

case 2:
- 2 users with P2P disabled (https://urldefense.proofpoint.com/v2/url?u=https-3A__meet.jit.si_echo42-23config.p2p.enabled-3Dfalse&d=DwIGaQ&c=wBUwXtM9sKhff6UeHOQgvw&r=-T6Cew-S4Ei-6rhDWu1AY-o1ETORq5uAicdns9fSwgI&m=yiRfdhOzE-Q-HAUhzb7nattwdizOiyb2rvQ1V_p0G90&s=tGnI5izVUbnvOXZFvcDYRXi5WEYnD4CijWyH1l9dgQY&e=) and camera allowed to be used by jitsi-meet
- User A share its screen to user B
- Simulate some packet loss on user A network (using "sudo tc qdisc add dev eth1 root netem loss 10%" on linux)
- stop packet loss

In the 2 tests when packet loss start , User B send nack and PLI request.

In test 1 :
User A receive only nack request and every time a PLI is send by B we have this error on Chrome :
[1:26:0911/111507.216237:ERROR:channel.cc(828)] Failed to unprotect audio RTCP packet: size=26, type=206
[1:26:0911/111507.216529:ERROR:channel.cc(828)] Failed to unprotect video RTCP packet: size=26, type=206
After stopping packet loss simulation : unprotect Error continue and no PLI are received by A the screensharing stream never restart on user B

In test 2:
User A receive Nack and PLI and we don't have error.
After stopping packet loss simulation : screensharing stream restart after a few time.

Thanks for your detailed analysis.

Do someone have some ideas or videobridge settings to have a more stable solution for screensharing ?

I’m afraid there is nothing we can do at the moment, AFAIK. When using video we can lower the simulcast layer so you get a lower resolution video stream in case there is packet loss, but screen sharing doesn’t (yet) use simulcast, so there is no layer we can drop. As a result, when packet loss is detected we will disable the video stream and you’ll see the “Video was disabled to save bandwidth” message.

Chrome is implementing simulcast for screen sharing streams too, so once it lands we should be able to take advantage of it.

Cheers,

--
Saúl

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.jitsi.org_mailman_listinfo_users&d=DwIGaQ&c=wBUwXtM9sKhff6UeHOQgvw&r=-T6Cew-S4Ei-6rhDWu1AY-o1ETORq5uAicdns9fSwgI&m=yiRfdhOzE-Q-HAUhzb7nattwdizOiyb2rvQ1V_p0G90&s=Wjtijvrzz7N1XJzBSeCuZeu6wzZ3mkjXebsI4kDhodA&e=

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.jitsi.org_mailman_listinfo_users&d=DwIGaQ&c=wBUwXtM9sKhff6UeHOQgvw&r=-T6Cew-S4Ei-6rhDWu1AY-o1ETORq5uAicdns9fSwgI&m=yiRfdhOzE-Q-HAUhzb7nattwdizOiyb2rvQ1V_p0G90&s=Wjtijvrzz7N1XJzBSeCuZeu6wzZ3mkjXebsI4kDhodA&e=

--
Saúl