Screen Sharing

General definition

Screen Sharing captures pixels from a display surface and sends them to other participants as video. In the browser this is the W3C Screen Capture API: a page calls navigator.mediaDevices.getDisplayMedia(), the browser shows its own picker for the user to choose a whole screen, a single window or a tab, and the call resolves to a MediaStream with a video track and, on some platforms, an audio track for tab or system audio. That track is then added to a WebRTC peer connection exactly like a camera track, so the rest of the media pipeline needs no special case for it.

Screen content behaves differently from a face on camera. A slide or a code editor is mostly static with sharp text; a video playing in a shared window is all motion. The MediaStreamTrack Content Hints specification lets the app tell the encoder which matters by setting contentHint on the track: detail or text favour resolution and let the frame rate drop, while motion keeps frames flowing at lower resolution. Browsers also accept a displaySurface preference and may expose the chosen surface type so the app can pick a sensible layout.

• Permission is per session and per choice: the page cannot pre-select a screen or window, and the user can stop sharing from a browser control at any time
• Mobile browsers largely do not support getDisplayMedia; native apps use ReplayKit on iOS and MediaProjection on Android, both of which show a system prompt before capture starts
• A shared screen is usually sent as one high-resolution layer at a low frame rate, so it costs less bandwidth than it looks but stresses the encoder on large monitors
• Through an SFU, screen share is simply another published track that each subscriber can pick up or ignore, and simulcast layers can be added when viewers vary widely in bandwidth

Privacy is the main operational risk. A shared screen can expose notifications, other tabs, patient records or account numbers to everyone on the call, which is why regulated teams prefer sharing a single window or tab over a full display, brief users before a session, and treat any recording of a shared screen as sensitive data with the same retention and access rules as chat history.

In the Ethora ecosystem

Ethora’s voice and video calls are built on WebRTC with an SFU media server, and screen sharing in that architecture is a standard WebRTC video track: a client captures a display surface with the platform API and publishes it to the same session as its camera and microphone, and the SFU forwards it to the other participants without re-encoding. Because the media stack is standards-based, the browser picker, content hints and stop-sharing controls behave the way they do in any WebRTC application.

For support and telehealth products the point is that screen share lives inside the same authenticated room as chat and calls, on infrastructure you can run in your own cloud account or on-premise, rather than in a separate consumer meeting tool. The voice and video call API page describes the calling features that ship in the SDK today; check with the team about screen-share requirements for your platform mix, since mobile capture depends on native OS APIs.