Cannot present/share desktop about teams-for-linux HOT 46 CLOSED

By the way, the "working on it" could mean finish next month, in 2 years... is fairly Agile but they should probably have a couple of more states to show progression.

from teams-for-linux.

Pre-release in here:

https://github.com/IsmaelMartinez/teams-for-linux/releases/tag/v0.1.16

I will close this issue, we can create new ones for each case... I have lost track of what is fixed and what is not!!

from teams-for-linux.

Just got it working, I'll be pushing it to the 0.1.16 branch in 10min

from teams-for-linux.

Merged in 0.1.16.

Regarding the issues, here my answers:

1. • ScreenShare button takes a couple of seconds to be visible. This is because we need to wait the minimum of a second to apply all the angular.element(document).injector() craziness.
2. • I have improve the thumbnail resolution. That page layout is, indeed, pretty poor. I have made small tweaks but it can benefit from a bit of TLC.
3. • I didn't find my streaming slow but I am only doing local tests... so might need to grab someone else from work for a few tests tomorrow.
     4.- Indeed, there is no notification/hint that screen sharing is currently enabled/active. We might be able to emit an event for this... the problem is to find what event is the one we need to emit!

I also found that, when you record a video, you need to ctrl+click to be able to download the link. (one of those hacks)

Anyone is more than welcome to improve on those points, but, to be honest, is pretty decent stuff.

I might do a bit of refactoring around it (nothing mayor, just naming convention is different of the rest), and there are a few/many things in the browser folder... and it might benefit from reorganising it a bit more... but that might need to wait for 0.1.17.

If tomorrow I can tests this at work, and it works fine, I am happy to release 0.1.16. I will appreciate if you people can do some testing on this if at all possible! (and/or improve it!)

Thanks to (in no particular order) @syepes, @BlueCase, @byteSamurai @cameronrmorris, @mpruefer and @tomicdusan.

from teams-for-linux.

@maximbaz , could you pull the latest and see if you get it again?

I have seen this happening when the app opens in a one-to-one chat. I have increase the timeout back to 3 seconds (instead of one) but I might need to revert it to its original 5 seconds.

I have added a wee improvement on the layout (names on it and two per row). That should tackle improvement number 3 (or at least, part of it)

Regarding the quality, I have seen it and looks like it depends on the screen that you are sharing (resolution). I haven't played enough with WebRTC but I will see if I can have a look at that one also at some point this week.

With regards the "select presentation only", I can confirm is annoying as you don't get a feedback neither of if the use has accepted the share or not... until a wee while but only if they accept.

from teams-for-linux.

As Microsoft is working on this feature at the moment (desktop sharing via web), we should keep this ticket open/pending. I will actively help get this done in teams-for-linux, cause I need it very much.

from teams-for-linux.

@byteSamurai and @maximbaz . I will wait until there are more stars here than in the ivelkov... if we ever do.

Regarding the timeout, the index.js file in the browser folder has a timeout before it applies all the angular inject changes. It use to be 5000 (5 seconds) but I did bring it down to 1second and now to 3.

I have added a parameter in the main index.js app to enable the h.264 codec (that I think should be enabled by default). could you guys check it that makes any difference to the video quality? I had mainly good quality images, a part from the odd one here and there.

Happy to release tomorrow and open issues for each of the other issues. Still better than no video :)

from teams-for-linux.

Tried a few things but can only add sharing ppt;s into a presentation... not ideal but better than nothing.

That will be part of #21 (the code is already there so feel free to yarn start to test it). I will keep this open to see if we get more alternatives to solve this issue.

from teams-for-linux.

0.1.16 should have the screen share button in it. Otherwise we can just tweak it to think is the desktop.

We can have a look at the other issues once your code is in.

Not sure if @syepes got any changes, but do add them to 0.1.16 if so.

Amazing job you all! At this rate we will end up with a better client than the one MS has for Windows/Mac.!!

from teams-for-linux.

First version #56

from teams-for-linux.

That looks promising!

Just reading the electron documentation, maybe the following works.

https://electronjs.org/docs/api/browser-window#browserwindowaddextensionpath

Never tried adding an extension, but it should work. Might need a delay as we are changing the browser from chrome to edge (or the other way round, I don't remember now)

Unfortunately I don't know when I will be able to test it.

Give it a go and make a pull request. I am happy to package it as 0.1.15 if it works! Thanks again!!

from teams-for-linux.

Screensharing with Teams and chorme/chromium working now for me.
The needed steps are to install following to plugins:
https://chrome.google.com/webstore/detail/microsoft-teams-screen-sh/dhheiegalgcabbcobinipgmhepkkeidk
https://chrome.google.com/webstore/detail/enable-teams-calling/ifgnnjhhfdpjpjokajkolhioakajhidc

The "enable teams calling" do basiclly following:

angular.element(document).injector().get('callingSupportService').oneOnOneCallingEnabled = true
	angular.element(document).injector().get('settingsService').appConfig.enableCallingChromeOneOnOne = true
	angular.element(document).injector().get('settingsService').appConfig.callingEnableChromeMeetingSingleVideo = true
	angular.element(document).injector().get('settingsService').appConfig.callingEnableChromeMultipartyVideo= true
	angular.element(document).injector().get('settingsService').appConfig.callingEnableChromeOneToOneVideo= true
	angular.element(document).injector().get('settingsService').appConfig.enableChromeScreenSharing= true
	angular.element(document).injector().get('settingsService').appConfig.enableSharingOnlyCallChrome= true
	angular.element(document).injector().get('settingsService').appConfig.enableCallingScreenPreviewLabel = true
	angular.element(document).injector().get('settingsService').appConfig.enableScreenSharingToolbar = true
	angular.element(document).injector().get('callingSupportService').isChromeMeetingSingleVideoEnabled = true
	angular.element(document).injector().get('callingSupportService').isChromeVideoMultipartyEnabled = true
	angular.element(document).injector().get('callingSupportService').isChromeVideoOneOnOneEnabled = true
	angular.element(document).injector().get('settingsService').settingsService.refreshSettings()

Compared with the MS Extension, screensharing working without setting a different UserAgent

Also tested the options with Rambox-OS and js injection.
I see all options and voice + video working. To get screensharing work a convert of the MS listener function to electron is needed.

from teams-for-linux.

Hi,
work :)
Changes:

• Changed User Agent to: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36
• Added files capture-selector.html, capture-selector.js, chrome-api.js to browser from danielhodder/teams-for-linux@3588853
• Added require('./chrome-api'); to browser/index.js

The basics seems to work... Now to the details :)

from teams-for-linux.

@syepes @IsmaelMartinez
As soon I have time I will push the changes. Above changes are on top of 0.1.16.
At the moment I see following problems/errors:

1. ScreenShare button not visible on startup until you change the view (e.g. go to channels and back to chats)
2. Thumbnail resolution and layout of the picker poor.
3. The resolution of the stream is partly really low. Think minheight/weight need to be adjusted
4. No notification/hint that screen sharing is currently enabled/active

from teams-for-linux.

@BlueCase, @byteSamurai and @dbaelz

We should probably create a few new "issues" in here so we/someone can tackle them in isolation.

Now the long message... apologies ;)

1. Is it really necessary to implement a own window picker? Someone know if the default chromium picker also available for electron or if a ready to use module exist?

I don't think we can easily use the chrome window picker and the electron implementation relies on creating a desktop picker. True we could just select the "window" by default but having multiple monitors might "break" that usage. So agree with @byteSamurai and we should keep it. Maybe v2 can have a config option where people can put the id that they want to always share.

2. At the moment the picker show also the teams-for-linux window. Should be hide or marked as "me"

Agree again with @byteSamurai. People might like to share that to show how to use the app... if we can determine easily that is the presentation screen, we can tag it like that (point 3)

3. We also should add labels/window names to the thumbnails.

Indeed, even better, we should group them by types like "window" or "screen" and also tag them (not sure how much info we get from the screens.

Notification:
Perhaps we could simply replace the default systray icon by a different one if screen sharing is in progress. Also a "Stop Sharing" function in the systray menu when active would be helpful.

That sounds like a great idea. Another one for version 2.

Alternatively, we can do like the windows desktop app and add a wee screen with what we are sharing
So we can do things like this:
https://twitter.com/darrel_miller/status/1105247834394320897

Further Bugs:

• In the native application or chrome, teams opening the call dialog when you select presentation only. At the moment nothing happens till the receiver accept the invite and then it took a while till i get a small conversation dialog (top/left). Work in chrome better or different :D

Will need to test this to fully understand what you mean. Maybe point 3 might help?

• Still have the feeling that the resolution of the stream need to improved. Sometimes the quality is good.. next time bad. Think that teams measure initial the link speed and select by this the streaming quality.

Something to look into. That could be a blocker for this if the resolution is that bad, but, if there is a work around like the one @dbaelz mentions, then it might be ok for v1.

from teams-for-linux.

@IsmaelMartinez

2019-03-13T09:21:13.171Z callingAgents: calling-stack [JS.TsCalling.MediaAgent] ffffffff: MA/DeviceManager/MediaStreamManager/SharingCP/CC None of available resolutions are suitable: [{"width":1920,"height":1088},{"width":1280,"height":720},{"width":640,"height":368}]. Fallback to: {"resolution":{"width":640,"height":368},"fps":1.875}

(anonymous) | @ | angular.min.js:formatted:3447

Seems the fallback to 640:386 is the reason for the poor quality.

from teams-for-linux.

@IsmaelMartinez you do such a great work, isn't is time to unfork this repo now? 🙈

from teams-for-linux.

I am afraid this is to be pass on to Microsoft. You can up-vote this suggestion:

https://microsoftteams.uservoice.com/forums/555103-public/suggestions/34241197-allow-screen-sharing-desktop-sharing-in-the-web

Closing this as the scope of this client is to wrap the functionality of the browser, not implement functionality that not even Microsoft are providing.

from teams-for-linux.

Reopening. Is one of those that is really not a issue for us as, as soon as they implement it for Chrome or Edge, we should get it... but yeah, keeping it open for the moment.

By the way, the "working on it" could mean finish next month, in 2 years... is fairly Agile but they should probably have a couple of more states to show progression.

from teams-for-linux.

I also want to believe! in miracles

from teams-for-linux.

It looks like there is an official chrome extension for sharing:
https://chrome.google.com/webstore/detail/microsoft-teams-screen-sh/dhheiegalgcabbcobinipgmhepkkeidk

from teams-for-linux.

Talking about miracles :)

I downloaded and unzipped the extension. Unfortunately it does nothing special in my opinion. The most interesting part is imho:

var listener = function (message, sender, sendResponse) {
    if (message === 'version') {
        sendResponse({
            version: chrome.runtime.getManifest().version
        });
    } else if (message === 'get-sourceId') {
        var tab = sender.tab;
        var screenOptions = ['screen', 'window', 'tab'];
        chrome.desktopCapture.chooseDesktopMedia(screenOptions, tab, function (streamId) {
            if (!streamId) {
                sendResponse({
                    type: 'error',
                    message: 'Failed to get stream ID'
                });
            }
            else {
                sendResponse({
                    type: 'success',
                    streamId: streamId
                });
            }
        });
    }
    return true;
};

chrome.runtime.onMessageExternal.addListener(listener);

But I am not sure how it might work in Electron 🤔

from teams-for-linux.

Reading the comments in the extension, it seems like is not working.

Hopefully is just a WIP, not sure. Thanks for keep searching @cameronrmorris and @byteSamurai , at some point we all will be able to share the screen with teams... or will move on to something that allows us to do it.

from teams-for-linux.

Thx @IsmaelMartinez

It might be a stupid question, but have you ever tried to reverse engineer the MS Teams app? I could imaging we find something useful after downloading the Java-Files, beautify them and study it. But its PITA work :/

In the end of April I have a couple of days and could try something like that, in case you haven't tried it already

from teams-for-linux.

Hi @byteSamurai , I had a quick look (not in deep). You can unasar the "asar" files and you get a bunch of Javascript (lots of lots). I didn't find anything interesting but is fairly lot of code and I didn't look for too long.

I tried setting the angular.element(document).injector().get('settingsService').appConfig.isDesktop = true that then enables the button, but doesn't work (some sort of missing skype session).

Feel free to try with the windows/mac client and see if you can get any closer... it should be possible but not sure if we will need to bypass Microsoft implementation and do it with webrtc (if that works) or we can just piggyback on some of theirs.

from teams-for-linux.

0.1.15 now is been released and got the ppt sharing presentation... as said before, not really solving the issue but I hope that improves the situation.

from teams-for-linux.

Yes, great, works for me, too. But only in "real" Google Chrome, in Chromium it doesn't work (when not using User Agent Switcher).

from teams-for-linux.

That is promising. Added a few more of those "parameters" and got the following "error" in the console:

0-angular-jquery.min-ae2a8f76.js:113 ReferenceError: chrome is not defined
    at s.isChromeExtensionInstalledAsync 

I will see if I got time to add the extension to the build and see if that makes it work... if anyone wants to try adding the extension this should work https://electronjs.org/docs/api/browser-window#browserwindowaddextensionpath

Do it in branch https://github.com/IsmaelMartinez/teams-for-linux/tree/0.1.16 . I don't know when I will be able to look into this.

from teams-for-linux.

This would be just amazing to be able to share the screen in Linux!

from teams-for-linux.

I have just also tried this version but it does not work: danielhodder/teams-for-linux@3588853

from teams-for-linux.

@BlueCase Do you have a branch with your changes? I can check it from my side.

from teams-for-linux.

Pull request to 0.1.16 if you can. We can test it and release it this week if all works fine. Great job!!

from teams-for-linux.

@IsmaelMartinez Thanks for the update!
About the window picker:

1. Is it really necessary to implement a own window picker? Someone know if the default chromium picker also available for electron or if a ready to use module exist?
2. At the moment the picker show also the teams-for-linux window. Should be hide or marked as "me"
3. We also should add labels/window names to the thumbnails.

Notification:
Perhaps we could simply replace the default systray icon by a different one if screen sharing is in progress. Also a "Stop Sharing" function in the systray menu when active would be helpful.

Further Bugs:

• In the native application or chrome, teams opening the call dialog when you select presentation only. At the moment nothing happens till the receiver accept the invite and then it took a while till i get a small conversation dialog (top/left). Work in chrome better or different :D
• Still have the feeling that the resolution of the stream need to improved. Sometimes the quality is good.. next time bad. Think that teams measure initial the link speed and select by this the streaming quality.

from teams-for-linux.

About the Stream quality:

[OpenH264] this = 0x0x99060a83ea0, Warning:ParamValidation(), AdaptiveQuant(1) is not supported yet for screen content, auto turned off
[OpenH264] this = 0x0x99060a83ea0, Warning:ParamValidation(), BackgroundDetection(1) is not supported yet for screen content, auto turned off
[OpenH264] this = 0x0x99060a83ea0, Warning:bEnableFrameSkip = 0,bitrate can't be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame.
[OpenH264] this = 0x0x99060a83ea0, Warning:Change QP Range from(0,51) to (26,35)
[OpenH264] this = 0x0x9905d523000, Warning:ParamValidation(), AdaptiveQuant(1) is not supported yet for screen content, auto turned off
[OpenH264] this = 0x0x9905d523000, Warning:ParamValidation(), BackgroundDetection(1) is not supported yet for screen content, auto turned off
[OpenH264] this = 0x0x9905d523000, Warning:bEnableFrameSkip = 0,bitrate can't be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame.
[OpenH264] this = 0x0x9905d523000, Warning:Change QP Range from(0,51) to (26,35)
[OpenH264] this = 0x0x9905d523000, Warning:ParamValidation(), AdaptiveQuant(1) is not supported yet for screen content, auto turned off
[OpenH264] this = 0x0x9905d523000, Warning:ParamValidation(), BackgroundDetection(1) is not supported yet for screen content, auto turned off
[OpenH264] this = 0x0x9905d523000, Warning:bEnableFrameSkip = 0,bitrate can't be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame.
[OpenH264] this = 0x0x9905d523000, Warning:Change QP Range from(0,51) to (26,35)

from teams-for-linux.

@BlueCase

Is it really necessary to implement a own window picker? Someone know if the default chromium picker also available for electron or if a ready to use module exist?

If you are using an external monitor you should avoid Chromium or Google Chrome at the moment, cause you cannot choose the desktops separately, see https://bugs.chromium.org/p/chromium/issues/detail?id=396091

jbtw: This issue is several years old

At the moment the picker show also the teams-for-linux window. Should be hide or marked as "me"

In my opinion: We are using Linux. We tend to know what we do. So I would not limit any options for the user here. Maybe someone would like to share a chat history oder a file stored in teams?

We also should add labels/window names to the thumbnails.

Good idea

from teams-for-linux.

Yesterday, I tested the pull request #56 on my Ubuntu 18.04.2 installation with a colleague (using a macbook). Overall the screen sharing worked really well. As mention before, the initial image quality was very poor. While sharing my screen, the colleague switched to the my camera window and back to the screen share window. This improved the quality of the stream significantly. At the moment I can't say if it was just coincidence or the quality adjusts when switching between the camera and the presentation window. But might be worth looking (or a workaround at least) and something I'd like to share for further testing and improvement.

I'll test the current 0.1.16 branch today (aka. typical working day) and see if I could provide more information. Thanks for the great work 🙇‍♂️

from teams-for-linux.

@byteSamurai

If you are using an external monitor you should avoid Chromium or Google Chrome at the moment, > cause you cannot choose the desktops separately, see https://bugs.chromium.org/p/chromium/issues/detail?id=396091
jbtw: This issue is several years old

I mean the dialog window for selecting the to share window/desktop. I also know about the bug round about the seemingly unsolvable chrome issues to select a external monitor :D

In my opinion: We are using Linux. We tend to know what we do.

That's exactly the problem why it's hard for new Linux users to get things work and go back to window. But that's a off topic :)

So I would not limit any options for the user here. Maybe someone would like to share a chat history oder a file stored in teams?

Because of that I wrote "or mark" ;)

from teams-for-linux.

Thanks again for all the hard work on this subject.
I have been using it and it's pretty ok, apart from the already mentioned stuff.

The screen selector can be an issue if you have multiple screens, I have tested it with 3 and it can get messy. Basically it only allows to share all 3 screens together or a single app window.

Definitively it would be great to have the possibility of selecting one of the external screens.

from teams-for-linux.

The screen selector can be an issue if you have multiple screens, I have tested it with 3 and it can get messy. Basically it only allows to share all 3 screens together or a single app window.

But this is standard WebRTC behaviour on Linux, it's the same in GoToMeeting, in Google Hangouts and previously was in Hipchat. So that's okay. When I want to share the whole screen, first I deactivate all other screens except one.

from teams-for-linux.

But this is standard WebRTC behaviour on Linux, it's the same in GoToMeeting, in Google Hangouts and previously was in Hipchat. So that's okay. When I want to share the whole screen, first I deactivate all other screens except one.

Not part of this issue:
I am aware of that and yes: I would handle it the same way. But first I would like to play with it:
Does the WebRTC API offer any option to control the captured screen section in pixel? Then I would check for the aspect ratio of the capture sources. Just an idea. I have not experience with it!

from teams-for-linux.

If tomorrow I can tests this at work, and it works fine, I am happy to release 0.1.16. I will appreciate if you people can do some testing on this if at all possible! (and/or improve it!)

@IsmaelMartinez today I'm using teams from 0.1.16 branch, screen sharing works perfectly (good job everyone involved!!). The only weird thing is that after Teams startup 1:1 calls work just fine, but if I just keep Teams opened, after a while I can no longer call, I'm getting the "calls are not supported" banner. Restarting Teams helps, but it has already happened twice for me today.

from teams-for-linux.

It might be more discoverable as a fork, because people still stumble upon ivelkov/teams-for-linux, but at least this repo shows up in the Network tab as being the one that is actually maintained 😉

@IsmaelMartinez it still happening. Could you explain what's the root cause, what kind of timeouts are you trying to add and why they help? Is there a workaround that does not require teams restart?

I have now soo many colleagues who are eager to start using screen sharing, but for one or another reasons cannot build from source. Please don't delay the release too much, a version that has screen sharing but occasionally requires restart is still much better than a version with no screen sharing 😉

from teams-for-linux.

I will release 0.1.16 as a Pre-release (as I think is not really that neat) so people can start using and creating issues in here. I will close this issue. Could any of you add new issues as you see/find? I will be out until Tuesday so can't really do much changes to it. Thanks again to everyone involved!

from teams-for-linux.

@IsmaelMartinez Think for a first release it is great.. More as MS delivered till now ;)

from teams-for-linux.

@IsmaelMartinez thank you a lot! Maximum efforttttt!

from teams-for-linux.

Seems like MS is now going to provide all of this "pretty soon"

Extract from here:
https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/What-s-new-in-Microsoft-Teams-the-Enterprise-Connect-feature/ba-p/376255

"Enhancements to the Chrome browser meeting experience (coming soon) are getting richer for Windows and Mac users. A year ago, we introduced frictionless meeting join in Chrome with no client needed. Coming soon, we will enhance that zero-footprint experience by adding 3 new capabilities: the ability to see participants video, application sharing, and full desktop sharing. This enables any meeting attendees to have face to face conversations and share content easily, with zero downloads needed."

from teams-for-linux.