Video quality deteriorated

Install & Config
,
#1

Hi @damencho,

since we switched from jitsi-meet version 2.0.4548-1 to 2.0.5142 we have been experiencing video resolution issues.

In the previous version we had imposed constraints max 640 and min 360 which made us find the right compromise between performance and quality.

This setting seems to be no longer respected on the new version because it blocks us all at 320x180.

We realized that we only get a change when we set 1280x720, the quality goes up but so does the bandwidth waste.

What does this change depend on?

Is it related to the JVB version? We have kept version 2.1-197-g38256192-1, although the stable version is now 2.1-376-g9f12bfe2-1.
Can it lead to problems like the anomaly I mentioned above?

Otherwise what other cause causes me to freeze the resolution at 320x180 as is happening now?

Thanks for the sure answer and good evening
Marco

#2

It can be.

This is question to @jallamsetty can you help with that, thanks.

1 Like
#3

Hi @jallamsetty can you help me ?

#4

Sure, can you please give me more details about the call setup ?
Can you please clarify about your constraints ? When you say max 640 and min 360, are you talking about the height setting in video constraints ? Do you have simulcast and layerSuspension enabled in your config.js ? Will you be able to post your browser console log with filter “SenderVideoConstraint” so that I can see what the client is sending ?

2 Likes
#5

Hi @jallamsetty,
thanks for replying to my message!
I’m referring to height constraints. We have the simulcast enabled and also the layerSuspension. Below is the console you asked me:

2020-12-20T11:24:47.041Z [modules/xmpp/JingleSessionPC.js] <w.setSenderVideoConstraint>: JingleSessionPC[p2p=false,initiator=false,sid=7tupj9i091992] setSenderVideoConstraint: 2160
Logger.js:154 2020-12-20T11:24:47.044Z [modules/RTC/TraceablePeerConnection.js] <A.setSenderVideoConstraint>: TPC[1,p2p:false] senderVideoMaxHeight: 2160
Logger.js:154 2020-12-20T11:24:47.049Z [modules/RTC/TraceablePeerConnection.js] <A.setSenderVideoConstraint>: TPC[1,p2p:false] setting max height of 2160, encodings: [{“active”:true,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:4},{“active”:true,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:2},{“active”:true,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:1}]

#6

Here is mine. I get videos with 160x120 size when using the latest version.

JingleSessionPC[p2p=false,initiator=false,sid=6brab9duoslb4] setReceiverVideoConstraint - max frame height: 720
instrument.js?ea14:109 2020-12-22T03:40:01.938Z [modules/RTC/BridgeChannel.js] <l.sendReceiverVideoConstraintMessage>: Sending ReceiverVideoConstraint with maxFrameHeight=720px
3instrument.js?ea14:109 2020-12-22T03:40:01.939Z [modules/RTC/TraceablePeerConnection.js] <A.setSenderVideoDegradationPreference>: Setting video sender degradation preference on TPC[1,p2p:false] to maintain-framerate
instrument.js?ea14:109 2020-12-22T03:40:01.940Z [modules/xmpp/JingleSessionPC.js] <w.setSenderVideoConstraint>: JingleSessionPC[p2p=false,initiator=false,sid=6brab9duoslb4] setSenderVideoConstraint: 720
instrument.js?ea14:109 2020-12-22T03:40:01.940Z [modules/RTC/TraceablePeerConnection.js] <A.setSenderVideoConstraint>: TPC[1,p2p:false] senderVideoMaxHeight: 720
instrument.js?ea14:109 2020-12-22T03:40:01.940Z [modules/RTC/TraceablePeerConnection.js] <A.setSenderVideoConstraint>: TPC[1,p2p:false] setting max height of 720, encodings: [{“active”:true,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:4},{“active”:true,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:2},{“active”:true,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:1}]
instrument.js?ea14:109 2020-12-22T03:40:01.941Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onmessage>: SenderVideoConstraints: {“idealHeight”:180,“preferredFps”:-1,“preferredHeight”:-1}
instrument.js?ea14:109 2020-12-22T03:40:01.941Z [modules/RTC/RTC.js] <A._senderVideoConstraintsChanged>: Remote max frame height received on bridge channel: {“idealHeight”:180,“preferredFps”:-1,“preferredHeight”:-1}
instrument.js?ea14:109 2020-12-22T03:40:01.941Z [modules/xmpp/JingleSessionPC.js] <w.setSenderVideoConstraint>: JingleSessionPC[p2p=false,initiator=false,sid=6brab9duoslb4] setSenderVideoConstraint: 180
instrument.js?ea14:109 2020-12-22T03:40:01.941Z [modules/RTC/TraceablePeerConnection.js] <A.setSenderVideoConstraint>: TPC[1,p2p:false] senderVideoMaxHeight: 180
instrument.js?ea14:109 2020-12-22T03:40:01.942Z [modules/RTC/TraceablePeerConnection.js] <A.setSenderVideoConstraint>: TPC[1,p2p:false] setting max height of 180, encodings: [{“active”:true,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:4},{“active”:false,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:2},{“active”:false,“networkPriority”:“low”,“priority”:“low”,“scaleResolutionDownBy”:1}]
instrument.js?ea14:109 2020-12-22T03:40:01.976Z [modules/xmpp/SDPUtil.js] <Object.candidateToJingle>: not translating “ufrag” = “TTdD”
instrument.js?ea14:109 2020-12-22T03:40:01.976Z [modules/xmpp/SDPUtil.js] <Object.candidateToJingle>: not translating “network-id” = “1”
instrument.js?ea14:109 2020-12-22T03:40:01.978Z [modules/xmpp/SDPUtil.js] <Object.candidateToJingle>: not translating “ufrag” = “TTdD”

#7

Hi @jallamsetty can you answer me, please ? :wink:

#8

@Marco_Scammacca, I got back today after the winter break, sorry about the delay. It is not clear from your logs why low resolution is being received on the other end since the encoding client is sending all 3 layers. It is the bridge that decided to send the lower resolution layer to the receiving client based on the b/w available and the resolution requested. I would need the receive side logs with filter ‘ReceiverVideoConstraint’ to understand what is being requested by the client.

@AymericG, it appears that the receiving client is requesting 180p and therefore the encoding client pick the 160x120 resolution to send since it is the resolution of the lowest simulcast stream. 6400x480 capture produces 3 simulcast streams of resolutions 640x480, 320x240 and 160x120 and 160x120 stream is the only one that satisfies the receiver constraint. If you want to increase the resolution requested per tile, please follow the instructions in this post - Poor Video Quality Latest Jitsi Update (5142-1) - #2 by jallamsetty

#9

Hi! Don’t worry, holidays are sacred!
Thanks for the answer, I’ll bring you what I found looking for “ReceiverVideoConstraint”:

2021-01-05T09:54:24.876Z [modules/xmpp/JingleSessionPC.js] <w.setReceiverVideoConstraint>:  JingleSessionPC[p2p=false,initiator=false,sid=b9hjehvash7ab] setReceiverVideoConstraint - max frame height: 2160
Logger.js:154 2021-01-05T09:54:24.876Z [modules/RTC/BridgeChannel.js] <l.sendReceiverVideoConstraintMessage>:  Sending ReceiverVideoConstraint with maxFrameHeight=2160px
#10

Looks like the bridge decided to drop down to the lowest resolution stream even though the receiving client is requesting 4k and the sending client is sending all the 3 simulcast streams to the bridge. Do you know if the receiving client has enough downlink ? What do the connection stats on the receiving client look like ?

#11

Hi, we have updated JVB jicofo but the poor quality issues remain. You released a version in October with 4K with this anomaly. is it there? how can we solve?

ps. we have also modified the conf file where the constraints are changed but without any effect