Hi Shahid, thank you for offering the URL.
Is this a Jitsi server instance? I am unable to access the config.js (https://trigonetech.com/config.js?) file to see if it is set to 1080p, and my jitsi client are unable to join room when entering https://trigonetech.com/ as server.
yes it self hosted Jitsi server instance for experimental purpose and set it on 1080p for you. currently i have disabled smart phone access on it.
sorry try the url
That is weird. Even though the constraints say up to 1080, I have two devices that are maxing at 720
I wonder why the Jitsi is always defaulting to 720 when there is always bandwidth, processor power, and camera resolutions available.
It sucks because I am trying to do remote tech support with 720
I wonder why the cameras are not selecting 1080.
org.webrtc.Logging: Camera2Session: Available preview sizes: [ 1920x1080 , 1280x720, 864x480, 800x480, 720x480, 768x432, 640x480, 672x380, 576x432, 480x320, 384x288, 352x288, 320x240, 240x160, 176x144]
org.webrt.Logging: Camera2Session: Available fps ranges: [[ 15.0:15.0 ], [24.0:24.0], [30.0:30.0], [ 7.0:100.0 ]]
My device always selects the 720p and fixed 15FPS.
I wish I could force it to select the 7-100FPS and select the 1080p :(!!
I wonder what constraint must be modified before camera2session selects 1080. Does anyone have experience with that?
If you are testing on this deployment it has wrong config:
ideal: 720, max: 10800, min: 240
It should be:
ideal: 1080, max: 1080, min: 240
resolution: 1080, is for chrome prior version 61.
Oh - Good find Damencho!
I really need to set up my home server space and fire up an ubuntu instance do it myself but I am moving between houses
Mr. Mehmood, would you perhaps be able to help revise config file if you are in control of instance?
Thank you both for help.
you can check now
I see the config is correct now.
My devices fluctuate between lower resolutions but unfortunately never to 1080
I wonder what is the bottleneck
Yeah, I’m not sure. What is the bandwidth estimation you see in your local connection info, when expanded?
This is with chrome, firefox shows N/A for download and upload.
Does the estimated bandwidth determine which video stream is selected by the client?
Perhaps the estimated bandwidth is inaccurate – I could start up an iperf session and get way faster speeds.
This is strange, so in p2p mode there is no jvb on the way it is just the two browsers talking to each other directly and the browser is detecting the bandwidth. Hey @gpolitis am I right, in p2p mode the estimated bandwidth stat is coming from the browser directly … ?
Have you tried just opening two tabs in the same browser, how does it bahave then?
You’re absolutely right, @damencho, in p2p mode there is no jvb on the way; it is just the two browsers talking to each other directly and the estimated bandwidth stat is coming from the browser directly.
The N/A appears both in p2p and in jvb mode and it’s because we have send-side bandwidth estimations in our deployments, which means that the endpoints do not compute how much receive (download) bandwidth they have; they only compute how much send (upload) bandwidth they have.
We’ve talked in the past about hiding the download estimated bandwidth label when send-side bwe are enabled but it fell off the radar.
I hope that my upload capacity can handle more than 300 Kbps because my speedtests say 163,290 Kbps .
Does this mean that there is a 300 Kbps bottleneck somewhere between me and the destination on the same WiFi (?)
It is weird… P2P on the exact same WiFi router with at least 833Mbps WiFi throughput between devices.
Perhaps the bandwidth estimation is incorrect? Would there be a way to force or fix this error?
Is there a way to turn off bandwidth estimation in the config.js file?
I assume this is why I am unable to increase resolution to 1080p even though there is bandwidth, FPS, processing power, and camera resolution available.
I found these
// Disables or enables TCC (the default is in Jicofo and set to true) // (draft-holmer-rmcat-transport-wide-cc-extensions-01). This setting // affects congestion control, it practically enables send-side bandwidth // estimations. // enableTcc: true, // Disables or enables REMB (the default is in Jicofo and set to false) // (draft-alvestrand-rmcat-remb-03). This setting affects congestion // control, it practically enables recv-side bandwidth estimations. When // both TCC and REMB are enabled, TCC takes precedence. When both are // disabled, then bandwidth estimations are disabled. // enableRemb: false,
Would that work if both of these are disabled?
Thank you for your time!
I was simply explaining why you see N/A in the estimated download bandwidth (it’s a non-issue); I don’t think the issue is related to the bandwidth estimation because there’s “plenty” of bandwidth to send at least 180p with a 300kbps estimate.
It looks like your endpoint has completely suspended video; I can’t say for sure but it could be the
googEnableVideoSuspendBelowMinBitrate flag misbehaving (we have this enabled for the p2p peer connection).
It’s been a while since I tested 1080p, maybe we broke something in the way we acquire the 1080p media stream?
As for disabling bandwidth estimations… Maybe, if you remove all the header extensions and rtcp messages from the SDP. Even then it’s a long shot, bw estimations are deeply rooted in webrtc.
Sorry for my ignorance – Is there an ideal scenario where 1080p would work smooth? How could I set this up?
What are ideal conditions needed that might get 1080p working?
If disabling bandwidth estimation does not increase the main video stream resolution, what variable is actually most important? Would setting the following work:?
ideal: 1080, max: 1080, min: 1080
On mobile we default to 720p 30fps, settings are currently ignored. I don’t know why it’s locked at 15fps though.
I can definitely understand locking mobile for cell phones in the past because of processor and bandwidth restrictions. Now we are testing out 5G with low latency cellular, with high-powered multicore cell phones, that the mobile implementation could handle greater than 720p.
There are smart-glasses with 1080p and even 14MP full 4K 60FPS cameras (ThirdEye X2) that would love to make use of Jitsi video bridge as a video conferencing solution, but are unfortunately limited to 720p
This limitation will hopefully be lifted soon. It wasn’t intentional, but a shortcut since we need to translate WebRTC constraints in JS to native calls in react-native-webrtc.