Converting 500 legacy training decks to video: what it actually takes

Converting one deck is a demo. Converting a library is a project, and it fails for different reasons.

Teams usually discover this after a successful pilot. The first deck looks good, the business case is approved, and then someone asks how long five hundred will take. Here is what changes at that scale.

Throughput is serialised at the GPU

Text-to-speech runs on CPU and parallelises freely. Lip-sync rendering needs a GPU, and a single card handles pages roughly sequentially. That asymmetry shapes the whole architecture: if you put TTS and rendering in the same serial queue, you waste most of the wall-clock time on a step that could have been free.

The correct shape is: TTS in parallel, lip-sync serialised per GPU, and a queue between them. Adding a second GPU should roughly double rendering throughput, which means the pipeline must be able to run more than one renderer without a global lock.

Cost per video is the number to model

Cloud avatar platforms bill per minute of output. That is rational for them, because every render consumes GPU time they pay for. But it means your cost scales linearly with volume forever.

Running your own GPU inverts the curve. You pay for the card once and the marginal cost of another video is electricity. The crossover depends on volume, but the shape of the argument is what matters: if you expect to convert hundreds of decks, or to re-render them as content changes, per-minute pricing is the expensive option.

Be honest about the second half of that sentence. Most libraries are not converted once. Compliance training changes annually. Product training changes quarterly. Re-render volume is usually larger than initial volume.

Retry must be page-level

At one deck, a failed render is an inconvenience. At five hundred, it is the dominant cost.

Two design decisions determine whether failures are survivable:

1. Retry only what failed. A pipeline that resets all pages when one fails multiplies your GPU spend by the number of failures. Page-level retry keeps the cost proportional.
2. Never charge for a failure. Credits should be held before a job starts and released in full if it does not complete. Anything else means paying for output you did not receive, at volume.

There is a third, less obvious one: a task that dies because the process restarted must not become undeletable. At scale you will have interrupted jobs, and if the only remedy is editing the database by hand, your operations team will hate the tool.

Re-render strategy beats initial render speed

Assume you will re-render. Design for it:

• Keep scripts stored and editable separately from rendered output, so a wording change does not force a full re-render.
• Re-render only edited pages.
• Keep per-page chapter markers stable across renders, so links into the video do not break.

A pipeline optimised purely for first-render speed tends to store only the final video, which makes every future edit a full rebuild.

What to measure before committing

• Seconds of GPU time per rendered page on your actual hardware
• Failure rate per page, and what fraction of failures are retryable
• Wall-clock time for a representative 20-page deck
• Cost per finished video, including failures and re-renders

Get those four numbers from a pilot on your own content before you size the project. Vendor marketing numbers are measured on easy decks.