Teams-for-linux: Low quality in screen sharing on 1 to 1 calls

[julian-alarcon]

When using screen sharing between only 2 peers the quality of the screen is pretty low.

If the screen sharing is between 3 or more people the quality is great with no issues. If you are in a one and one screen sharing and invite to someone else the quality wont be improved, you have to cancel and reshare the screen to fix the quality issue.

I'm using Snap build on Ubuntu 18.04 with Xorg (no Wayland) using version 0.1.16 of teams-for-linux.

Attached is an screenshot that show the issue.

[IsmaelMartinez]

Can you see if there is something in the console (logs). I think is the webrtc using a pretty low default quality, but not sure how to override it at this moment.

Strange it works ok for 3 people... I think it might be related to the screen you are trying to share... But isjust speculation

[brennerm]

Can confirm the very low resolution during one-to-one calls.

[Developer2048]

Thanks a lot for 0.1.16. Screen sharing works now. :-)
I also confirm a low quality in 1:1 calls (not enough to read on a shared terminal). With 3 people it is a lot better. Not perfect, but good enough to read a shared terminal...

[chrisgns]

It does not work for me on Centos 7, do I have to install any additional package to get it working, I am using the latest released rpm.

[maximbaz]

Could it depend on network quality? I've been using screen sharing in 1:1 calls for two days now, the quality is just perfect

[Developer2048]

I have a 50/10 Mbits connection at home, which works great with Zoom (telephony and screensharing). But you are right, I tested screen sharing in a local network and it worked without any issues in quality or sound.

[IsmaelMartinez]

Might be good if you can check if there are any logs (start app with --webDebug) that are different between sharing between 2 and 3 people.

@chrisgns , can you open a separate issue and provide more information about what you (not) see?

ps: not marking this as a bug... but almost.

[chrisgns]

Hi, it is #64 ,
sorry for the noise

Christoph

[foot3print]

Hi,

i can confirm that the 1:1 screen sharing works on the first share.. a soon as i close screen-sharing and reshare another screen, the video quality goes down. I tested this 5x with the same results. BTW, thank you for actively updating this project.

Regards,

[Developer2048]

I can confirm foot3print discovery (tested one time).
First screen sharing worked fine (in a 1:1 call), no error messages.
Second screen sharing (I shared my screen, still 1:1) was in bad quality with following error message:
https://pastebin.com/BX3qKTC7

[IsmaelMartinez]

Thanks @foot3print and @Developer2048. That should help finding the core issue. Can you confirm if the quality is bad from the second one on, or just alternates (one good, one bad)?

[IsmaelMartinez]

Might be worth trying reverting the chrome user agent to before 69 (check history of config/index.js). Just run with this crazily long string

teams --chromeUserAgent "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36"

[IsmaelMartinez]

Ignore that last one, it is needed for been able to do the screenshare.

[IsmaelMartinez]

The following are things that might be worth checking/testing:

• disabling the hardware acceleration in the app. Edit the main index.js and add app.disableHardwareAcceleration() around line 17/18 : https://github.com/electron/electron/blob/master/docs/api/app.md#appdisablehardwareacceleration
• disabling the gpu rendering in the app: (similar but a bit more internal). For this try starting the app with teams --disable-gpu
• trying to change the applyConstraints for the video (https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/applyConstraints#Examples)

Unfortunately I am just blind. We don't do screenshare or much video at my work. Can any of you try those options? The last one probably is a bit more tricky to test... and is also the one that I believe less in.

[Developer2048]

Thank you for the support!
In my case (at least today) the quality seems to depend on who shares the screen. When I shared the screen, it is in bad quality, when my colleague shared his screen, it worked fine (tested 4 times). Error messages were the same like posted. I remember, that I also saw a screen sharing in bad quality on my notebook (not today), so it seems to be more random...
I was able to test the second point (--disable-gpu) only. This had no impact. I will try the first option on Monday and report then.
To be honest I have no idea how to implement the third option. I found the string "applyConstraints" in two binary files only. What I have to do?

[IsmaelMartinez]

To be honest, I don't think the last one will work, I think the best bet is to try to make electron use another decoder "vp8/9". Might be worth seeing if we can activate this with some flags. (but I might be looking in the wrong place)
https://peter.sh/experiments/chromium-command-line-switches/

Now, a bit unrelated but fairly close enough to the topic.

Seems like MS is going to support this (screensharing in chrome) pretty soon.

They announced yesterday video, audio and screensharing will be supported soon in Chrome. Check my comment in #19 for further info.

This might or might not solve the issue, or might require a bit of wiring up, so worth keeping an eye on it.

[IsmaelMartinez]

Could this ms issue give some info about this issue??

https://techcommunity.microsoft.com/t5/Microsoft-Teams/Microsoft-Teams-low-font-resolution-and-blurry-text/td-p/293125

Maybe is the monitor configuration. If using multiple monitors, try sharing the same app but I'm different monitors... And turn off Anti-Aliasing if all seems to have the same problem.

Hope helps!

[Developer2048]

Sorry, I can't test today and will be not available for the rest of the week. I will try to discover how to disable AA in Gnome (I don't think, disabling Fonts AA is enough, right?) and be back next week...

[IsmaelMartinez]

Hi @Developer2048 , try the fonts... I am not sure if that is just different name in the windows domain...

Let us know how you get on. No rush.

[IsmaelMartinez]

Actually, by doing #83 might fix this, or at least probe if the more than one user theory is right.
@julian-alarcon , @brennerm or @chrisgns, can you check the AA there while @Developer2048 is not available? See comment https://github.com/IsmaelMartinez/teams-for-linux/issues/61#issuecomment-475813311

[Developer2048]

So, I tried to test the first recommendation (disable hardware accelaration). Same behavior (low quality) Since I'm disabled Anti-Aliasing in Gnome Fonts menu only, I'm not sure if this is what needed to be tested...
I will wait now until the new version is available...

[IsmaelMartinez]

@Developer2048 , are you able to test this from source? Thanks.

[Developer2048]

@IsmaelMartinez , I tested it with 0.1.16 and 0.1.17 releases. For 0.1.17 I used the package and for 0.1.16 the source (as far as I remember).
I have a 3 monitor (notebook + 2 external monitors) configuration. Today I shared different windows from each monitor. The share of notebook monitor was not good, but better then the share of a window on the external monitors...

[zeitounator]

I can confirm this on my side with 0.1.17 deb package. Didn't get the time to test from source.

1-to-1 screen sharing quality is poor when not totally unreadable where screen sharing in a meeting is good.

[IsmaelMartinez]

Hi, can you guys test 0.2.0 and see if this still an issue? Maybe, as now we have another "screen" in the mix (the one that shows what you are sharing) this might be solve... but that is a pretty looooooooong shot.

Again, I am incline to wait until MS release the promised screen sharing support for chrome:
https://microsoftteams.uservoice.com/forums/555103-public/suggestions/36131932-allow-anybody-to-share-their-screen

[zeitounator]

Hi @IsmaelMartinez.

I didn't test thoroughly but my 2 tries with 2 different persons had a very good screen sharing quality in 1-to-1. Cheers.

[IsmaelMartinez]

Hi,

I will close this and, if someone else still having this issue, can reopen.

Thanks!

[byteSamurai]

Hey @IsmaelMartinez,
I testet several times with 0.2.0, but the quality is pretty bad :/
Can you reopen it please?

[IsmaelMartinez]

I can only think on moving to electron 5.0 and see if that helps...

Unfortunately, then the spellchecker will need to be removed as it fails to build. Issue is in here:
https://github.com/atom/node-spellchecker/issues/112
PR open in here https://github.com/atom/node-spellchecker/pull/108

Electron 5.0 uses version 73 or Chrome browser, so that might do the trick.

Apologies, but this is now blocked :(

[byteSamurai]

Apologies, but this is now blocked :(

Absolutely not needed. You do a great job here!

Just keep this open please until the hopefully merge that PR. I would miss the spellchecker, so lets give them some time.

[IsmaelMartinez]

One last thing. Does the screensharing work fine when you only have one monitor? (no external monitors).

[julian-alarcon]

I tested this, with 2 screens additional, 1 screen additional screen and just 1 monitor. The issue was the same on Ubuntu 18.04 with GNOME. Tried multiple screen resolutions even lower.

The weird stuff is that on a VM (KVM) with Centos 7 the screen sharing worked with no issues, the display resolution of the VM was small but I already tried that on Ubuntu.

BTW, seems to be an issue with Ubuntu, as I know Kubuntu works fine and Centos too. Maybe is a GNOME related issue, but Centos also uses GNOME (and old version but still)

I'll keep checking this bug.

[IsmaelMartinez]

Does anyone not using Ubuntu has this issue? If no-one shouts I might change the title of the issue to be more specific

[byteSamurai]

Fedora here using Gnome 3.30. Also some of my colleagues using AwesomeWM having this issue.

@IsmaelMartinez But all we are using external monitors and I can imagine once, I was in a meeting at the customer (without any external screen) where I could share my screen without any problems. It was v0.17, but then I never ever was able to get a good quality for screen sharing. So in my opinion checking for external monitors might be a way to dig deeper.

[IsmaelMartinez]

It does smell like a Gnome multi monitor issue... Not sure if we can do anything in the client about it... Might be worth checking in other clients, slack or skype, and see if they had/have a similar issue in case there is already a solution out there.

[byteSamurai]

okay, we just tested it:

• GDM + Gnome + external monitor -> good quality at the beginning. Dropped after a fews seconds
  (logged out and restarted GDM)
• GDM + Gnome + single monitor: poor quality from the beginning
• LightDM + Budgie-Desktop + single monitor: poor quality from the beginning

We tried to share a single app (chrome) as well as the whole desktop.

So before we get any evidence on this I highly doubt its something wrong with gnome - even this was a spark of hope to get things better.

Btw @IsmaelMartinez is there a ticket to close the additional window after screensharing has been stopped? At the moment if we start screen sharing multiple times we have multiple "What you currently share" windows.

Also: What video codec are we using for screen capture at the moment? H.264? :thinking:

(edit: Typos)

[IsmaelMartinez]

I tried specifying different codecs, but we should be using the default from electron that I think is h.264.

This really smells a linux environment issue rather than our implementation... as we don't really do much on that area, only reuse what electron and chrome provides. Otherwise everybody will be having the issue, but I might be wrong.

Regarding the screensharing additional window, feel free to create another issue. Did saw it while implementing but didn't had the time to work around it.

[mxsteini]

I did a npm update wich downloaded electron 4.2.0. That fixed the problem for me.

[julian-alarcon]

@mxsteini are you sure about that? I just read your comment and rebuild 0.2.1 version to use electron 4.2.0 and the issue is still there.

I'm using Ubuntu 18.04, multiple screens (already tested with only one screen and the issue persisted), snap build (local build not Store or GitHub snap).

How is your System and which build are you using? rpm, deb, AppImage, Snap, source?

[mxsteini]

@julian-alarcon this is quite mysterious. Today I ran my old rpm and I cannot reproduce this whole issue - sorry.
This App is working correct on my 4k laptop:
Fedora 30, gnome 3.32.1, wayland, intel graphic, external 4k screen, laptop is scaled to 200%
Sharing windows works
Sharing Desktop not (Screen is black, only mouse ist sharred)

Also on my kollegues
Fedora 30, gnome 3.32.1, wayland, nvidia graphic, two screens
Sharing windows works
Sharing Desktop works

[byteSamurai]

@mxsteini @julian-alarcon

Can we collect our dm stacks here?

| Item | Value |
|--------------------------------------|------------|
| External Monitor while startet Teams | yes and no |
| Distro | Fedora 29 |
| Desktop-Manager | GDM |
| Desktop + Version | Gnome 3.30 |
| Teams Version | 0.2.0 |

[julian-alarcon]

@julian-alarcon this is quite mysterious. Today I ran my old rpm and I cannot reproduce this whole issue - sorry.
This App is working correct on my 4k laptop:
Fedora 30, gnome 3.32.1, wayland, intel graphic, external 4k screen, laptop is scaled to 200%
Sharing windows works
Sharing Desktop not (Screen is black, only mouse ist sharred)

Also on my kollegues
Fedora 30, gnome 3.32.1, wayland, nvidia graphic, two screens
Sharing windows works
Sharing Desktop works

Black Desktop may be related to Wayland, but I'm not sure as your colleges are using Wayland too.

I'll try Wayland today on my Ubuntu conf.

[byteSamurai]

Black Desktop may be related to Wayland, but I'm not sure as your colleges are using Wayland too.

It is. As far as I know it could work, if you start team with an "backend xServer" for e.g. modifiy your desktop file with something like this:
GDK_BACKEND=x11 teams...

[rumatoest]

I'm using debian buster (no wayland) and screensharing often translates black screen. I've noticed that actually screen sharing works but after few minutes it became black. The same thing happens if you will stop desktop sharing and turn it on again.

[mike-of-earth]

My screen share quality is poor on 1-many. I haven't got another workstation to test 1-1 ATM. Shall I open another issue or track here? Thanks so much for your hard work @IsmaelMartinez !
Manjaro 5.0.18 kernel.

UPDATE: I was able to test with a coleague, and 1-1 was perfect for him.

[IsmaelMartinez]

@rumatoest and @mike-of-earth , thanks for your comments.

MS are implementing screensharing for the browser, so they well might be hitting, and solving, those issues. I don't have the time to look into them into detail so can't do much.

Maybe check if restarting the call/share, works. I haven't had myself any issues with screensharing but I am not using it much.

[IsmaelMartinez]

I am going to close this as it has become a dumping ground. Moving to #156 might find this issue, but I have no time at this moment (and the task is fairly tedious as electron have changed quite a few things around that area). Feel free to create a new bug with the distilled info from here.

[IsmaelMartinez]

Actually, just looking around for another issue I found this that might be related

https://electronjs.org/docs/faq#the-font-looks-blurry-what-is-this-and-what-can-i-do

Worth a try...

[byteSamurai]

How are blurry fonts in the UI related to low quality screen captures? Did I miss something?

[IsmaelMartinez]

Not sure but it might be related to anttialiasing as it is a rendering issue. To be honest, we have tried that many different things and only affects a few people so I am tempted to try it and see if this goes away

[IsmaelMartinez]

ok, version 0.3.2 should be out in snap edge soon (next hour) with this background stuff. please comment with whatever you find. If I don't see any comments in the next few days I will close this ticket (as mentioned before) as it feels like it has become a bit of a dumping ground.

update: travis seems to be a bit f*&( so maybe is out there tomorrow...

[byteSamurai]

I don't understand how this might be related to this issue. Could you explain it please?

Furthermore I managed to get some time to investigate on this issue after 12th July. I have also a technical user/account in a separate network to deep a bit deeper. Is it possible to keep this ticket open while July? I will report back anyway what I have done.

[IsmaelMartinez]

hi @byteSamurai , happy to keep it open if still is an issue.

The reasoning behind is that antialiasing is a rendering technique, and some people seems to be having an issue with the rendering. .

Also, is something new in the docs (added 2 days ago). The issue seems to be old but still present in electron (as far as I can see from the docs).

As that change should not have any side effect, I thought worth a try.

To be honest, I have tried doing screenshare with quite a few different monitors in many different circumstances but video was always fairly decent.

Happy to keep it open, in any case, seems like travis-ci is not doing behaving so 0.3.2 will take longer to be out.

Thanks for checking it out, if you want, it might worth investigating moving to electron 5, but the window.chrome.runtime override in https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/app/browser/desktopShare/chromeApi.js seems to not work anymore in electron 5.x (not 6 or 7) - Mentioning it as I think you did work on that area.

[rumatoest]

In 0.3.2 Screen sharing works way better. Resolution is Ok

[IsmaelMartinez]

@julian-alarcon , as you did open it, can you have a check to see if 0.3.2 screen sharing now works fine? Ta

[IsmaelMartinez]

also @byteSamurai, can you also check if 0.3.3 (or 0.3.2) quality has improved? it does sound crazy that setting the background white fixes this issue but I have seen worse/crazier fixes.

[byteSamurai]

Yes, but keep in mind I need to start next weekend. (time is like sand)

[IsmaelMartinez]

I have added that background stuff to version 0.3.2. If that works, then feel free to play around with version 5 of electron. Is giving me a few headaches (and I have no much sand, I mean time).

In any case, thanks a lot for expending time on this!

[julian-alarcon]

I can confirm, using the latest version (edge in Snap Store) 0.3.3 the quality improved a lot! There are not differences! I think that we can close it.

This may also be related with the changes that MS made to the videocall interface recently (square icons and maybe under the ground changes).

[IsmaelMartinez]

closing and starting to pack stuff to release 0.4.0... once we move to electron 5 (if ever) I change the number to 1.0.0. Thanks!

[byteSamurai]

We did some test here with several users, comparing mostly v0.2.0 with the current master branch.
Outcome -> Quality is identical, but not bad at all!

In my opinion MS may did some optimizations under the hood at the same time we were try to discover what is going on here.

As everyone seems to be happy, case closed and again GJ @IsmaelMartinez. Thank you!

As far as I see, there is some polish needed on the dialog selecting the app/window one likes to share. Also the current sharing stream window could be a chromeless windows. I don't know how this is related to electron 5. What can I do right now?

(@IsmaelMartinez you got mail from me, feel free to say me, how I might help you )

[IsmaelMartinez]

Hi @byteSamurai ,

Thanks for checking it. To be honest, I never experienced the issue myself so just tried to fix something blind (what is fairly tricky)

Replying your email in here, any help is always more than welcome.

I just created the Gitter channel so hopefully communication is a bit better than now. It might also help people to help each other.

My current plan is to merge the PR that is in the middle, and release 0.4.0. Then spend sometime with the electron 5. I don't think is urgent yet, but there are only two parts not working.

We will need to move to electron 5/6/7 soon.

If you want a challenge, that task is then the one for you ;) If you prefer something easier, but equally useful, working in the screensharing area might also be a great idea. Now it works but got a few edges that will be nice to trim :) There might be a couple of challenges around it.

Thanks again!

[julian-alarcon]

This issue appeared again with version 0.6.3. One to One quality is bad, but in groups there is no issue.

It's possible to try the same workaround previously used?

[julian-alarcon]

The workaround is in place... Maybe is a new bug.

[IsmaelMartinez]

Hi, can you confirm it is not on 0.6.0 (stable) also with the 0.6.4 (as it wait now to clean the cache)? Just to see if is related to our app or something from the website part.

If is the clearCache stuff I will then put it as a config option.

Thanks

On Fri, 9 Aug 2019, 17:01 Julian Alarcon, [e-mail] wrote:

The workaround is in place... Maybe is a new bug.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IsmaelMartinez/teams-for-linux/issues/61?email_source=notifications&email_token=AADJHEHKS6DO5HFS2EU2I2DQDWIHHA5CNFSM4G6T6QIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD37CXZA#issuecomment-519973860,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADJHECHBEU6XHNWL7IY6E3QDWIHHANCNFSM4G6T6QIA
.

[IsmaelMartinez]

Actually, we are reverting the changes from 0.6.3 so, hopefully, this goes away as they go away. Can you test with 0.6.0 and see if the quality is fine? Once the other stuff is packet and ready to go I release a edge version of 0.6.5 and see if still the case.

Hopefully I get some time at lunch time on Monday!

[byteSamurai]

JBTW: I am still on 0.4.0 and we are facing the again the same issue. Could it be something on MS side? :thinking:

[IsmaelMartinez]

@byteSamurai , do you have the blank/white loading screen every now and then? Just to check if you need to buildup cache in order for the call to be better... to be honest, I doubt it.

Are group calls still ok? Is this only 1-2-1? And yeah... probably Microsoft and/or your network.

[IsmaelMartinez]

worth having a look at this (but grab a coffee or two before you start, pretty long read):
https://docs.microsoft.com/en-us/microsoftteams/monitor-call-quality-qos

[IsmaelMartinez]

Hi @byteSamurai and @julian-alarcon , did you get a chance to read that long document? also... are you still experiencing the issue? Thanks!

[byteSamurai]

@IsmaelMartinez Actually QoS should be established in our networks. But I will ask our IT department as they are monitoring most of our traffic, maybe also QoS.

Nevertheless: I don't think its related to this because some of my colleagues are willing to work with me via Zoom. In Zoom gives me a perfect quality every time! No matter if I work from home or not.

---

At the moment I have a completely different problem: After almost every start if teams it stucks in initializing. If I clear the cache, I can log in once (after a use-the-desktop-app notification).

Affects 0.4.0 as well as 0.6.0 so it looks it is related totally on something MS has changed?

I am investigating and write an issue if I am sure, its not related to our AD.

[IsmaelMartinez]

That is #171. Look at my last comment. 0.6.6 or higher should have this
fixed

On Wed, 14 Aug 2019, 21:34 Alfred Feldmeyer, [e-mail]
wrote:

@IsmaelMartinez https://github.com/IsmaelMartinez Actually QoS should
be established in our networks. But I will ask our IT department as they
are monitoring most of our traffic, maybe also QoS.

Nevertheless: I don't think its related to this because some of my
colleagues are willing to work with me via Zoom. In Zoom gives me a perfect

quality every time! No matter if I work from home or not.

At the moment I have a completely different problem: After almost every
start if teams it stucks in initializing. If I clear the cache, I can log
in once (after a use-the-desktop-app notification).
[image: image]
https://user-images.githubusercontent.com/6654064/63054081-774e8900-bee3-11e9-9ec5-14aef824df9b.png

Affects 0.4.0 as well as 0.6.0 so it looks it is related totally on
something MS has changed?

I am investigating and write an issue if I am sure, its not related to our
AD.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IsmaelMartinez/teams-for-linux/issues/61?email_source=notifications&email_token=AADJHEHPVC3HV5Z7WR6CGULQERT5XA5CNFSM4G6T6QIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4KA4CY#issuecomment-521408011,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADJHEBT2N7MYXLO6WRQEJTQERT5XANCNFSM4G6T6QIA
.

[mschirmacher]

@IsmaelMartinez bad news: from yersterday to today Screensharings i reveice are completly blurred. Was running 0.6.6 and installed 0.6.7 today - no difference. I guess microsoft again made some changes :-(

[IsmaelMartinez]

one-2-one calls or group ones? We don't do screensharing at my office (as we all sit pretty close to each other) so it is always a bit more difficult to test this things... Is it possible to test with version 0.5.0 and see if is better? (just to make sure is not the newer version of electron that introduce this)

[mschirmacher]

Ok we tested a bit:
It's blurred in group vide chats as well as in scheduled meetings in 0.5.0, 0.6.6 and 0.6.7
BUT it's crystal clear in one-2-one calls - so maybe i'll just open a new issue for that one?

[IsmaelMartinez]

Open a new issue but I will point you 1st to MS... https://docs.microsoft.com/en-us/microsoftteams/monitor-call-quality-qos

[IsmaelMartinez]

I will actually close this one and move it to the #241 as this issue is a bit polluted.

As I mentioned in the other issue, I think it might be one of the changes introduced in 0.5.0.

[IsmaelMartinez]

Ignore my previous message. Reopening

[IsmaelMartinez]

Can you guys test if it now works? according to https://github.com/IsmaelMartinez/teams-for-linux/issues/241#issuecomment-523813914 MS has fixed something... and is in the same area so maybe it also fixes our problems?

[julian-alarcon]

Hi!

I just made a test with snap version edge: 0.7.0 2019-08-23 (59) 52MB

No issues! Seems to be a server/service issue from Microsoft, and now the fixed again.