Share Screen → Window

Issue generated from Tuleap's migration script. Originally submitted by: Óvári (ovari)

 1. Please enable window share screen.  

 2. The mouse does \*not\* shows when on the window has been shared.  

 3. The window selected shows even if there is another window that covers it.  

 4. This feature is useful if you only want to share the information in one window.  

    (a) If the window is resized only the resized windows is shared. This is useful as the window can be resized until the person viewing the window finds it the correct size.  

    (b) When the windows is closed, share screen automatically and gracefully closes.  

 5. This feature is in addition to the currently supported “Share screen area”.  

 6. This feature is in addition to the recommended other “Monitor share screen” mode.  

 7. If Ring implements a Menu Bar, the share screen could be located by:  
    (a) The menu: Call → Share Screens… → Window  
    (b) It will show, as thumbnails, all the windows that are open so that the correct one can be selected and shared  

 8. References:  

    (a) How do I share my screen in Skype?  
   https://support.skype.com/en/faq/FA10022/how-do-i-share-my-screen-in-skype  

 9. Please advise if you require any additional information.  

 10. Please advise when this feature has been implemented for testing purposes.  

Thank you

Submitted by Adrien Béraud (adrienberaud)

It's a feature request not a bug but keeping it open for reference.

changed title from [GNOME] Share Screen → Window to Share Screen → Window

mentioned in issue jami-client-qt#513 (closed)

Perhaps there could be an option to Show/Hide the mouse pointer when it is over the window and the window is in the foreground.

Please fix existing issues (especially video lag) before you implement new features:

jami-client-qt#403

jami-client-qt#375 (closed)

https://git.jami.net/savoirfairelinux/ring-client-android/-/issues/892

https://git.jami.net/savoirfairelinux/ring-client-android/-/issues/922

Perhaps video lag could be fixed with Desktop sharing frame rate jami-client-qt#514 (closed)?

Perhaps something like Kooha would be useful:

• Capture your screen without any hassle.
• Record your microphone, computer sounds, or both at the same time.
• Support for WebM, MP4, GIF, and MKV formats.
• Multiple sources selection.
• Optional hardware accelerated encoding
• Select a monitor or window to record.
• Create a selection to capture certain area from your screen.
• Set delay to prepare before you start recording.
• Hide or show mouse pointer.
• Choose a saving location for your recording.
• Utilize helpful keyboard shortcuts.

However, Kooha seems to be only available for GNU/Linux.

https://github.com/SeaDve/Kooha/issues/131

Thank you

assigned to @agsantos

changed milestone to %Jami for education

changed due date to November 09, 2021

added SprintIn progress label

mentioned in issue jami-client-qt#514 (closed)

Perhaps there are some code pointers which can help solve this issue at:

• Window capture stride is wrong
• https://hg.mozilla.org/integration/autoland/rev/ee898d5997e1

https://review.jami.net/q/topic:x11-windowsharing

@ovari , if you have GNU/Linux with x11 , you might be able to test those patches. They are wip yet, but should be minimally functional.

Thank you for your message.

In the Linux Mint 20.2 Cinnamon Terminal:

$ loginctl show-session c2 -p Type
Type=x11

If you prefer we test those patches, please advise the webpage with the steps on how to do so.

We might provide feedback on items which are are aware haven't been implemented yet and are planning to implement. Do you still want feedback?

The netbook has 10GB free space. Is that enough space or should we wait for the next automatic nightly download?

Sometimes we feel that we are not helping as it feels we are wasting your time with the silly questions we ask; however, happy to help anyway we can. If you feel that us testing these patches now is the way to go please advise and we will do the best we can to test.

Thank you

1. If the program with the shared window is exited, does Jami gracefully:
   a) turn off window sharing?
   b) update the state of the buttons in the Jami panel?
2. What does Jami do if the shared window is minimized? Does Jami send a 1px by 1px transparent tile So that Jami set with light or dark theme will show correctly? Does the image not freeze on viewer screens? Does the mouse pointer stop being sent?
3. If the shared window is minimized and then restored/maximized, does Jami show the restored/maximized window correctly?

Thank you

Hi @ovari !

1. Is crashing sometimes for the moment, but the current UI behavior, when it doesnt crash, is to keep showing the last successful frame.
2. Sharing flow continues and the shared window looks like freezed. The mouse pointer is send.
3. Yes.

1. Can it please turn off instead of showing the last successful frame? See #1294 (comment 32124)
2. Don't understand Share flow continues and the shared windows looks like. How does it send the mouse pointer if there is no area being sent?
3. Great.

1. It should turn off the screen sharing and go back to the previous state imho
2. It will just be black as there is nothing to show and the pointer is shown yes
3. it should yes

1. I will take a look on how to link this behavior;
2. We are probable able to check if the window state is minimized to set frames to black and remove cursor from drawing.

2. Perhaps if the window state is minimized, the avatar could be sent?

note for myself: https://specifications.freedesktop.org/wm-spec/latest/ar01s05.html#idm45623293999552

2. The avatar are, normally, a small image (32x32 for example), that would be poorly displayed in the UI.

Can a window in a different workspace be shared?

For Linux Mint: Ctrl + Alt + Up Arrow key
https://itsfoss.com/workspace-linux-mint-16/

Thank you

yes

Great, is this a solution for sharing a window with no mouse pointer?

1. It should turn off the screen sharing and go back to the previous state imho

Does the previous state just mean no screen sharing? Hope so.

Screen share a window of the first program, then screen share a window of the second program, then screen share a window of the third program, then exit second program, then exit the third program, what happens? Is the previous state screen share the window of the first program? Sounds too complicated.

When video split is implemented, perhaps it may be possible to have 2 screen share concurrently, or a screen share with a camera. What is the previous state?

Thank you

For now 1. is crashing, but 2/3 should be ok (I don't have any minimize button on my computer, will test on another later)

2. It will just be black as there is nothing to show and the pointer is shown yes

Should the mouse pointer not be shown as there is no area being shared?

I mean the pointer will be shown if the area is shown. If minimized, there is just black as nothing to show

4. If there window being shared is in the background and another window is above it, i.e. in the foreground, does the mouse pointer not show?
5. Is there an option to show/hide the mouse pointer?

4. If the window shared is in the background, the pointer still shows.
5. No

4. Is it possible to please not show the mouse pointer if the window share is not in the foreground? For example, a device with only 1 display can show and share the presentation window in the background with the Presenter Console in the foreground.

To always show the presenter console with only 1 monitor (i.e. with no external monitor): https://ask.libreoffice.org/t/is-it-possible-to-enter-the-presenter-console-in-impress-without-external-monitor/35828

imho, most of the users will like to have the cursor even if the shared window is not in the foreground. Speaking for myself, the mouse could be used as the "laser pointer" of the real world.

May I ask regarding this issue: jami-client-qt#514 (closed)

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.

Are issues like these already fixed? Video lag: jami-client-qt#375 (closed)

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

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.

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)

and pixelated video:

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

If not - Can you/the team please fix these issues too? It's great if you implement many new features but I would like to see this issues fixed first.

Hi @El4

We recently merged a few patches regarding the video performance that should improve your experience

Ok.. I will test ... May I ask will these patches be availabe in the "regular" version of Jami within the next update or do I need to test the BETA version?

Clicking on the Emojis don't show here in GitLab.

Are you able to reproduce?

Does a new issue need to be created?

Thank you

It's related to gitlab, but I never saw it, maybe a temp bug. And no, no ticket as it's not for Jami

They are showing now

@ovari Hello, long time no see, just some news:

In the next nightly for GNU/Linux, sharing windows will be possible in a v1.

Some notes:

• The mouse will show on the area for now, Aline is checking for screen sharing on Windows first
• For now, no signal is coming when the windows is closed while sharing, so it still shows the last valid frame. On Jitsi Meet, it's the same behavior.
• So, in case of closing, for now it's not going back in the previous state. However, I'm not sure it's wanted. Moreover, with multi-stream and video-split, in the future, there can be multiple windows shared, so going back to a previous state can be weird, so for now, I think we can stick with this behaviour to see what will be possible with multistream.

@sblin May I ask if the screen lag issues (using just Jami "screenshare" option AND "OBS-VirtualCam" using different fps and different networks) are done? And the pixelated video if you move fast?

Like @agsantos mentioned? If yes, when will it possible to try everything out?

I don,t have lag on my 5 devices in screen sharing, so never reproduced. So I don't know what will changes or not. And pixelated video is generally depends on lot of parameters (hardware acceleration or not, codecs used, cpu usage on your device for encoding). And I don't know any application not pixelating when moving fast.

But patches for video-performance are already there for GNU/Linux at least (I don't manage other platforms)

Thanks for your answer.

May I ask the following question: Regarding Windows 10 (newest version, no beta version) -> Android (newest beta version)

Are you able to reproduce for GNU/Linux and/or Windows 10 -> Android: jami-client-qt#403

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

So for the SAME network:

I just used my desktop pc as wifi hotspot so that my Android phone (Mate 20 Pro) and PC (Windows 10) are connected to the same WiFi network.

I played Splinter Cell Blacklist using "OBS-VirtualCam"; Jami select video device "OBS-VirtualCam".

Nearly no video lag. You can play the game from your phone screen.

So it's not important if you select a high or a low number of fps for OBS-VirtualCam. Maybe just this issue: jami-client-qt#478 (closed)

However: If both devices have different networks:

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.

Jami: If I use the option "share my screen" i have less than one second of video delay, sometimes I see a pixelated video (Device B, my phone screen).

AND (different networks) a higher framerate leads to more video lag:

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)

As mentioned I had THE SAME network settings/ setup and used Element (Windows 10) -> Element (Android) and selected OBS-VirtualCam too. (different network again)

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

No issues if you use Element (Windows 10 and Android tablet): same settings

So it's probably an issue regarding Jami. Who can fix this issue (Windows 10)? Can you reproduce? It would be very important for me.

this is completely out of the scope of this issue, but dumb question if it's in another network, you will probably use a TURN server (it's in the log what connection is used)

Where are you located geographically speaking? Cause the TURN in North America or in West Europa may be far from you, increasing delay. Also if you do not have ipv6 everywhere, it's more likely using a TURN

I am not sure if it's (just) because of the Turn server.

If I use /change (to) a "real" webcam (30fps, Jami Windows 10 -> Android) INSTEAD of "OBS-VirtualCam" or the screenshare option of Jami I don't get any noticable video lag. SAME Call

Just the sound issue mentioned: #1122 (closed)

Even if I use different networks. For me it seems related OBS-VirtualCam (especially higher fps) vs. Jami and maybe the integrated Screenshare option of Jami (not sure).

Because if it is just because of the Turn servers I would get a video delay too if I use a "real" webcam. I get a huge delay if OBS-VirtualCam has 60 fps (selected using OBS and Jami settings, different network, same network (WiFi Hotspot no issues)).

OBS-VirtualCam, 60 fps: And the video gets much pixelated.

As mentioned - no issues if I use Element (Link: https://element.io/ ,Windows 10 (same settings OBS-VirtualCam) -> Android) even if I change the frames to 81. The video is always less sharp than Jami. The fps for OBS-VirtualCam are 15,30,60,81 but I don't get any difference regarding the video stream or any video lag.

So: webcam Windows 10 -> Android: audio and video: no delay

BUT (Person A: Windows 10, Splinter Cell Blacklist, Person B: Android tablet)

For example if I shoot out the lights they turn black on the video call but (person B) hears the gun sound later.

I will keep testing.

as I said it also depends of CPU usage, codecs, gpu usage and bitrate.

Also in the logs it the bitrate is precised. In 4k 60 fps I have no pixelated video with a bitrate for the codec > 2000kbit/s

You can see lines like this:

[1638394453.493|41775|media_encoder.cpp :882  ] H264 encoder setup: crf=23, maxrate=2102 kbit/s, bufsize=1051 kbit

mentioned in commit jami-daemon@cc8fb024

mentioned in commit jami-libclient@2b3ad824

mentioned in commit jami-client-qt@f238b9d8

Thank you for enabling this feature in GNU/Linux!

Should this issue be closed now that the feature is available in GNU/Linux with jami-client-qt Version: 202112012137?

No there is still for Windows

Should a Share window option be added to the list in the panel?

It might make a better UX.

There would be 4 options then in the image above, i.e.:

• Share screen
• Share screen area
• Share window
• Share file

What do you think?

Thank you

it's there now :)

@sblin Even for Windows 10? Or just Linux?

Oh right there is no window screen sharing for windows, nvm

mentioned in issue jami-client-qt#612 (closed)

mentioned in commit jami-daemon@1bb4739f

mentioned in issue jami-client-qt#668 (closed)

removed SprintIn progress label

closed

reopened

added SprintIn progress label

removed due date

added to epic &48 (closed)

added 1 deleted label

changed epic to &50 (closed)

assigned to @sblin

assigned to @atraczyk

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

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

added SprintTo review label and removed SprintIn progress label

I just checked and I was still able to reproduce this issue (using the "real" share screen option of Jami - no VirtualCam used): jami-client-qt#481 (closed)

Any chance that you can check this issue too? (I think there are free demos so it should be possible to reproduce)

mentioned in commit jami-daemon@9d76cf5c

mentioned in commit jami-client-qt@a28d5c5c

added SprintDone label and removed SprintTo review label

removed SprintDone label