Desktop sharing frame rate

Jitsi Meet → … (More actions) → Settings → More → Desktop sharing frame rate

There is a drop-down with options:

• 5 frames per second
• 15 frames per second
• 30 frames per second

Desktop sharing frame rate could be called Screen sharing frame rate?

Can this feature be available as it could help with:

1. reducing data consumption
2. reducing video lag #403 #375 (closed) https://git.jami.net/savoirfairelinux/ring-client-android/-/issues/892 https://git.jami.net/savoirfairelinux/ring-client-android/-/issues/922

What do you think?

Thank you

changed the description

The frame rate is now 30 fps. See: https://git.jami.net/savoirfairelinux/ring-project/-/issues/1262

But before the Jami developers implement new features I think it would be better to fix existing issues.

See #403 :

Even if OBS-VirtualCam is set to 30 fps you have a noticeable delay (latency). No issues if you use Element (Windows 10 and Android tablet): same settings

So just changing the frame rate won't fix these issues.

Thank you @El4 for your contribution; however, people with lower-powered devices, including ourselves, 30 fps (frames per second) may not be possible (or produce a bad outcome because of the device).

Having the option of 5 fps could be sufficient when sharing a LibreOffice Impress presentation or the input from a document camera.

Having an option to reduce the fps may also help in the gathering of information to track down the cause of the latency you mention.

Thank you once again.

assigned to @atraczyk

changed the description

In addition to the 5, 15 and 30 frames per second, perhaps there could be a user-specified frames rate? This could be used initially for debugging.

By increasing the frame rate, developers could find where the bottleneck(s) in the Jami code is/are or whether it is external to the Jami program (i.e. Internet connection, computer speed/specifications, etc.).

The optional frame rate could also be used for gamers or people using Jami over a high speed LAN/gigabit network.

Thank you

assigned to @agsantos

changed milestone to %Jami for education

added ~279 SprintIn progress ~266 labels

https://review.jami.net/c/jami-client-qt/+/19599

https://review.jami.net/c/jami-daemon/+/19600

added SprintTo review label and removed SprintIn progress label

1. Is the auto string viewable to the user? If so, is it translatable?
2. Is there an option to for a user specified setting/stress testing?

Thank you

1. No it is not viewable, we only show the frame rates.

2. No. Only the fixed rates [5-30] step 5;

changed due date to November 09, 2021

Hi @ovari

Just some news. I said that I wanted to generate a nightly today with the features you asked. Actually, I saw some bugs for syncing and I prefer to finish my patches before generating a new one. So, is it okay if I delay a bit the nightly to test. This is basically a summary:

• Desktop sharing framerate

Client is ready, daemon is in review: https://review.jami.net/c/jami-daemon/+/19600 so not merged

• hands-up

It's actually testable in latest nightly for GNU/Linux, available for video-conferences (jami-project#855 (closed))

• Screen sharing in audio-only calls

It's actually testable in current nightly. However, it will be improved in next one to not open the camera automatically (https://review.jami.net/c/jami-client-qt/+/19693)

• Window's screen sharing:

Aline is working on it, it's more complicated. I will Aline explain this point, so probably not in next nightly

What I want in next nightly:

• I want to merge my patches adding the read status in the chatview for client-qt
• I need to fix some swarm issues about syncing after importing from backup (https://review.jami.net/c/jami-libclient/+/19695), and detecting missing conversations (patch incoming)
• And this https://review.jami.net/c/jami-client-qt/+/19689

If you prefer to not wait to test, I can generate an internal version, else I hope to be able to generate the nightly before the week end

@sblin

Window's screen sharing:

It's great if there are new features coming but can you / the team please fix the video lag issues first? #403

especially:

same WiFi network. [..] Nearly no video lag.

BUT

If I use "OBS-VirtualCam" (60 fps, video device) and different networks I have at least 2-3 seconds video delay. I often see a pixelated video.

AND

If OBS-VirtualCam has 80 fps there are many seconds of video delay. Nearly only one second (or less) video delay if the framerate of OBS-VirtualCam is set to 30 fps. However - if the framerate is set to 20 fps or less there is no improvement anymore. You have to restart Jami again if the framerate is changed so that it will show up (Jami: Audio and Video Settings)

It's probably an issue regarding Jami (Android device and windows 10 device: different network):

Element: Even if you set the framerate of OBS-VirtualCam to 81 fps there is no video delay.

And the video of the integrated Screenshare function of Jami (no virtual cam) also sometimes lags: #375 (closed)

Sometimes the video (Person B that can view my screen from a tablet) is stuck for a few seconds (video game) but then everything works again.

It's great if there are new features regarding screensharing but it would be very useful if all these bugs were fixed. Together with jami-project#1122 (closed) and #390

Any (fast) movement leads to a pixelated video. Even if you have a good Internet connection.

Hi @El4

Probably you will be interested in knowing that we are beginning a great work in the window/screen sharing pipeline.

Regarding the windows sharing, some of the problems we experienced so far: black frames while sharing chrome or Visual Studio Code, resolution change is not followed by ffmepg library, jami may freeze in Windows while sharing, and more.

For the long list of bugs and after spending few days debugging and trying some possible fixes, It is our conclusion that ffmpeg does not support window sharing properly. Thus, it was decided that we need to rework the screen/window sharing for both GNU/Linux and Windows. This work, however, will take longer than a month to be functional.

It is likely that those changes may reduce or fix the bugs you related so we ask you to follow our updates in jami-project#1294 (closed) and the related tickets that will be added to that issue.

Thanks for your reply.

I thought it is also a connectivity issue because if I am using the same Wifi with different devices I don't have any (longer) video lag (using OBS VirtualCam with various fps).

So can you test OBS VirtualCam (same network/ different network, low internet speed etc.) if you are using Jami?

regarding ffmpeg: Is it also responsible for this audio issue? jami-project#1122 (closed)

Because @sblin wrote:

pretty sure this is caused by ffmpeg not up-to-date

Windows is a bit old and doesn't get last ffmpeg bump

However- using another audio codec didn't help.

Just wanted to mention some black screen issues: #453 (moved) #478 (closed) #536 (closed)

Can you check them too?

In https://review.jami.net/c/jami-daemon/+/19600 there is a comment https://review.jami.net/c/jami-daemon/+/19600/7..10/src/media/video/v4l2/video_device_impl.cpp#b552 about not allowing 60 and 120 frame rates.

https://rog.asus.com/articles/guides-gaming/how-to-set-up-your-monitor-and-pc-for-high-refresh-gaming/

Should 60 and 120 be allowed? And even 144?

Thank you

Sorry, just noticed 144 at https://review.jami.net/c/jami-daemon/+/19600.

@ovari the feature is merged, it will be available on next nightly (I will do one later today).

Thank you

mentioned in commit cfd5617c

added SprintDone label and removed SprintTo review label

closed

removed SprintDone label

mentioned in issue jami-project#1294 (closed)

mentioned in issue #614