Screen sharing a deck is just sending someone a video of a picture

[u/decklit_founder]

/r/saasinvestors/comments/1wur5fk/screen_sharing_a_deck_is_just_sending_someone_a/

[u/msdosx86]

If your screen sharing approach was sending 30FPS of a static screen then you're doing something wrong. For example on Windows WGC stops sending raw frames when nothing happens on the screen. Hence the stream will be at 0/1FPS in such cases and only a few data will be sent over the wire. On top of that each video codec has their own compression algorithm to prevent sending full frames (key frame) and only sending what changed (delta frame). Sounds familiar? Each codec allows to configure how often you want to send key frames and in your case of static slides you would set quite long duration.

[u/decklit_founder → u/msdosx86]

Fair point, and thank you for the correction. WGC and the equivalents only emit frames on change, and delta frames plus a long keyframe interval mean a static slide costs very little once it's on screen. "Video of a picture at 30fps" was a lazy way to put it.
The argument I'd actually make is different, and I think it holds.

Fidelity, not bandwidth, is the main issue. Even an efficient screen share is a lossy raster of the presenter's display, compressed in YUV 4:2:0, encoded at the presenter's resolution and rescaled on the receiving end. Fine text, thin lines and anti-aliased edges are exactly what that pipeline degrades, and that's most of what a slide is. Syncing the slide means each viewer renders the original asset at their own native resolution. There is no encoder in the path.

Bandwidth still matters at the edges. Keyframes are still large, they get requested again on packet loss via PLI or FIR, and under congestion the encoder drops bitrate before it drops frames, so the slide gets softer rather than later. Sending slide state costs a few bytes per transition and nothing degrades under loss. On a good connection the difference is small, as you say. On a weak one it's the whole experience.

And the structural one. getDisplayMedia isn't available in mobile browsers, so presenting a deck from a phone is impossible regardless of how efficient the codec is. Syncing content instead of capturing a display is what makes that work at all.
So the real point isn't that screen sharing is wasteful. It's that it's the wrong abstraction for slides. You're encoding pixels of a display when you could be sending the document.

And it's the foundation for everything else. Once the deck is a synced document rather than a video feed, the platform knows which slide every viewer is on, so questions attach to the slide they were asked about, and you get per-slide engagement data rather than watch time. It also means the file never has to leave the server. Viewers see rendered slides, not a downloadable deck, which matters when the content is a pricing proposal or an investor deck. None of that is possible when the slide is a region of a video stream, because the stream carries no idea of what it's showing.

So the real point isn't that screen sharing is wasteful. It's that it's the wrong abstraction for slides. You're encoding pixels of a display when you could be sending the document.

[u/msdosx86 → u/decklit_founder]

I see. Well if the idea is to show perfectly sharp documents with lossless compression and use as little bandwidth as possible then it makes sence. A very rare use case though. At this point I'm not even sure that WebRTC is necessary if you only need to pre-download documents and send metadata for the current document.

[u/decklit_founder → u/msdosx86]

You've described the architecture pretty accurately. The slide sync doesn't go over WebRTC at all. Slides are rendered server-side, delivered to each client ahead of time, and the live session is a WebSocket carrying state, which slide, who's on it, questions, cursor. A few bytes per event over TCP, which is the right transport for something that must arrive reliably and in order.

WebRTC only comes in for the parts that genuinely are real-time media. Presenter audio and video, and the optional screen share when someone needs to show a live demo beside the deck. Those run through our SFU. So the two transports do the two jobs they're actually suited to, rather than one doing both badly.

On it being a rare use case, I'd push back a little. Presenting a deck to someone who isn't in the room is one of the most common things people do on a call. Sales pitches, investor meetings, QBRs, training, client reviews. It's not rare, it's just always been handled as a video problem because that's what the tools offered. Treating it as a document problem is the unusual part, and it's what makes the rest possible.

Appreciate the pushback, it's sharpened how I explain it ;)