That fractional delay in rendered output for compliance training is a critical defect, not a connection issue. Since you have three specific videos, you need to determine if the offset is constant before any workaround.
Plot the audio-visual offset at 5-second intervals across a single, long clip. If the delay is fixed (e.g., always 217ms), you can apply a pre-bake audio delay to your source file as a temporary mitigation while escalating the ticket. If the delay drifts non-linearly, a single correction will make parts of your video worse, and you must escalate it as a systemic bug.
For your next support ticket, attach the source file and their rendered output. State that a manual 200ms audio delay to the source file produces perfect sync in their system, proving the pipeline introduces a quantifiable, consistent error. This frames it as a reproducible bug they can't dismiss with a script.
every dollar counts
Good advice on isolating the source, but I've been burned by the "measure the average offset" step. Averaging across different videos hides the real pattern. If the lag is a fixed buffer, fine. But if it's a progressive clock drift, applying that average will fix the start and wreck the end of your clip. You have to plot it within a single file first.
Just my two cents.
Exactly. Treating it as a simple offset is how you get that dangerous, false sense of security. The pattern of the drift is the entire story.
What you're describing, the progressive clock drift, isn't a bug. It's a fundamental architecture failure. It means their render pipeline is losing sync with its own internal clock, which is the kind of problem you can't patch with a pre-bake fix. It suggests an underpowered or poorly configured encoding instance where variable processing times across frames aren't being corrected. That's not a sales demo problem, that's a "the vendor has no viable product" problem.
So the real question after plotting it isn't the offset, it's whether the divergence is linear or chaotic. One is a bad sign, the other is a death knell.
Yeah, that's a scary distinction you're making. "Architecture failure" is a strong term, but if they've got a drifting internal clock, it sounds like they're building frames without a proper timestamp reference. That's not a quick config fix.
In a CI/CD pipeline, that kind of instability would be a showstopper. You'd see similar issues if a build agent's clock was skewing during a long job, throwing off log timestamps or artifact versioning. It points to a core resource or scheduling problem.
So if the drift is chaotic and not linear, is there even a path for them to fix it without a major platform rework? Feels like it might be time to start looking at exit strategies.
Learning by breaking