When a presenter shares their screen and plays a video, the video signal travels through a path it was never designed for — screen capture, compression, transmission, decompression — and long videos collapse under that weight. Reviewers described this exactly: 'long videos during meetings never work,' 'if a video is very long it doesn't load properly.' This isn't a bug in any one product. It's a structural mismatch between how screen sharing encodes motion and what smooth video playback actually requires.

Conferencing vendors won't fix this because fixing it properly means rebuilding part of their media pipeline specifically for video-within-video, which is expensive and benefits a minority of users. Their incentive is to ship a general-purpose screen share, not optimize for the presenter who needs to play a 10-minute product demo.

What's needed is something that intercepts the video file before it hits the screen share path and delivers it directly to attendees as a synchronized stream — so what attendees see isn't a screen-captured version of a video playing on the presenter's desktop, but the actual video file delivered cleanly, with the presenter retaining control over play/pause/scrub. The presenter's screen share stays active for everything else — slides, speaker face, Q&A — but video segments route differently.

This is structurally awkward to build inside a conferencing product because it requires the vendor to treat 'video playback' as a first-class content type separate from screen share, which breaks their existing architecture. An independent layer that sits between the presenter's file and the meeting has no such constraint.

This is a business because every recurring webinar program with product demos, training videos, or customer testimonials hits this ceiling. Marketing teams abandon video in their demos. Trainers strip clips from their courses. The workaround — 'share the link and have attendees watch separately' — breaks the live experience entirely and kills the presenter's ability to control pacing.

What to build

Build a desktop app that presenters run alongside their conferencing tool, which detects when a video segment begins, uploads the file to a CDN on the fly, and pushes a synchronized playback URL to all attendees so video is delivered as a direct stream rather than through the screen share pipeline — with presenter-controlled play/pause broadcast to all viewers.

Where to start

Target sales engineering teams at SaaS companies whose product demos include recorded feature walkthroughs — they have a clear, dollar-valued reason to fix this (a broken demo in a late-stage deal is a concrete revenue risk), they're technical enough to adopt a desktop app without IT approval, and they run the same demo video repeatedly so the fix compounds.

The hard part

Getting attendees to receive and play a synchronized stream without requiring them to install anything or leave the meeting window is technically hard — a purely browser-based push that works across corporate firewall configurations and locked-down enterprise environments is the first painful constraint to solve.

How it makes money

Monthly subscription per presenter seat at $30–50/month; free 14-day trial with no attendee cap to let teams prove it works before paying.

See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Video Conferencing.

More ideas in Video Conferencing