Best Settings for Code Screensharing

I’ve created a Jitsi integration that is helping us hold virtual office hours for my CS class. Students stay in a room while staff circulate. Access is controlled by JWT tokens.

Everything works pretty well—except that the desktop screen sharing quality isn’t always great. Usually students are sharing their screen with us and staff are just using audio, allowing them to examine student code and provide suggestions. But frequently the quality of the screencast isn’t good enough to actually read code visible in an IDE or browser tab.

I’m going to start fiddling with the video streaming settings here and I’m wondering if anyone with more experience in this area has any advice. This application has somewhat different requirements that typical video sharing. Specifically, there’s really no utility is delivering a frame that is too blurry to read for the sake of preserving motion. I’d rather have a very (very) slow frame rate, but have the delivered frames be readable.

So far it seems worth trying some of the following:

  • Setting the screensharing frame rate lower. I already have this set to min: 1. I wonder if it can go lower? Again, even one readable frame ever few seconds would allow us to help. (Students don’t type that fast.)
  • Disabling multicast. We really don’t want that low-quality stream.

Any other suggestions? Does that choice of encoder matter here? Or are there other settings that we could tweak to better support our use case?

Thanks in advance! Jitsi’s an incredible tool.

Hack rather than a fix: if they are sharing code, could you install etherpad and they paste the code there, rather than trying to share their screen?

Thanks for the idea! I think that this is probably more friction that we want. We already have a forum where we can help students this way. Part of the goal of our Jitsi integration is to allow us to peer “over the students shoulder”, so it’s also valuable to watch them interact with the editor, run the test suites, etc.

I really wish Jitsi would integrate something that allowed my staff to annotate a student’s screen. I don’t think that Etherpad does that, correct? (I’ve heard about something called Etherdraw, but IIRC it doesn’t do overlays…)

PS: when screensharing works and is readable, the system works really well. So if we can just fix this issue I think we’ll be all good.

I’m going to test the simulcast disabling today and see how that goes. I have high hopes for that tweak.

Posting to follow, I’ve been considering the same sort of thing for doing “virtual board games” - we’d need a way to say, “Please send the full resolution frame, I don’t care how long it takes, I only want full resolution transmitted.” For that case, you’d want to be able to specify “full resolution only” on a webcam stream (as well as the screen sharing feed relevant here).

I think dropping the frame rate down that far might violate some of the webrtc assumptions, but I also expect it would work in most cases… decoders tend pretty tolerant.

It seems like an “advanced settings” interface would be useful - it would allow disabling simulcast, forcing full resolution, etc. There are a lot of new use cases that are being explored during the shutdown!

1 Like

I’m also posting to follow, as I would like to see developments with this. We are using Jitsi Meet to do live coding workshops. We spend quite a bit of time looking at the IDE, so yah, same problem. The screen share is not very clear and some people can’t read the code, which is a big problem. I would like to have the ability to at least allow the presenter (or admin of the conference room) to be able to bump up their stream resolution or something along those lines.

1 Like

I’m not sure if anyone from Jitsi core is following this thread. But it would be great to address this.

I read somewhere that another WebRTC solution addressed this by not using the video channel—since apparently it was too hard to adjust the video encoding parameters properly—and instead periodically sending snapshots of the screen down a data channel. This seems like something that Jitsi could support but it would probably require a fair amount of hacking in both the client-side library and possibly on the video bridge. (I don’t know if it will distribute messages sent to data channels to all connected clients or not.)

I also have a hunch that this is how Zoom works, but with an interesting twist. I was on a video call recently with a student who was sharing their screen. The screen sharing was sharp, but not smooth, in the sense of as they navigated the editor we’d see a whole update all at once, rather than the intermediate frames. This was fine for what we were doing and definitely better than it just being too blurry to read always.

But the interesting twist was that the mouse moved smoothly and continuously :slight_smile:. So I wonder if Zoom has an optimization to track the mouse position and update its position continuously even if the background behind it is not being updated. I guess this might give the appearance of the screen share being more interactive, and is probably a good optimization for things like slide shows where you might want to move the mouse to highlight content. But on our call the dissonance between the mouse and the actual IDE content was just kind of weird…

1 Like