[jitsi-users] Jitsi Meet Videobridge minimum bandwdith limit


#1

Dear All,

Is there a way to set/control the minimum bandwidth required for conference
so that auto-bandwidth adjustment doesn't keep dropping below a limit, when
network is bad in one of participant of a conference?

The reason I asked this is because I noticed that the jitsi
meet/videobridge (when it detects network is bad) sometimes will drop
participant bandwidth way too low (e.g. 2Mbps to 70kbps) that make the
picture very blur and unnoticeable.

I noticed there is setting MIN_ASSUMED_ENDPOINT_BITRATE_BPS in videobridge
with default value 400000 bps which seems related.

But for my case, the bandwidth still drops below that value.

Best Regards,
KC


#2

Hi,

Dear All,

Is there a way to set/control the minimum bandwidth required for
conference so that auto-bandwidth adjustment doesn't keep dropping below
a limit, when network is bad in one of participant of a conference?

The reason I asked this is because I noticed that the jitsi
meet/videobridge (when it detects network is bad) sometimes will drop
participant bandwidth way too low (e.g. 2Mbps to 70kbps) that make the
picture very blur and unnoticeable.

I noticed there is setting MIN_ASSUMED_ENDPOINT_BITRATE_BPS in
videobridge with default value 400000 bps which seems related.

It is the clients who drop their bitrate, the bridge doesn't control that directly. The setting you found is only used when adaptive last-n is enabled, when the bridge decides how many video streams to forward.

For your issue, enabling RTCP termination might help (see this doc[0], but have in mind that it is a bit outdated).

Regards,
Boris

[0] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rtcp-termination.md

···

On 14/01/16 05:34, KC OOI wrote:


#3

Hi Boris,

Thanks for the info.
After reading it, If I understand correctly, rtp-termination can provide a
way (e.g. FallbackingRTCPTerminationStrategy /
HighestQualityRTCPTerminationStrategy) to ignore/cancel a poor client-side
bandwidth feedback on bandwidth availability so that particular client with
poor connection doesn't affect the entire conference. Correct me if I
misunderstood it.

What I plan to do now is little bit difference. I wish that poor connection
client can transmit at least a specified bandwidth amount.
My current thought is to add a bandwidth setting slider on jitsi-meet UI so
that the poor connection sender can manually set a value and its transmit
video not below the bandwidth setting (e.g. 512kbps, instead of allowing it
to drop from 2Mbps till 70kbps for my previous case).

From my previous testings, the poor client-side mentioned was actually had

high bandwidth but bad network connection, which caused a lot of packets
loss and auto bandwidth adjust too low.

Not sure if my thought is feasible or not. Need some advises and
directions...

Thanks.

···

On Thu, Jan 14, 2016 at 6:29 PM, Boris Grozev <boris@jitsi.org> wrote:

Hi,

On 14/01/16 05:34, KC OOI wrote:

Dear All,

Is there a way to set/control the minimum bandwidth required for
conference so that auto-bandwidth adjustment doesn't keep dropping below
a limit, when network is bad in one of participant of a conference?

The reason I asked this is because I noticed that the jitsi
meet/videobridge (when it detects network is bad) sometimes will drop
participant bandwidth way too low (e.g. 2Mbps to 70kbps) that make the
picture very blur and unnoticeable.

I noticed there is setting MIN_ASSUMED_ENDPOINT_BITRATE_BPS in
videobridge with default value 400000 bps which seems related.

It is the clients who drop their bitrate, the bridge doesn't control that
directly. The setting you found is only used when adaptive last-n is
enabled, when the bridge decides how many video streams to forward.

For your issue, enabling RTCP termination might help (see this doc[0], but
have in mind that it is a bit outdated).

Regards,
Boris

[0]
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rtcp-termination.md

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

--
Best Regards,
KC