Sharing part of the screen

[mkaminski100]

Several users in our organisation use wide screens (42-49") which when shared in Teams as one screen are illegible for others. Even when sharing between two users, video is very pixelated and difficult to read. 

We tried using window sharing which works fine, but there is a need to often switch between several windows, which is creating multiple issues, especially when information from one window is referenced in another. 

I was unable to find a function enabling us to share just a portion of the main screen as we use in PowerTools. 

Am I missing something here or would this require a request for a new feature?

[#2]

You need to jump over to request a new feature. The only options are windows (apps) or the whole of the desktop(s).

[#3 · Accepted solution]

Seem to be not possible at the moment, but heavily requested by user voices: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/38834104-share-custom-area-of-...

[#4]

Is partial screen sharing option available now?

[#5]

@sivakumar3rgmailcom 

No, I don't think so. See my link above. User voices is still open / untreated. But you may encourage friends and colleagues to vote there in order to increase the weight of user's voices

[#6]

@mkaminski100 

While this is still not implemented (after more than 2 years ffs) I recommend you using OBS as a virtual web-cam, so you can select the part of the screen that should be streamed and just switch the "webcam" used in Teams.

[#7]

@mkaminski100 

I have created a little work around for me, by letting VLC capture a part of my screen. This captured video is played back in a borderless VLC window which I use to share via Teams (or similar tools).

I put all things together as an powershell script which I installed into my powershell profile so I can easily start (partial) sharing from a powershell by typing 

Share-PartialScreen

The script does the following:

function Share-PartialScreen {
    [CmdletBinding(DefaultParameterSetName='Preset')]
    Param(
        [Parameter(Mandatory = $false)]
        [string] $preset,
        [Parameter(Mandatory = $false)]
        [int] $Width = 1920,
        [Parameter(Mandatory = $false)]
        [int] $Height = 1080
    )

    switch ($preset) {
        "720p" { 
            $Width = 1280
            $Height = 720
        }
        "1080p" { 
            $Width = 1920
            $Height = 1080
        }
    }

    $id = Start-Process -FilePath "C:\Program Files\VideoLAN\VLC\vlc.exe" -ArgumentList "screen:// --screen-fps=30 --live-caching=300 --screen-width=$Width --screen-height=$Height --no-embedded-video --no-video-deco --qt-start-minimized" -PassThru

    [reflection.assembly]::LoadWithPartialName( "System.Windows.Forms")
    [reflection.assembly]::LoadWithPartialName( "System.Drawing")

    $pen = New-Object Drawing.Pen red
    $brushRed = New-Object Drawing.SolidBrush red
    $brushWhite = New-Object Drawing.SolidBrush white
    $font = New-Object Drawing.Font "Arial", 14

    $form = New-Object Windows.Forms.Form
    $form.TransparencyKey = $form.BackColor
    $form.WindowState = 'Maximized'
    $form.FormBorderStyle = 'None'
    $form.TopMost = $true

    $formGraphics = $form.createGraphics()

    $form.add_paint(
        {
            $formGraphics.DrawRectangle($pen, 0, 0, $Width + 1, $Height + 1)
            $formGraphics.FillRectangle($brushRed, $Width + 1, 0, 60, 30)
            $formGraphics.DrawString("close", $font, $brushWhite, $Width + 5, 3)
        }
    )

    $form.Add_Click({$form.Close()})
    $form.ShowDialog()   # display the dialog

    Stop-Process $id
}

Be warned that this leads to flickering sometimes, in the recorded area, as you constantly record the area again, but this disappears if you place a window over this area. 

Of course VLC is necessary for this, but additionally I can recommend the tool Sizer that allows to set a windows to a specific size easily, so you don't need to fiddle a long time till a window matches the shared area.

I hope some of you enjoy this work around :smiling_face_with_smiling_eyes:

Fell free to follow the gist on github in case I extend this script.

[#8]

Meanwhile I have created a workaround as well. The app opens two windows, one to allow selecting the area to record, and the other to be shared over Teams. Feel free to use the executable on the releases page or checkout the code on github.

[#9]

@PyKen Brilliant mate... I was looking for something exactly like this!! 

I have a humble request to make this even easier to use. Could you look into:

- Creating the selection rectangle at a desired location, width and height?

    (command line parameters: sel_x, sel_y, sel_w, sel_h)

- A command line parameter to control whether the selection rectangle is visible or not? If I dedicate the right half of my ultrawide to sharing via Teams and the program starts up with fixed parameters (sel_x, sel_y, sel_w, sel_h), the selection border need not be visible.

- Moving the Main Window to a desired location (i.e. out of the way)?

    (command line parameters: main_x, main_y)

I assume the Main Window must be visible (not hidden) for sharing purposes, otherwise a 'hide main window' parameter could also make sense. Minimizing it doesn't work, because Microsoft Teams will stop sharing any minimized window. So being able to move the Main Window to a location where it's less distracting would be fantastic. Many thanks in advance!

[#10]

@ProMace Thanks for the suggestions!:) I have added these features. After running the setup, you can run it (in case of the desktop link) like this

.\screen-area-share.lnk --cx=0 --cy=0 --cw=1920 --ch=1080 --rx=1920 --ry=0 --rw=1920 --rh=1080 --freeze

AFAIK hiding the main window is not possible. I have tried minimizing it as well. Moving the main window to another workspace does not help either. Currently, the only solution is to simply put another window above it.

[#11]

Hi PyKen, thanks again for your effort, much appreciated! :) I'll be testing your updated version over the next few hours.

This morning I tested Teams sharing with my work colleagues and it didn't work as expected, they couldn't see the contents of the Main Window. I set up a Teams call this evening from work to my home account and I found that moving the Main Window 'out of the way' (= outside of the visible desktop) doesn't work. In summary, I found the following on the receiver side of Teams sharing:
1. Nothing is shared if the Main Window is fully covered by another window.
2. The Main Window is fully shared if it is partially covered by another window.
3. If the Main Window is partially pushed outside of the desktop area, only the visible part of the Main Window is shared, zoomed.
4. If the Main Window is minimized, nothing is shown (normal Teams behavior).
5. If the Main Window is hidden, it turns black, as does the shared content (I used WinSpy to get the handle and AutoHotkey to hide the window).

If 3 were not the case, you could just push the Main Window to a place outside of the visible desktop. Is there a way to fully render the Main Window even when it's outside of the visible desktop? Because that would be a perfect! As it stands, when sharing half of my ultrawide screen the other half will be occupied by the Main Window, whereas you'd want to use that space to prepare whatever you're going to drag into the shared rectangle. If you manage to solve that issue, you can start asking $$$ for your solution! :)

[#12]

@ProMaceThanks for your extensive tests! I have released a small fix for 1.

1 and 2. Thanks, I fixed this in v1.1.1. The window should continue rendering now, even if it is completely covered by other windows.

3. Unfortunately, this is a Teams limitation. A capture in OBS has no problems with it. As a workaround, I made sure the Main Window always stays within the screen.

4. Yes, it seems that Teams stops recording when the window is minimized. I am not sure if it is possible to render while minimized.

5. What do you mean with 'hidden'? Is there another way to cover a window?

If 1 is not a solution for you, you can actually use virtual desktops. A bit complicated to start, but you can move the Main window to another virtual desktop after selecting it for screen sharing!

[#13]

@PyKen You, my friend, are an asset to humanity... Your fix works just fine for me! So no need for virtual desktops. 

After some further testing, I found a few small remaining issues:

1. When using DPI settings > 100% (I use 125%), the effective screen pixel coordinates of the 2 windows will be off by DPI / 100. So for instance, if DPI = 125 then (2560, 0) effectively becomes (3200, 0). I can compensate for this through the coordinates passed to the app, in the example I can multiply by 100/125 which yields (2048, 0). It would be cool if you could implement a parameter --dpi and then perform the correction (100 * coordinate) / --dpi internally within the app!

2. It appears that the Main Window has a positive offset on the passed (x, y) coordinate. It looks like it's being positioned at (x + N, y + N). In my use case this causes a slight overlap with the capturing rectangle as I'm positioning the Main Window at (0, 0) and the Capture Window at (2560, 0). Moving the Main Window to the left and top, outside of the desktop area, causes it to snap (as per your fix) into the (0, 0) position which is where I expect it to be.

Regarding your question about hiding a window: AutoHotkey has a function WinHide that makes the window invisible. I assume Windows simply stops rendering the window, which is why it can't be used in our screen sharing scenario. I think AutoHotkey is calling a low-level Windows API to make a window invisible. See https://www.autohotkey.com/boards/viewtopic.php?style=17&t=63297

If you could look into these small issues, that would be great! I've already had my X-mas present for sure!

Best regards,

ProMace

[#14]

@ProMace  Glad to hear it works well on your end as well:D And thanks for pointing out further issues:)

1. I made v1.2.0 to ignore scaling by default as it causes recorded images to blur (i.e. you do not need to calculate beforehand). The old behavior can be enabled with --consider-scale

2. Hmm I cannot confirm this, in my case, the rendering window spawns at exactly (0,0). Could it be the case that you are running some other applications related to window placement?

Interesting feature by AutoHotkey there... might look into it if the current workaround does not work one day^^

[#15]

@PyKen Thanks again mate!  I'll be testing this after work. I'll pay special attention to the Main Window positioning and whether it's something on my side that's interfering.

Regardless, what I can say upfront is that countless people have been stalking Microsoft for region-based sharing in Teams, and you've managed to come up with a straightforward solution! 

Edit: Before I forget: is there a reason to have width and height parameters for the Main Window? Is this not equal to the capture region size, in other words can they be omitted?

[#16]

@PyKen Okay, so I tested further and this is getting really interesting... I figured out the following:

1. The new default behavior (ignore scaling) actually gives me the pixel-perfect result I was looking for! Much better than the previous version where the mirrored image was a little blurred.

2. The app wasn't responding to my command line parameters for the Main Window coordinates at all. No matter what I entered, it would show up at the same location.

3. I then found that running the program as an administrator made it behave as expected with regard to the Main Window coordinates. However...

4. ... running the program as an administrator introduces a new issue, which is that any window dragged over the Main Window will show up as a gray rectangle on the rendered image on the receiver side, at the respective location! 

So it has to be a (company) policy-related issue that's forcing me to run as admin, but the 'ghost window' effect when doing so doesn't make sense to me... I've been testing work --> home sharing so far, I'll also look into home --> work as my private laptop will naturally have fewer restrictive policies enabled. In the meantime, could you check what happens on your side when explicitly running the app as admin? Furthermore, any idea why positioning the capture window works fine while positioning the render window does not, when not running as admin?

As always, thanks in advance! 

[#17]

Hi @PyKen, I did a few tests sharing from home --> work and these are the results:

Not running as administrator

• Positioning of the Main Window works fine. This helps confirm that Windows policies are interfering one way or another on my company laptop.
• Sharing works fine.

Running as administrator

• Positioning of the Main Window works fine.
• Sharing exhibits the same gray 'ghost window' effect. So this issue appears to be of a more general nature. Can you reproduce this?

Very curious to find out why 'run as admin' is causing an issue!

Best regards,

ProMace

[#18]

@ProMaceVery interesting. In my case, I do not have those limitations, so I can run it as non-admin without any problems. I can, however, confirm the gray 'ghost window' effect when I run it as admin and share the main window over Teams. Capturing the main window in OBS shows no 'ghost window' effect, so I assume this is, again, a Teams specific capturing logic and there is probably no way around it :|

I wonder which policy on your work environment is hindering the main window to be positioned when running as non-admin... But as long as it is the main window, I guess it is not a critical thing:)

> is there a reason to have width and height parameters for the Main Window?

You are right, no, there is no reason For now, you can safely ignore those parameters. Maybe in future, it could be used to define some scaling between the captured and rendering content.

[#19]

Simple post to thank you for this tool, was looking for one before I write one, you did it and it works great. Will open issues in your GitHub if I find some. Do you have a tip jar ?

[#20]

@ACGendronThanks for your kind words!:)

> Do you have a tip jar ?

For now, I have the 'Sponsor' button on the github site