WebRTC getDisplayMedia: How Video Frames Are Captured, Transcoded & Transmitted in Chromium
Step-by-step trace of WebRTC getDisplayMedia() in Google Chrome, Edge, and web conferencing platforms. Frame capture, downsampling, and network encoding.
Google Meet, Slack Huddles in browser, and web-based Zoom rely directly on the W3C WebRTC navigator.mediaDevices.getDisplayMedia() specification. Tracing the browser's internal capture pipeline demonstrates why web apps cannot detect excluded windows.
The JavaScript W3C getDisplayMedia() Spec
When a web page invokes getDisplayMedia(), the browser requests permission from the user and hands off frame acquisition to the operating system's native capture subsystem.
Chromium DesktopCaptureDevice Architecture
In Chromium source code (media/capture/content/desktop_capture_device.cc), the browser instantiates a platform capturer: DesktopAndWindowCaptureFrameSource. This invokes ScreenCaptureKit on macOS or DXGI Desktop Duplication on Windows.
Hardware Transcoding: VP8, VP9, H.264 & AV1 Pipelines
Frames delivered from the OS compositor are converted to YUV420 color space, encoded using hardware encoders (Apple VideoToolbox or Intel QuickSync / NVIDIA NVENC), and transmitted over SRTP RTP streams.
Why Browser-Based Exclusion Detection Is Impossible
The web application's JavaScript sandbox only receives an opaque MediaStreamTrack. It cannot inspect desktop z-order, list running processes, or detect windows that were excluded by the OS compositor before reaching the encoder.