search

IsmaelMartinez / teams-for-linux

Unofficial Microsoft Teams for Linux client
GNU General Public License v3.0
2.92k stars 237 forks source link

Low quality in screen sharing on 1 to 1 calls #61

Closed julian-alarcon closed 5 years ago

julian-alarcon commented 5 years ago

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. image

IsmaelMartinez commented 5 years ago

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 commented 5 years ago

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

Developer2048 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Hi, it is #64 , sorry for the noise

Christoph

foot3print commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

IsmaelMartinez commented 5 years ago

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

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Developer2048 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Hi,

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

Thanks!

byteSamurai commented 5 years ago

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

IsmaelMartinez commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

julian-alarcon commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

okay, we just tested it:

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 commented 5 years ago

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 commented 5 years ago

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

julian-alarcon commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

IsmaelMartinez commented 5 years ago

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