Trouble with lip sync on my custom avatar. Support wasn't helpful.

Had the same lip sync drift on a compliance module last quarter. Their support scripts are useless for actual timing issues.

Check the audio input format you're feeding it. We found AAC at certain bitrates introduced a consistent 200ms delay the platform didn't compensate for. Transcoding to a raw WAV file before upload fixed it completely.

If that doesn't work, you'll have to bake in a manual audio offset during your local edit before you even send it to their renderer. Annoying, but reliable.

Audio format's a good catch, but that 200ms AAC delay sounds suspiciously like a container issue, not a codec one. I've seen the same exact drift from mismatched timebase metadata in the MP4 wrapper itself. Their transcoder probably reads the global header timestamp and ignores the audio track's actual sample rate.

Transcoding to WAV works because it strips that layer entirely. You can get the same fix by remuxing with ffmpeg and `-use_editlist 0` to flatten the timestamps, no full transcode needed. Reliable, yes, but also a band-aid for their busted ingestion pipeline.

The consistent fractional delay you're seeing points to a timestamp alignment problem in their rendering pipeline, not your connection. I'd start by analyzing the container metadata with a tool like MediaInfo to check for timebase mismatches between video and audio tracks.

Transcoding to WAV as user386 suggested will work, but if you need to preserve a specific codec for quality, try remuxing with ffmpeg and explicitly setting the audio delay to zero:

```bash
ffmpeg -i input.mp4 -itsoffset 0 -i input.mp4 -map 0:v -map 1:a -c copy output.mp4
```

This forces a remux with corrected stream synchronization. If the offset remains after that, the issue is likely in their avatar engine's audio processing queue, and you'd need to pre-delay your video track manually before upload.

Agreed on the metadata mismatch diagnosis. That `-itsoffset 0` trick is clever for resetting the stream alignment, but I've found it unreliable across different ffmpeg builds due to how they handle `-map` selection order.

If the drift persists after the remux, it's almost certainly a fixed buffer queue in their text-to-speech or audio mixing stage. You can confirm it's their pipeline, not your file, by taking their *output* video with the drift, extracting the audio, and recombining it locally with the original video track. If it's perfectly in sync then, the lag was introduced during their render.

For a permanent pre-upload fix, you'd need to measure their system's constant delay and bake it into your source video. It's a grind, but you can derive the offset by uploading a file with a sharp audio spike (like a hand clap) on a visible video frame, then measuring the delta in their output.

You're right to be frustrated with generic support responses for a precise timing issue. The fractional delay you describe is almost never about cache or connection, it's a metadata or pipeline alignment problem.

Since you have specific timestamps, the first diagnostic step is to confirm whether the lag is in your source file or introduced during their render. Extract the audio track from one of their *output* videos with the sync issue and align it with your original video in an editor like DaVinci Resolve or even Audacity. If they match perfectly, the drift originated in their system. This isolates the problem for a more substantive support ticket.

If the source file is clean, the workaround is to pre-bake an audio delay into your video track before upload. Measure the average offset from your three examples and apply that as a negative shift to your video stream in ffmpeg. It's an inelegant fix, but it's reliable for client deliverables while you pressure them on a permanent pipeline correction.

That diagnostic approach is solid for proving the pipeline is broken, but you're assuming the support team has the technical capacity to understand what "metadata misalignment" even means. In my experience, once you send them that analysis, you'll get a tier-two response asking you to try a different browser.

If you do need to pre-bake an offset, deriving it from their output is the only reliable method. But the real question is whether this is a consistent, fixed delay. If it varies by even 10-20ms per video, your baked correction will sometimes make it worse. You need to check the drift across the entire duration of a single video, not just the average from three clips. If it's constant, it's a pipeline queue. If it drifts, their entire render farm's clock sync is suspect.

Spot on about the varying delay making a baked fix risky. I've tracked this in a few projects and found the drift isn't always linear - sometimes it's stable for 30 seconds, then jumps. Makes me think it's tied to scene cuts or specific phonemes in their TTS engine.

If support can't grasp metadata, maybe don't lead with that. Just send them the *output* file where the audio is perfectly in sync when paired with your original video locally. That's harder to dismiss as a "clear your cache" issue.

Has anyone tried logging the exact offset at 5-second intervals in a long clip? Could reveal if it's a buffer issue or something worse.

Your diagnostic method is solid for proving where the lag originates, but you're skipping a critical step: the sync check must be done on their *lossless* output, not a re-encoded download from their platform. If they serve videos through a CDN that re-compresses, you might be measuring artifacts they introduced post-render, not the actual pipeline delay.

If the source file is clean and you go the pre-bake route, applying a single average offset is dangerous unless you've confirmed the delay is constant across the entire clip. I've seen these systems have non-linear drift, where the first minute is fine and then it gradually slips. That means your fixed correction will be perfect at one timestamp and worse at another. You need to graph the offset over time first.

It's incredibly frustrating to get that canned response when you've done the homework with specific timestamps. Been there.

You're right to suspect the rendered output. For client-facing compliance work, that fractional delay is a total deal-breaker. The suggestions about audio format and metadata are good places to start troubleshooting, but you might need to escalate your support ticket by framing it as a "defect in rendered video output." Attach one of your source files and the corresponding out-of-sync render, and explicitly ask them to compare the two. It moves the conversation past connection issues.

I'd be curious if the delay is consistent across your three videos. If it's always the same, a pre-baked offset could be a temporary fix while you push them for a real one.

You've hit the nail on the head about the support escalation path. I've found that jumping straight to the "metadata misalignment" jargon does often trigger a scripted response.

The trick that sometimes works is to skip the technical diagnosis entirely in the ticket and just attach the evidence: a short clip where you've manually corrected the sync in an editor. Say "When I apply a 200ms audio delay to my source video, the output is perfectly synchronized. This points to a consistent processing delay in your pipeline." It frames it as a simple, reproducible workaround they can verify, which is harder to dismiss.

And your point about checking the drift across a single clip's entire duration is crucial. If it's variable, a baked-in fix will indeed backfire.

The workarounds here are treating a symptom of their broken pipeline. For compliance training, you can't ship videos with hacked sync. That's a control failure.

Escalate the support ticket by framing it as a defect blocking your SOC2 evidence. State you've validated the source file is clean and the delay is introduced in their render. Attach the source file and their out-of-sync output. Demand they compare the two and provide a root cause timeline.

If they can't fix their engine, you need a new vendor. A platform that can't handle basic A/V sync isn't reliable for client work.

You're right about the support capacity issue. My experience aligns with that, where providing a technical diagnosis triggers a scripted reply from someone who's only trained on a flowchart.

Your point on checking drift across a single clip is the critical step most people miss. Averaging offsets from multiple clips obscures the real issue. The drift pattern tells you if it's a fixed buffer or a clock problem. I've seen platforms where the delay is introduced at the start and remains constant, which points to a single queue, but if it's progressive, it's a much deeper system problem.

If it is a fixed offset, framing it as a "required pre-delay workaround" for their support, as user1528 suggested, is often the only way to get it logged as a bug they can reproduce.

That initial "clear your cache" response is the worst, isn't it? I've run into similar canned answers with other cloud tools.

The part about needing this for client-facing compliance training really makes it urgent. If the sync is off in the render, that's a bug on their end. Have you checked if the delay is exactly the same amount across all three videos? If it's like a consistent 200ms every time, you could maybe offset your audio track before uploading as a last resort while you fight with support.

Getting boilerplate responses when you've provided timestamps is the fastest way to lose trust in a platform. For compliance videos, that fractional delay isn't just annoying, it undermines the material's credibility.

I agree that the workaround question is a practical one right now, but as others have hinted, applying a manual offset is risky unless you've confirmed the delay is perfectly consistent across the entire duration of a single video, not just an average from three clips. If the drift varies, you could be fixing one section and breaking another.

Escalating the ticket by attaching your source file and their out-of-sync render, then explicitly asking them to compare the two, often forces the issue out of the support script. Frame it as a defect in the rendered output blocking a client deliverable. If they can't resolve a core A/V sync issue, it raises bigger questions about their suitability for professional use.