[jitsi-users] Jitsi-Meet Packet-loss testing


#1

So, I am trying to do some bitrate testing and evaluation of the
VideoBridge. I was curious if you guys have documented the tools you use
for your own testing?

I am currently using the latest stable release.

Currently we have a router that we can connect to, and set packet loss, and
some other conditions.

I was trying Network Link Conditioner on Mac, (But it doesn't seem to
effect the UDP traffic, or basically Jitsi doesn't register any loss.)

We currently have a bridge that does RTCP termination, and only supports
NACK, and in the 10% loss scenario via our router, it is able to NACK its
way into having a usable stream.

Jitsi-Meet however, seems to keep negotiating lower and lower, even though
it seems to reach a point where the stream probably would be stable, until
eventually it just shuts off the video entirely.

As far as I am aware your RTCP termination strategies are configurable, and
you are doing a lot of things for calculating when to use FEC vs NACK, etc
etc...

Any ideas on why I am seeing the above behavior, and more particularly what
we ought to research and configure to understand this situation better,
would be greatly appreciated.

···

--
- Jason Thomas


#2

Hi Jason,

So, I am trying to do some bitrate testing and evaluation of the VideoBridge. I was curious if you guys have documented the tools you use for your own testing?

I am currently using the latest stable release.

Currently we have a router that we can connect to, and set packet loss, and some other conditions.

I was trying Network Link Conditioner on Mac, (But it doesn't seem to effect the UDP traffic, or basically Jitsi doesn't register any loss.)

Network Link Conditioner is one of the tools that we use, and in our setup it works for UDP. I don't think it works with the loopback interface, though.

We currently have a bridge that does RTCP termination, and only supports NACK, and in the 10% loss scenario via our router, it is able to NACK its way into having a usable stream.

Jitsi-Meet however, seems to keep negotiating lower and lower, even though it seems to reach a point where the stream probably would be stable, until eventually it just shuts off the video entirely >
As far as I am aware your RTCP termination strategies are configurable, and you are doing a lot of things for calculating when to use FEC vs NACK, etc etc...

I don't think any configuration other than the default is currently sensible. We don't have FEC at the moment (although Brian is working on an implementation).

Any ideas on why I am seeing the above behavior, and more particularly what we ought to research and configure to understand this situation better, would be greatly appreciated.

There's a couple of factors here.

First, Google Congestion Control will keep dropping its estimate of the available bandwidth as long as the loss is >10% [0]. I would suggest limiting the bandwidth instead of adding a constant amount of packet loss (and if you do add constant packet loss, keep it at a lower value).

Second, the googEnableVideoSuspendBelowMinBitrate PeerConnection option. If it is enabled, the browser will completely disabled the video stream if the bandwidth estimation is too low. If it is disabled, it will keep sending at the lowest configured rate.

In Jitsi-Meet this option is enabled for the p2p connection, and disabled for the jitsi-videobridge connection, which would explain what you are seeing.

Regards,
Boris

[0] https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02#section-6

···

On 11/01/2018 11:17, Jason Thomas wrote:


#3

Thanks Boris,

Disabling P2P mode for my bridge resolved the issue with the Network Link
Conditioner per your suggestion.

Now that the connections are going through the VideoBridge, I am able to
throttle bandwidth, and it works very similar to your demo
https://www.youtube.com/watch?v=mbOMbgF0sdo at around 8:40.

I am still seeing intermittently when testing "Video for fellow jister has
been turned off to save bandwidth."

Looking into the source this seems to result from:
JitsiParticipantConnectionStatus.INACTIVE

Is there logic somewhere that causes the client to set its video inactive
intentionally, and can this be toggled, or tweaked?

Thanks for the help so far, and for making this awesome project.

- Jason Thomas.

···

On Jan 11, 2018 11:39 AM, "Boris Grozev" <boris@jitsi.org> wrote:

Hi Jason,

On 11/01/2018 11:17, Jason Thomas wrote:

So, I am trying to do some bitrate testing and evaluation of the
VideoBridge. I was curious if you guys have documented the tools you use
for your own testing?

I am currently using the latest stable release.

Currently we have a router that we can connect to, and set packet loss,
and some other conditions.

I was trying Network Link Conditioner on Mac, (But it doesn't seem to
effect the UDP traffic, or basically Jitsi doesn't register any loss.)

Network Link Conditioner is one of the tools that we use, and in our setup
it works for UDP. I don't think it works with the loopback interface,
though.

We currently have a bridge that does RTCP termination, and only supports
NACK, and in the 10% loss scenario via our router, it is able to NACK its
way into having a usable stream.

Jitsi-Meet however, seems to keep negotiating lower and lower, even
though it seems to reach a point where the stream probably would be stable,
until eventually it just shuts off the video entirely >
As far as I am aware your RTCP termination strategies are configurable,
and you are doing a lot of things for calculating when to use FEC vs NACK,
etc etc...

I don't think any configuration other than the default is currently
sensible. We don't have FEC at the moment (although Brian is working on an
implementation).

Any ideas on why I am seeing the above behavior, and more particularly
what we ought to research and configure to understand this situation
better, would be greatly appreciated.

There's a couple of factors here.

First, Google Congestion Control will keep dropping its estimate of the
available bandwidth as long as the loss is >10% [0]. I would suggest
limiting the bandwidth instead of adding a constant amount of packet loss
(and if you do add constant packet loss, keep it at a lower value).

Second, the googEnableVideoSuspendBelowMinBitrate PeerConnection option.
If it is enabled, the browser will completely disabled the video stream if
the bandwidth estimation is too low. If it is disabled, it will keep
sending at the lowest configured rate.

In Jitsi-Meet this option is enabled for the p2p connection, and disabled
for the jitsi-videobridge connection, which would explain what you are
seeing.

Regards,
Boris

[0] https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02#section-6


#4

Hi,

> Thanks Boris,
>
> Disabling P2P mode for my bridge resolved the issue with the Network
> Link Conditioner per your suggestion.
>
> Now that the connections are going through the VideoBridge, I am able to
> throttle bandwidth, and it works very similar to your demo
> https://www.youtube.com/watch?v=mbOMbgF0sdo
> <https://www.youtube.com/watch?v=mbOMbgF0sdo> at around 8:40.
>
> I am still seeing intermittently when testing "Video for fellow jister
> has been turned off to save bandwidth."
Videobridge does it's own bandwidth estimation, and if it determines that there isn't enough bandwidth for a receiver it will stop sending video to it. Effectively the "suspend" option that I described before is enabled in the bridge-to-receiver leg.

I think the way to disable this behavior with the latest versions is to set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

This should probably be used only in tests, as it disables the congestion control

Regards,
Boris

···

On 12/01/2018 10:41, Jason Thomas wrote:


#5

Hi Boris,

I think the way to disable this behavior with the latest versions is to

set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

Alright, I definitely want the congestion control in the long run, but it
would be good just as a sanity check for what I am seeing.

Is the suspend option required for congestion control to operate, or does
it just happen that this flag disabled all congestion control, and thus
this option as well?

I have generated a recording of the case of 2.5% packet loss in both
directions with Jitsi-Meet, which I will send to you directly.

It seems to be able to handle the loss with NACK, but it is continually
halting the video on both ends, eventually permanently.

In the long run, would FEC be able to handle the above situation by erasing
the packet loss?

I show the behavior on our current video bridge (a highly altered version
of licode), which only supports NACK, and doesn't do any congestion control
on the bridge,
just to demonstrate that the call quality is stable using just NACK in this
situation, and doesn't degrade.

- Jason Thomas.

···

On Fri, Jan 12, 2018 at 11:02 AM, Boris Grozev <boris@jitsi.org> wrote:

Hi,

On 12/01/2018 10:41, Jason Thomas wrote:
> Thanks Boris,
>
> Disabling P2P mode for my bridge resolved the issue with the Network
> Link Conditioner per your suggestion.
>
> Now that the connections are going through the VideoBridge, I am able to
> throttle bandwidth, and it works very similar to your demo
> https://www.youtube.com/watch?v=mbOMbgF0sdo
> <https://www.youtube.com/watch?v=mbOMbgF0sdo> at around 8:40.
>
> I am still seeing intermittently when testing "Video for fellow jister
> has been turned off to save bandwidth."
Videobridge does it's own bandwidth estimation, and if it determines that
there isn't enough bandwidth for a receiver it will stop sending video to
it. Effectively the "suspend" option that I described before is enabled in
the bridge-to-receiver leg.

I think the way to disable this behavior with the latest versions is to
set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

This should probably be used only in tests, as it disables the congestion
control

Regards,
Boris

--
- Jason Thomas
   http://jasonthom.as


#6

org.jitsi.videobridge.TRUST_BWE=false

So, now the received video is completely stable even up to 10% received
packet loss (Setting x-google-min-bitrate seems to put a lower floor on the
downward bitrate negotiation of death).

The issue is the remote end (With no simulated packet loss) continually
sees 'Fellow Vuer is having connectivity issues,' and the transmitted video
pauses over and over again.

I assume Jitsi is keeping a buffer of packets that the remote end is
NACKing.

Is this message due to similar detection logic from the bridge, or is it
something that happens when the track pauses due to decoding errors?

- Jason Thomas.

···

On Fri, Jan 12, 2018 at 11:42 AM, Jason Thomas <mail@jasonthom.as> wrote:

Hi Boris,

> I think the way to disable this behavior with the latest versions is to
set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

Alright, I definitely want the congestion control in the long run, but it
would be good just as a sanity check for what I am seeing.

Is the suspend option required for congestion control to operate, or does
it just happen that this flag disabled all congestion control, and thus
this option as well?

I have generated a recording of the case of 2.5% packet loss in both
directions with Jitsi-Meet, which I will send to you directly.

It seems to be able to handle the loss with NACK, but it is continually
halting the video on both ends, eventually permanently.

In the long run, would FEC be able to handle the above situation by
erasing the packet loss?

I show the behavior on our current video bridge (a highly altered version
of licode), which only supports NACK, and doesn't do any congestion control
on the bridge,
just to demonstrate that the call quality is stable using just NACK in
this situation, and doesn't degrade.

- Jason Thomas.

On Fri, Jan 12, 2018 at 11:02 AM, Boris Grozev <boris@jitsi.org> wrote:

Hi,

On 12/01/2018 10:41, Jason Thomas wrote:
> Thanks Boris,
>
> Disabling P2P mode for my bridge resolved the issue with the Network
> Link Conditioner per your suggestion.
>
> Now that the connections are going through the VideoBridge, I am able to
> throttle bandwidth, and it works very similar to your demo
> https://www.youtube.com/watch?v=mbOMbgF0sdo
> <https://www.youtube.com/watch?v=mbOMbgF0sdo> at around 8:40.
>
> I am still seeing intermittently when testing "Video for fellow jister
> has been turned off to save bandwidth."
Videobridge does it's own bandwidth estimation, and if it determines that
there isn't enough bandwidth for a receiver it will stop sending video to
it. Effectively the "suspend" option that I described before is enabled in
the bridge-to-receiver leg.

I think the way to disable this behavior with the latest versions is to
set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

This should probably be used only in tests, as it disables the congestion
control

Regards,
Boris

--
- Jason Thomas
   http://jasonthom.as

--
- Jason Thomas
   http://jasonthom.as


#7

Hi Jason,

I'm sorry for nor responding on this sooner.

Hi Boris,

> I think the way to disable this behavior with the latest versions is to set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

Alright, I definitely want the congestion control in the long run, but it would be good just as a sanity check for what I am seeing.

Is the suspend option required for congestion control to operate, or does it just happen that this flag disabled all congestion control, and thus this option as well?

The flag effectively disables taking any action for congestion control on the bridge->receiver leg, which results in the sending of all configured streams (highest resolution for the selected endpoint, 180p if available for anyone else).

I have generated a recording of the case of 2.5% packet loss in both directions with Jitsi-Meet, which I will send to you directly.

It seems to be able to handle the loss with NACK, but it is continually halting the video on both ends, eventually permanently.

In the long run, would FEC be able to handle the above situation by erasing the packet loss?

I'm not sure what version of the bridge you were using, but 1019 introduced a bug which we suspect brakes NACK/RTX (the bug is fixed in master). I don't expect 2.5% packet loss to cause much freezing, so I suspect you might be running with the bug.

For repair with NACK and retransmissions the RTT is very important. If you are running locally with an RTT of ~1ms, you can repair a lot of missing packets quickly, but it isn't realistic. So testing with a realistic delay is important.

FEC will help with this, especially in high RTT scenarios.

> The issue is the remote end (With no simulated packet loss) continually
> sees 'Fellow Vuer is having connectivity issues,' and the transmitted
> video pauses over and over again.

This is also consistent with the bug with NACKs.

>
> JVB 2018-01-12 22:52:10.337 WARNING: [56815]
> org.jitsi.videobridge.cc.SimulcastController.log() A jump was detected
> in the picture IDs.

I don't think we are seeing this one, and I don't know how to interpret it. Perhaps George will know.

> So, commenting out the following lines of code in the videobridge seemed
> to fix the continuous freezing and 'Fellow User is having connectivity
> issues.' message on the remote end.
>
> Is it possible the logic calculating the new dstPictureID could be wrong
> somehow?

I don't know. If you want to experiment with disabling the rewriting of PictureID, you can use this property:
org.jitsi.videobridge.ENABLE_VP8_PICID_REWRITING=false

Since the freezing problem that you see is consistent with the bug that we recently fixed, I would suggest to update the bridge and see if that helps. If it doesn't, check if disabling PictureID rewriting makes a difference.

Regards,
Boris

···

On 12/01/2018 12:42, Jason Thomas wrote:
On 12/01/2018 13:12, Jason Thomas wrote:
On 12/01/2018 16:58, Jason Thomas wrote:
On 12/01/2018 17:18, Jason Thomas wrote:


#8

Just some more information on this. It appears in the case where I set
constant packet loss (Of any amount really), I see on the VideoBridge
continually the message:

[ C1 ] -> 10% Loss Up -> [ JVB ] -> [ C2 ]

JVB 2018-01-12 22:52:10.337 WARNING: [56815]
org.jitsi.videobridge.cc.SimulcastController.log() A jump was detected in
the picture IDs.

This is followed by the remote client continually freezing and getting the
'Fellow User is having connectivity issues." message.

This doesn't appear when I set a constant receive packet loss.

[ C1 ] <- 10% Loss Down <- [ JVB ] <- [ C2 ]

I see similar NACKs coming from the remote end, but it just keeps sending
NACKs and the video playback is normal.

- Jason Thomas.

···

On Fri, Jan 12, 2018 at 12:12 PM, Jason Thomas <mail@jasonthom.as> wrote:

>org.jitsi.videobridge.TRUST_BWE=false

So, now the received video is completely stable even up to 10% received
packet loss (Setting x-google-min-bitrate seems to put a lower floor on the
downward bitrate negotiation of death).

The issue is the remote end (With no simulated packet loss) continually
sees 'Fellow Vuer is having connectivity issues,' and the transmitted video
pauses over and over again.

I assume Jitsi is keeping a buffer of packets that the remote end is
NACKing.

Is this message due to similar detection logic from the bridge, or is it
something that happens when the track pauses due to decoding errors?

- Jason Thomas.

On Fri, Jan 12, 2018 at 11:42 AM, Jason Thomas <mail@jasonthom.as> wrote:

Hi Boris,

> I think the way to disable this behavior with the latest versions is
to set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

Alright, I definitely want the congestion control in the long run, but it
would be good just as a sanity check for what I am seeing.

Is the suspend option required for congestion control to operate, or does
it just happen that this flag disabled all congestion control, and thus
this option as well?

I have generated a recording of the case of 2.5% packet loss in both
directions with Jitsi-Meet, which I will send to you directly.

It seems to be able to handle the loss with NACK, but it is continually
halting the video on both ends, eventually permanently.

In the long run, would FEC be able to handle the above situation by
erasing the packet loss?

I show the behavior on our current video bridge (a highly altered version
of licode), which only supports NACK, and doesn't do any congestion control
on the bridge,
just to demonstrate that the call quality is stable using just NACK in
this situation, and doesn't degrade.

- Jason Thomas.

On Fri, Jan 12, 2018 at 11:02 AM, Boris Grozev <boris@jitsi.org> wrote:

Hi,

On 12/01/2018 10:41, Jason Thomas wrote:
> Thanks Boris,
>
> Disabling P2P mode for my bridge resolved the issue with the Network
> Link Conditioner per your suggestion.
>
> Now that the connections are going through the VideoBridge, I am able
to
> throttle bandwidth, and it works very similar to your demo
> https://www.youtube.com/watch?v=mbOMbgF0sdo
> <https://www.youtube.com/watch?v=mbOMbgF0sdo> at around 8:40.
>
> I am still seeing intermittently when testing "Video for fellow jister
> has been turned off to save bandwidth."
Videobridge does it's own bandwidth estimation, and if it determines
that there isn't enough bandwidth for a receiver it will stop sending video
to it. Effectively the "suspend" option that I described before is enabled
in the bridge-to-receiver leg.

I think the way to disable this behavior with the latest versions is to
set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

This should probably be used only in tests, as it disables the
congestion control

Regards,
Boris

--
- Jason Thomas
   http://jasonthom.as

--
- Jason Thomas
   http://jasonthom.as

--
- Jason Thomas
   http://jasonthom.as


#9

Boris,

I'm sorry for nor responding on this sooner.

No worries, I appreciate that you guys are busy working on the project :slight_smile:

Since the freezing problem that you see is consistent with the bug that

we recently fixed
Awesome, I will test with the latest videobridge. At the moment I am
testing and developing against the last stable release.

For repair with NACK and retransmissions the RTT is very important. If

you are running locally with an RTT of ~1ms, you can repair a lot of
missing packets quickly, but it isn't realistic. So testing with a
realistic delay is important.

Yeah, I totally agree, this is more just a sanity check that we run on our
current infrastructure.
We will definitely try to make some more realistic scenarios to test
against in the long run.

Cheers,
- Jason Thomas.

···

On Sat, Jan 27, 2018 at 10:48 AM, Boris Grozev <boris@jitsi.org> wrote:

Hi Jason,

I'm sorry for nor responding on this sooner.

On 12/01/2018 12:42, Jason Thomas wrote:

Hi Boris,

> I think the way to disable this behavior with the latest versions is
to set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

Alright, I definitely want the congestion control in the long run, but it
would be good just as a sanity check for what I am seeing.

Is the suspend option required for congestion control to operate, or does
it just happen that this flag disabled all congestion control, and thus
this option as well?

The flag effectively disables taking any action for congestion control on
the bridge->receiver leg, which results in the sending of all configured
streams (highest resolution for the selected endpoint, 180p if available
for anyone else).

I have generated a recording of the case of 2.5% packet loss in both
directions with Jitsi-Meet, which I will send to you directly.

It seems to be able to handle the loss with NACK, but it is continually
halting the video on both ends, eventually permanently.

In the long run, would FEC be able to handle the above situation by
erasing the packet loss?

I'm not sure what version of the bridge you were using, but 1019
introduced a bug which we suspect brakes NACK/RTX (the bug is fixed in
master). I don't expect 2.5% packet loss to cause much freezing, so I
suspect you might be running with the bug.

For repair with NACK and retransmissions the RTT is very important. If you
are running locally with an RTT of ~1ms, you can repair a lot of missing
packets quickly, but it isn't realistic. So testing with a realistic delay
is important.

FEC will help with this, especially in high RTT scenarios.

On 12/01/2018 13:12, Jason Thomas wrote:
> The issue is the remote end (With no simulated packet loss) continually
> sees 'Fellow Vuer is having connectivity issues,' and the transmitted
> video pauses over and over again.

This is also consistent with the bug with NACKs.

On 12/01/2018 16:58, Jason Thomas wrote:
>
> JVB 2018-01-12 22:52:10.337 WARNING: [56815]
> org.jitsi.videobridge.cc.SimulcastController.log() A jump was detected
> in the picture IDs.

I don't think we are seeing this one, and I don't know how to interpret
it. Perhaps George will know.

On 12/01/2018 17:18, Jason Thomas wrote:
> So, commenting out the following lines of code in the videobridge seemed
> to fix the continuous freezing and 'Fellow User is having connectivity
> issues.' message on the remote end.
>
> Is it possible the logic calculating the new dstPictureID could be wrong
> somehow?

I don't know. If you want to experiment with disabling the rewriting of
PictureID, you can use this property:
org.jitsi.videobridge.ENABLE_VP8_PICID_REWRITING=false

Since the freezing problem that you see is consistent with the bug that we
recently fixed, I would suggest to update the bridge and see if that helps.
If it doesn't, check if disabling PictureID rewriting makes a difference.

Regards,
Boris

--
- Jason Thomas
   http://jasonthom.as


#10

So, commenting out the following lines of code in the videobridge seemed to
fix the continuous freezing and 'Fellow User is having connectivity
issues.' message on the remote end.

Is it possible the logic calculating the new dstPictureID could be wrong
somehow?

I'm seeing this with my added details to the logging,
JVB 2018-01-12 23:13:48.689 WARNING: [196]
org.jitsi.videobridge.cc.SimulcastController.log() A jump was detected in
the picture IDs: 1381 - 14687
JVB 2018-01-12 23:13:49.254 WARNING: [196]
org.jitsi.videobridge.cc.SimulcastController.log() A jump was detected in
the picture IDs: 1398 - 14687

diff --git
a/src/main/java/org/jitsi/videobridge/cc/SimulcastController.java
b/src/main/java/org/jitsi/videobridge/cc/SimulcastController.java
index 09ff99c..b3d0f21 100644
--- a/src/main/java/org/jitsi/videobridge/cc/SimulcastController.java
+++ b/src/main/java/org/jitsi/videobridge/cc/SimulcastController.java
@@ -1020,9 +1020,9 @@ private int calculatePictureID(RawPacket pkt)
                 if (((dstPictureID - getMaxPictureID()) & 0x7FFF) > 200
                     >> ((dstPictureID - getMaxPictureID()) & 0x7FFF) >
0x7F00)
                 {
- pidDelta = (getMaxPictureID() + 1 - srcPID) & 0x7FFF;
- dstPictureID = (srcPID + pidDelta) & 0x7FFF;
- logger.warn("A jump was detected in the picture IDs.");
+ //pidDelta = (getMaxPictureID() + 1 - srcPID) & 0x7FFF;
+ //dstPictureID = (srcPID + pidDelta) & 0x7FFF;
+ logger.warn("A jump was detected in the picture IDs: "
+ dstPictureID + " - " + pidDelta);
                 }
             }
             else

- Jason Thomas.

···

On Fri, Jan 12, 2018 at 3:58 PM, Jason Thomas <mail@jasonthom.as> wrote:

Just some more information on this. It appears in the case where I set
constant packet loss (Of any amount really), I see on the VideoBridge
continually the message:

[ C1 ] -> 10% Loss Up -> [ JVB ] -> [ C2 ]

JVB 2018-01-12 22:52:10.337 WARNING: [56815] org.jitsi.videobridge.cc.SimulcastController.log()
A jump was detected in the picture IDs.

This is followed by the remote client continually freezing and getting the
'Fellow User is having connectivity issues." message.

This doesn't appear when I set a constant receive packet loss.

[ C1 ] <- 10% Loss Down <- [ JVB ] <- [ C2 ]

I see similar NACKs coming from the remote end, but it just keeps sending
NACKs and the video playback is normal.

- Jason Thomas.

On Fri, Jan 12, 2018 at 12:12 PM, Jason Thomas <mail@jasonthom.as> wrote:

>org.jitsi.videobridge.TRUST_BWE=false

So, now the received video is completely stable even up to 10% received
packet loss (Setting x-google-min-bitrate seems to put a lower floor on the
downward bitrate negotiation of death).

The issue is the remote end (With no simulated packet loss) continually
sees 'Fellow Vuer is having connectivity issues,' and the transmitted video
pauses over and over again.

I assume Jitsi is keeping a buffer of packets that the remote end is
NACKing.

Is this message due to similar detection logic from the bridge, or is it
something that happens when the track pauses due to decoding errors?

- Jason Thomas.

On Fri, Jan 12, 2018 at 11:42 AM, Jason Thomas <mail@jasonthom.as> wrote:

Hi Boris,

> I think the way to disable this behavior with the latest versions is
to set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

Alright, I definitely want the congestion control in the long run, but
it would be good just as a sanity check for what I am seeing.

Is the suspend option required for congestion control to operate, or
does it just happen that this flag disabled all congestion control, and
thus this option as well?

I have generated a recording of the case of 2.5% packet loss in both
directions with Jitsi-Meet, which I will send to you directly.

It seems to be able to handle the loss with NACK, but it is continually
halting the video on both ends, eventually permanently.

In the long run, would FEC be able to handle the above situation by
erasing the packet loss?

I show the behavior on our current video bridge (a highly altered
version of licode), which only supports NACK, and doesn't do any congestion
control on the bridge,
just to demonstrate that the call quality is stable using just NACK in
this situation, and doesn't degrade.

- Jason Thomas.

On Fri, Jan 12, 2018 at 11:02 AM, Boris Grozev <boris@jitsi.org> wrote:

Hi,

On 12/01/2018 10:41, Jason Thomas wrote:
> Thanks Boris,
>
> Disabling P2P mode for my bridge resolved the issue with the Network
> Link Conditioner per your suggestion.
>
> Now that the connections are going through the VideoBridge, I am able
to
> throttle bandwidth, and it works very similar to your demo
> https://www.youtube.com/watch?v=mbOMbgF0sdo
> <https://www.youtube.com/watch?v=mbOMbgF0sdo> at around 8:40.
>
> I am still seeing intermittently when testing "Video for fellow jister
> has been turned off to save bandwidth."
Videobridge does it's own bandwidth estimation, and if it determines
that there isn't enough bandwidth for a receiver it will stop sending video
to it. Effectively the "suspend" option that I described before is enabled
in the bridge-to-receiver leg.

I think the way to disable this behavior with the latest versions is to
set this property in jitsi-videobridge's config file:
org.jitsi.videobridge.TRUST_BWE=false

This should probably be used only in tests, as it disables the
congestion control

Regards,
Boris

--
- Jason Thomas
   http://jasonthom.as

--
- Jason Thomas
   http://jasonthom.as

--
- Jason Thomas
   http://jasonthom.as

--
- Jason Thomas
   http://jasonthom.as