Need help : Constant audio desync after upload (perfect locally)

[-Tetsuo-]

Hello,I’m dealing with a very stubborn audio/video sync issue.

Symptoms:

• The video is perfectly in sync locally (VLC, PC players, YouTube on desktop).
• After uploading (YouTube + other platforms), a constant offset appears (audio is delayed).
• The desync is especially noticeable on mobile and on files downloaded from the platforms.
• It is not progressive drift — it’s a fixed offset.

What I’ve already tried without success:

• Spectral analysis (Spek, Adobe Audition, iZotope RX Spectral Recovery) → cutoff around 12,141 Hz
• Conversions forcing the original sample rate to 24,000 Hz, 22,050 Hz, 22,500 Hz, then high-quality resampling to 48 kHz (SoX high precision)
• Forcing Constant Frame Rate
• Cleaning timestamps (asetrate, asetpts, video_track_timescale, etc.)
• Different H.264 profiles (baseline, main…)
• Re-capturing audio via OBS loopback at 48 kHz
• Mono versions

I’ve uploaded dozens of other videos without ever encountering this problem, so I believe the cause lies in this particular source (history of conversions + very limited bandwidth). Has anyone encountered a similar case and found a definitive fix on the source file side?
Thank you in advance.

[Selur]

maybe this helps:

• make sure the video is cfr
• if the audio isn't 44.1 or 48kHz
• if the container contains:
  • Chapters: Make sure the chapter times are correct (non before the video starts or after the video ends)
  • Subtitle: Make sure the subtitle times are correct (non before the video starts or after the video ends)
  • Stretch infos: reencode audio/video to make those unnecessary and remove them.
• If the audio has a fixed delay, reencode the audio and add the delay, so that the resulting file has no delay.
• If you use mkv or mp4 as container.

Cu Selur

[rgr]

Post sample.

How did you create this file?

[johnmeyer]

Drop the video onto Mediainfo and post what it reports.

You didn't mention the length of the offset. Was it ten seconds? 1/4 second? If it is short, it could have something to do with the offset until the first I frame. It will be interesting to see what codec was used.