Blurry shared screen
complete
J
Jonas Erlandsson
When my colleague is sharing his screen it takes a long time for the screen to actually render properly, and as soon as he starts scrolling it gets all blurry again.
He's on a decent internet connection. This haven't happened before. He's not maxing the connection either, so it doesn't feel like it's because of the connection, but how screen is using the network.
If he stops the share and then re-share the screen it works for a little while, then it gets back to being super blurry again.
Log In
J Sherwani (Pop Team)
complete
This should now be fixed with some significant updates to our video encode pipeline! Let us know if you still encounter this issue.
A
Alessio Orazietti
I have the same problem, but usually not when I share my screen but when my colleague share his screen. My sharings appear not blurry to my mate, but his sharings are almost always blurry. (I have a MacBook Pro 16 2020 and he has a MacBook Pro 15 2016)
J Sherwani (Pop Team)
in progress
J Sherwani (Pop Team)
This is something we haven't seen recently (since we've fixed many issues that could have contributed to this), so we definitely want to fix this for you and your colleague. The screenshot shows that something is definitely wrong on our end!
Could you try again, and please share:
1) Screenshots of the stats view (mini panel > ... > graph icon) for both you and your colleague, when you're screen sharing (try both ways to see if the problem is symmetrical)
2) Details on the screen share host (screen resolution, and hardware)
3) Screenshot of a bandwidth speed test (e.g. via speedtest.net) for both participants
Thanks!
S
Seth Nickell
J Sherwani (Pop Team): Hi, we're seeing this off and on. Its not a huge problem (our workaround on mac is to expose the screen, to get a full 'keyframe' refresh), but its worth noting that what we've seen is that once the screen is blurred, if you don't change the screen (e.g. say you are sharing your screen and staring at a code without moving the mouse or keyboard for a minute), once it blurs, it won't fix itself without changing what's on the screen.
To me, this looks like perhaps a keyframe was missed (out of order UDP packet dropped due to being received after what was intended to be a followup packet?), and when the screen is static, sending a new keyframe is not triggered.
Curiously, while we've found a tiny "whole screen change" like expose quickly resolves the issue, and is easy for people watching ot trigger non invasively as needed, we've also noticed this almost looks like it tends to happen more frequently for screen sharers who use OSX in a way that triggers full screen animations followed by long no-screen-changes, in particular people who use the "three finger swipe left and right between desktops" seem most likely to cause a "stuck blur"
This is again consistent with the idea that the problem is a keyframe being dropped due to a newer "screen delta update" packet arriving first, which of course doesn't work, because you can't delta update if you don't have the master state to delta from.... three finger swipe probably triggers large packet-size keyframes due to full screen pixel changes, and a flurry of immediate deltas because its a LONG full screen animation, thereby upping the risk of a (small) delta UDP packet arriving before a big keyframe packet..... and then the final finishing blow here is that three finger expose users often don't change anything after the animation, they just swiped to docs e.g., and sit there reading without changing the screen, a perfect storm for the final state after a long pause being a corrupted delta packet over a missing keyframe.
Probably totally wrong in my guessing here, but I get a long time to meditate on this while watching pair screenshares, and thought it might trigger a thought on your side for what would prolly be a very hard bug to guess at
S
Seth Nickell
J Sherwani (Pop Team): also worth noting that I see this a lot more sharing screens over long distances. We have zero packet loss between our IPs, and between us and screen's servers, so its not that, but UDP over long multi-hop routes does dramatically increase the odds of out-of-order packets
S
Seth Nickell
Also, I have a large and varied sample set experience with no common IPs, ISPs, locations, people, computers, or any hardware
The only general correlation I have noticed is: "the longer the ping between people or perhaps the number of network hops (?), the higher the chance of a stuck blur occuring"
J Sherwani (Pop Team)
Seth Nickell: Thank you for the detailed description. I think I know exactly what the issue is. It's related to the API for screen capture on macOS, where we don't get frame updates if the screen doesn't change (which makes sense from the OS' perspective). We had code that accounted for this issue, but removed it temporarily due to the complexity it was adding for an unclear value, and your post reminded me that there is significant value. So we're now going to bring it back mindfully to fix this while minimizing its complexity (we've learnt a lot about Electron/WebRTC since we started working on this product). I'll post an update here once we've made progress on this front.