Screen sharing captures a display, application window, or browser tab as a video feed and transmits it to other participants as a separate track alongside the camera stream. In WebRTC this is done via the getDisplayMedia API, which prompts the user to pick what to share and returns a MediaStream that is encoded and forwarded through the SFU just like any other track. The key difference from camera video is resolution and frame rate priority: a presentation needs sharp text at the cost of lower frame rate, while camera video prioritizes smoothness over resolution, so most SFU configurations apply separate encoding profiles to the two tracks. For live learning, screen sharing is the primary way an instructor demonstrates software, walks through a slide deck, or shows a live coding environment; learners may also share their screens to get help from an instructor. A practical nuance is bandwidth asymmetry: the sharer must upload a high-resolution stream while potentially also uploading their camera, which can saturate a typical home upload link and cause quality degradation on both tracks. Platforms address this by automatically reducing camera resolution when screen sharing starts. Screen sharing content is captured in the session recording and should be synchronized with audio and any whiteboard annotations for coherent async playback.
The handbook · 7 volumes
Fora Soft Video Engineering Handbook
Screen sharing in a class sends code, slides, and small text, which blur fast when the stream is tuned for faces. We wrote seven volumes on the video stack; for screen sharing start with Volume 3 on WebRTC, real-time delivery, and QoE monitoring, with codec and bitrate choices in Volume 1 and voice processing in Volume 4. Written by Nikolay Sapunov, CEO at Fora Soft.
Is screen sharing in your live classes too blurry to read code or slides?
We will check your WebRTC settings for screen content and send concrete changes to resolution, frame rate, and bitrate. 250+ video products shipped since 2005.
