Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
julian-alarcon opened this issue Mar 14, 2019 · 80 comments
Closed

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

julian-alarcon opened this issue Mar 14, 2019 · 80 comments
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested

Comments

@julian-alarcon
Copy link
Collaborator

julian-alarcon commented Mar 14, 2019 •
edited
Loading

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
@julian-alarcon julian-alarcon changed the title Low quality in screen sharing on 1 to 1 calls Low quality in screen sharing on 1 to 1 calls v0.1.16 Mar 14, 2019
@IsmaelMartinez
Copy link
Owner

IsmaelMartinez commented Mar 15, 2019 •
edited
Loading

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
Copy link

brennerm commented Mar 15, 2019 •
edited
Loading

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

@developer2048
Copy link

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
Copy link

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
Copy link

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
Copy link

developer2048 commented Mar 16, 2019 •
edited
Loading

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
Copy link
Owner

IsmaelMartinez commented Mar 18, 2019 •
edited
Loading

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.

@IsmaelMartinez IsmaelMartinez added enhancement New feature or request help wanted Extra attention is needed labels Mar 18, 2019
@chrisgns
Copy link

Hi, it is #64 ,
sorry for the noise

Christoph

@foot3print
Copy link

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
Copy link

developer2048 commented Mar 19, 2019 •
edited
Loading

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
Copy link
Owner

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
Copy link
Owner

IsmaelMartinez commented Mar 19, 2019 •
edited
Loading

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
Copy link
Owner

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

@IsmaelMartinez
Copy link
Owner

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
Copy link

developer2048 commented Mar 20, 2019 •
edited
Loading

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
Copy link
Owner

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.

@julian-alarcon julian-alarcon changed the title Low quality in screen sharing on 1 to 1 calls v0.1.16 Low quality in screen sharing on 1 to 1 calls Mar 22, 2019
@julian-alarcon julian-alarcon mentioned this issue Mar 22, 2019
Closed
@IsmaelMartinez
Copy link
Owner

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
Copy link

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
Copy link
Owner

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
Copy link
Owner

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 #61 (comment)

@IsmaelMartinez IsmaelMartinez mentioned this issue Mar 27, 2019
Closed
@developer2048
Copy link

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
Copy link
Owner

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

@developer2048
Copy link

@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
Copy link
Contributor

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.

@byteSamurai
Copy link
Collaborator

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
Copy link
Owner

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
Copy link
Collaborator Author

julian-alarcon commented Aug 9, 2019 •
edited
Loading

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 julian-alarcon reopened this Aug 9, 2019
@julian-alarcon
Copy link
Collaborator Author

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

@IsmaelMartinez
Copy link
Owner

IsmaelMartinez commented Aug 9, 2019 via email •
edited
Loading

@IsmaelMartinez
Copy link
Owner

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
Copy link
Collaborator

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

@IsmaelMartinez
Copy link
Owner

@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
Copy link
Owner

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
Copy link
Owner

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

@IsmaelMartinez IsmaelMartinez added the question Further information is requested label Aug 14, 2019
@byteSamurai
Copy link
Collaborator

@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

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
Copy link
Owner

IsmaelMartinez commented Aug 14, 2019 via email

@mschirmacher
Copy link

@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
Copy link
Owner

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
Copy link

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
Copy link
Owner

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

@IsmaelMartinez IsmaelMartinez mentioned this issue Aug 19, 2019
Closed
@IsmaelMartinez
Copy link
Owner

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
Copy link
Owner

Ignore my previous message. Reopening

@IsmaelMartinez
Copy link
Owner

Can you guys test if it now works? according to #241 (comment) MS has fixed something... and is in the same area so maybe it also fixes our problems?

@julian-alarcon
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests