> The fix was embarrassingly simple: once you fall back to screenshots, stay there until the user explicitly clicks to retry.

There is another recovery option:

- increase the JPEG framerate every couple seconds until the bandwidth consumption approaches the H264 stream bandwidth estimate

- keep track latency changes. If the client reports a stable latency range, and it is acceptable (<1s latency, <200ms variance?) and bandwidth use has reached 95% of H264 estimate, re-activate the stream

Given that text/code is what is being viewed, lower res and adaptive streaming (HLS) are not really viable solutions since they become unreadable at lower res.

If remote screen sharing is a core feature of the service, I think this is a reasonable next step for the product.

That said, IMO at a higher level if you know what you're streaming is human-readable text, it's better to send application data pipes to the stream rather than encoding screenspace videos. That does however require building bespoke decoders and client viewing if real time collaboration network clients don't already exist for the tools (but SSH and RTC code editors exist)