How to turn a PowerPoint deck into a narrated presenter video
A practical walkthrough of converting a slide deck into a video with a presenter narrating it — what the pipeline looks like, where quality is won or lost, and how long it takes.
Most teams that want video versions of their training decks already have the hard part done: the content. What they lack is a way to get from a finished deck to a finished video without booking a studio, briefing a presenter, and re-recording every time a number changes.
Here is what that conversion actually involves, and where the quality is decided.
The pipeline, end to end
1. Render each slide to an image. The deck is rasterised page by page. This matters more than it sounds: rasterising preserves charts, tables and diagrams exactly as authored. Approaches that try to reconstruct slide content from the XML lose layout, and a slide that has been visually mangled is worse than no video at all.
2. Extract the text layer. The text is pulled out separately so the narration can be grounded in what is actually on the slide, rather than invented. Pages where text extraction fails should fall back to visual description, not to silence.
3. Draft a script per page. A language model reads the extracted text and proposes narration. The critical design decision here is that the draft must be reviewable before rendering. Language models are fluent and frequently wrong; a script that confidently states something your slide does not support is worse than no narration.
4. Synthesise the audio. Text becomes speech using a built-in voice, or a voice cloned from reference audio on self-hosted deployments. Audio length is the master clock for the page — everything downstream is cut to it.
5. Generate lip-sync. A digital presenter’s mouth movement is generated frame by frame from the final audio. Head pose, body and background come from a short source clip you registered.
6. Encode. Each page becomes a clip, pages are stitched, and per-page start and end offsets are recorded so the finished video can be navigated by slide.
Where quality is actually won
Presenter source footage dominates the result. The requirements are narrow and unforgiving: frontal, evenly lit, no occlusion, roughly 8 to 30 seconds. A clip shot at an angle under mixed lighting will produce visible artifacts no matter how good the lip-sync model is.
Script length per page is the second lever. Narration that runs long against a short presenter clip forces the renderer to either truncate — losing content — or loop the footage — repeating the same head movement. Both look broken. The fix is upstream: constrain the script to what the audio window can hold, and warn the author when it does not fit.
Audio length should drive the cut, never the reverse. If your renderer derives page duration from the video and then attaches audio, mismatches become silent truncation.
What it costs in time
Text-to-speech is fast and parallelises on CPU. Lip-sync is the bottleneck: it needs a GPU, and it is roughly serialised per device. A 20-page deck is minutes of TTS and tens of minutes of rendering on a single GPU. A 500-deck library is an overnight job on one card, or a short job on several.
This is the reason batch throughput matters more than single-video speed for this use case. Nobody is converting one deck.
What to check before you publish
- Play the audio for proper nouns and technical terms. Synthesisers get these wrong often.
- Confirm the last page is not truncated. If the renderer cut to the video instead of the audio, the final slide loses its ending.
- Confirm every page’s script says something the slide supports.
Do those three things and the output is publishable. Skip them and you will ship something that looks finished and is quietly wrong.