Corey JamesScreen sharing through Teams' own path
Helix puts a digital employee in Teams meetings, and people wanted to watch it work: a browser page it was reading, a terminal it was typing into. I decided the employee would share a real screen through Teams' own screen-sharing path, with H.264 as the video format end to end. A headless Linux desktop (virtual display, window manager, Chromium, terminal) is captured and encoded by FFmpeg as an H.264 elementary stream. The employee can share a browser, a terminal or the whole desktop, and stop cleanly. Terminal text is typed at a pace people can follow, faster for long outputs so large updates finish.
desktop · FFmpeg · Rust
C# bridge · Teams
The rest of the meeting surface, from chat to the stage to raised hands, is the story A meeting attendee that will not fake it, and the media bridge itself is A self-hosted colleague in a Teams call.
Settings for text and for late joiners
I chose the settings for text on screen and for people who join late: a low output frame rate, zero-latency tuning, main profile, a short fixed group of pictures with scene-cut detection off, and access-unit delimiters with the stream headers repeated at every keyframe.
I picked a low frame rate on purpose, because the content is text and the bandwidth is better spent on sharpness.
The encoder is FFmpeg's x264 path used through configuration.
A frame contract between Linux and Windows
Between the Linux voice engine, written in Rust, and the Windows media bridge, written in C#, I defined a small frame contract that carries one H.264 access unit per frame. Frames are cut on access-unit boundaries, so the receiver never re-parses a byte stream to find them.
Illustrative sequence.
I can carry a media format from a Linux container through a Windows bridge into a vendor's platform and tune it for what the person watching needs. Teams' screen-sharing transport is Microsoft's platform, used as provided.