[jitsi-users] Screen sharing only, video freezing


#1

Hello,

We are doing screen sharing only calls with lib-jitsi-meet against our
deployment of Prosody/Jicofo/Videobridge but are experiencing video
freezing + not being able to recover from time to time. We are using latest
Chrome on both sides, and when this happens, we can tell from
webrtc-internals that the receiver is still receiving bits, but is not able
to decode them.

From webrtc-internals it seems that the receiver is sending Plis (lots of

them) and NACKS when this happens, but we do not see FIRs being requested
or sent. The sender generally receives only a few Plis and no NACKS. And no
FIRs requested.

This from the Chrome debug log seems suspicious (number of these seem to
correspond to the number of Plis):

[7672:5904:1127/041533.851:WARNING:srtpsession.cc(140)] Failed to unprotect
SRTCP packet, err=7

[7672:5904:1127/041533.851:ERROR:channel.cc(787)] Failed to unprotect video
RTCP packet: size=26, type=206

Increasing org.jitsi.impl.neomedia.transform.CachingTransformer.CACHE_SIZE_MILLIS
in the video bridge config, appears to make the freezes less likely to
happen (suggesting that NACK+RTC is working on the viewer side?), but
still, when a freeze eventually happens, it cannot recover.

Any help / pointers to what might be going on here would be much
appreciated.

Thanks,
Jonas


#2

Hi Jonas,

I'm afraid I can't help much, but your interpretation seems correct.

type=206 and size=26 strongly suggests a PLI packet sent from the bridge, and if the sender doesn't handle PLIs freezes are exactly what you would see. The bridge will consume PLI/FIR packets that it receives, and will generate PLIs on its own (paced to at most one per 300ms, and it gives up after a while, which explains why your sender only receives a few PLIs).

err=7 indicates an authentication failure[0], i.e. the authentication tag in the packet didn't match the one that was computed, but it's hard to tell what actually caused it.

Regards,
Boris

[0] https://github.com/cisco/libsrtp/blob/master/include/srtp.h#L173

···

On 28/11/2017 01:27, Jonas Jonas wrote:

Hello,

We are doing screen sharing only calls with lib-jitsi-meet against our deployment of Prosody/Jicofo/Videobridge but are experiencing video freezing + not being able to recover from time to time. We are using latest Chrome on both sides, and when this happens, we can tell from webrtc-internals that the receiver is still receiving bits, but is not able to decode them.

From webrtc-internals it seems that the receiver is sending Plis (lots of them) and NACKS when this happens, but we do not see FIRs being requested or sent. The sender generally receives only a few Plis and no NACKS. And no FIRs requested.

This from the Chrome debug log seems suspicious (number of these seem to correspond to the number of Plis):

[7672:5904:1127/041533.851:WARNING:srtpsession.cc(140)] Failed to unprotect SRTCP packet, err=7

[7672:5904:1127/041533.851:ERROR:channel.cc(787)] Failed to unprotect video RTCP packet: size=26, type=206

Increasing org.jitsi.impl.neomedia.transform.CachingTransformer.CACHE_SIZE_MILLIS in the video bridge config, appears to make the freezes less likely to happen (suggesting that NACK+RTC is working on the viewer side?), but still, when a freeze eventually happens, it cannot recover.

Any help / pointers to what might be going on here would be much appreciated.

Thanks,
Jonas

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


#3

Hi

We are facing similar thing. We use chrome version 62 too. We did not see this in earlier versions of chrome.
We also see random no mic detected on windows 7 pro with this Chrome version.
Anyone else sees these issues?
Thanks
Osama

···

On Nov 28, 2017, at 5:55 AM, Boris Grozev <boris@jitsi.org> wrote:

Hi Jonas,

I'm afraid I can't help much, but your interpretation seems correct.

type=206 and size=26 strongly suggests a PLI packet sent from the bridge, and if the sender doesn't handle PLIs freezes are exactly what you would see. The bridge will consume PLI/FIR packets that it receives, and will generate PLIs on its own (paced to at most one per 300ms, and it gives up after a while, which explains why your sender only receives a few PLIs).

err=7 indicates an authentication failure[0], i.e. the authentication tag in the packet didn't match the one that was computed, but it's hard to tell what actually caused it.

Regards,
Boris

[0] https://github.com/cisco/libsrtp/blob/master/include/srtp.h#L173

On 28/11/2017 01:27, Jonas Jonas wrote:
Hello,
We are doing screen sharing only calls with lib-jitsi-meet against our deployment of Prosody/Jicofo/Videobridge but are experiencing video freezing + not being able to recover from time to time. We are using latest Chrome on both sides, and when this happens, we can tell from webrtc-internals that the receiver is still receiving bits, but is not able to decode them.
From webrtc-internals it seems that the receiver is sending Plis (lots of them) and NACKS when this happens, but we do not see FIRs being requested or sent. The sender generally receives only a few Plis and no NACKS. And no FIRs requested.
This from the Chrome debug log seems suspicious (number of these seem to correspond to the number of Plis):
[7672:5904:1127/041533.851:WARNING:srtpsession.cc(140)] Failed to unprotect SRTCP packet, err=7
[7672:5904:1127/041533.851:ERROR:channel.cc(787)] Failed to unprotect video RTCP packet: size=26, type=206
Increasing org.jitsi.impl.neomedia.transform.CachingTransformer.CACHE_SIZE_MILLIS in the video bridge config, appears to make the freezes less likely to happen (suggesting that NACK+RTC is working on the viewer side?), but still, when a freeze eventually happens, it cannot recover.
Any help / pointers to what might be going on here would be much appreciated.
Thanks,
Jonas
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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


#4

Thanks Boris,

It seems we are able to reproduce this with meet.jit.si as well. See
detailed descriptions and logs here:
https://github.com/jitsi/jitsi-videobridge/issues/580

Do you think it is a Chrome or a VideoBridge issue? Would be great if we
could work with someone to resolve this.

Thanks,
Jonas

···

On 28 November 2017 at 11:55, Boris Grozev <boris@jitsi.org> wrote:

Hi Jonas,

I'm afraid I can't help much, but your interpretation seems correct.

type=206 and size=26 strongly suggests a PLI packet sent from the bridge,
and if the sender doesn't handle PLIs freezes are exactly what you would
see. The bridge will consume PLI/FIR packets that it receives, and will
generate PLIs on its own (paced to at most one per 300ms, and it gives up
after a while, which explains why your sender only receives a few PLIs).

err=7 indicates an authentication failure[0], i.e. the authentication tag
in the packet didn't match the one that was computed, but it's hard to tell
what actually caused it.

Regards,
Boris

[0] https://github.com/cisco/libsrtp/blob/master/include/srtp.h#L173

On 28/11/2017 01:27, Jonas Jonas wrote:

Hello,

We are doing screen sharing only calls with lib-jitsi-meet against our
deployment of Prosody/Jicofo/Videobridge but are experiencing video
freezing + not being able to recover from time to time. We are using latest
Chrome on both sides, and when this happens, we can tell from
webrtc-internals that the receiver is still receiving bits, but is not able
to decode them.

From webrtc-internals it seems that the receiver is sending Plis (lots
of them) and NACKS when this happens, but we do not see FIRs being
requested or sent. The sender generally receives only a few Plis and no
NACKS. And no FIRs requested.

This from the Chrome debug log seems suspicious (number of these seem to
correspond to the number of Plis):

[7672:5904:1127/041533.851:WARNING:srtpsession.cc(140)] Failed to
unprotect SRTCP packet, err=7

[7672:5904:1127/041533.851:ERROR:channel.cc(787)] Failed to unprotect
video RTCP packet: size=26, type=206

Increasing org.jitsi.impl.neomedia.transform.CachingTransformer.CACHE_SIZE_MILLIS
in the video bridge config, appears to make the freezes less likely to
happen (suggesting that NACK+RTC is working on the viewer side?), but
still, when a freeze eventually happens, it cannot recover.

Any help / pointers to what might be going on here would be much
appreciated.

Thanks,
Jonas

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