Any ideas why this is the culprit for poor video?
IIUC you didn’t test it on a fresh setup (you upgraded the old one) while keeping JVB and Jibri on the old version. Is it correct?
@emrah I did do 1 test using the video bridge installed on the instance and it was the same result. But Jibri version 8.0 is up to date.
And you are always sending the receiver constraints in those tests?
Emrah, to demonstrate again, I just updated my video bridge to:
jitsi-videobridge2 2.2-63-g252d14bc-1
Re-enabled the sourceNaming and recieveMultipleStreams, and here was the result was the same, video is here: Glitch Gaming Platform
@damencho Yes, I always set the receiver and sender constraints. And my chrome-internals are set to 120fps for screensharing.
Also @emrah, I forget in my last post, I increased the defaults in the /etc/jitsi/videobridge/jvb.conf:
cc {
onstage-preferred-framerate=60
allow-oversend-onstage=true
max-oversend-bitrate=5000 kbps
}
I think there either the fps or bitrate is being capped somewhere.
We have been having a similar issue for weeks now using meet.jit.si. The following cases occur frequently and at off-times (e.g. Sat, Sun, all day | night) on Jitsi’s us-east-1 server. We are in the central Virginia and D.C. area.
Case 1:
- Bob starts a conference on meet.jit.si
- Jane joins the conference and Bob’s connection becomes Suboptimal and remains that way. Jane’s connection is barely good (under 1000 Kbps).
- Bob leaves the conference and then rejoins the conference. Bob’s connection then becomes barely good (under 1000 Kbps).
Case 2:
- Bob starts a conference on meet.jit.si
- Jane joins the conference and Bob’s connection becomes Suboptimal and remains that way.
- Mary joins the conference. The connections for Jane and Mary are both barely good (under 1000 Kbps)
- Bob leaves the conference. The connections for Jane and Mary become Poor or Suboptimal, but eventually become barely good (under 1000 Kbps).
- Bob rejoins the conference. Bob’s connection then becomes barely good (under 1000 Kbps) and everybody is a bit happier
This, unfortunately, happens all the time now. This is not a bandwidth issue for us. On the contrary:
Edit: Just tested on beta.meet.jit.si and above issue is the same - also on us-east-1 server. Also tested on alpha.jitsi.net with much better results: Connection: 2000 - 3000 Kbps which is great and what we are looking for. However, this is VP8, moderated, and on a different Jitsi server I think (west-cost ???). So, why the big difference? VP8? Moderated? Different server with little traffic?
Last note from me here, with my latest update of the video-bridge, all the streams are now choppy, even if lib-jitsi-meet mutlistream option is off. Looking back at this pull request, multistream is always on in the latest version of the bridge and cannot be turned off:
Two things:
- The problem seems to be mutlistream as having a frame rate or bandwidth limitation that is independent of the available bandwidth or the constraints set in lib-jitsi-meet or the jitsi-config.
- Another concern is the forcing of the developer to use certain protocols instead of making them optional and configurable.
Should this be logged under lib-jitsi-meet or the jvb as a bug?
Upload the logs from lib-jitsi-meet from a problem session.
Update, I made two logs:
Receiver (The user watching the screenshare and seeing it choppy): lib-jist-meet-reciever.log · GitHub
Sender (The user who is sharing their screen): lib-jisti-meet-debug.log · GitHub
And this occurs when sendMultipleVideoStreams and sourceNameSignaling is enabled.
SenderSourceConstraints: {"sourceName":"ee621273-v0","maxHeight":180}
You are requesting 180p for the video.
And the sender constraints seems suspicious setSenderVideoConstraint: 180, sourceName: 6354ac70-v0
I’m not so familiar with the sender and receiver constraints … but you can test this on meet.jit.si and see how it behaves (check js console logs), what are the constraints sent from the sender and the constraints by the receiver when viewing the screen share on large screen and make sure your app does the same.
That seems very very strange and I don’t think that is correct. My here are my chrome://webrtc-internals/
They are indicating 1080, not 180. I also have my values set with:
room.setReceiverVideoConstraint(1080);
room.setSenderVideoConstraint(1080);
Also:
- A smaller screen should be less choppy not more because of reduced bandwidth? Or am I wrong in my thinking
- Why does this only occur when sendMultipleVideoStreams and sourceNameSignaling is enabled?
Also looking at the code, the only place where I am seeing SenderSourceConstraints is in the BridgeChannel.js for when FeatureFlags.isSourceNameSignalingEnabled().
case 'SenderSourceConstraints': {
if (FeatureFlags.isSourceNameSignalingEnabled()) {
const { sourceName, maxHeight } = obj;
if (typeof sourceName === 'string' && typeof maxHeight === 'number') {
// eslint-disable-next-line object-property-newline
logger.info(`SenderSourceConstraints: ${JSON.stringify({ sourceName, maxHeight })}`);
emitter.emit(
RTCEvents.SENDER_VIDEO_CONSTRAINTS_CHANGED, {
sourceName,
maxHeight
}
);
} else {
logger.error(`Invalid SenderSourceConstraints: ${JSON.stringify(obj)}`);
}
}
break;
}
I am not where channel.onmessage is getting called, but could this be getting the wrong information somewhere else?
This is how it works, you need to tell jvb which resolution you want based on the area where you will display it. In the latest versions there is no option to enable/disable sendMultipleVideoStreams and sourceNameSignaling.
Try setting setReceiverConstraints:
lib-jitsi-meet API (low level) | Jitsi Meet Check 35.
With setReceiverVideoConstraint you announce to the bridge I have this kind of screen and I can receive up to this resolution. Where with setReceiverConstraints you constantly announce on changes now I’m in stage view and want this stream in HD or I’m in tile view and I want all these streams in 180p, failing to send those the bridge will send you 180p by default.
Try it out on meet.jit.si, can you reproduce your problem there?
Yes, I recorded the experience on jitsi.meet and uploaded to youtube: Testing on Jitsi Meet - YouTube
Still choppy.
Till now we were discussing a resolution, not choppiness. Choppy is something else … I will ask @jallamsetty for help here …