If FFmpeg audio and video are out of sync on a Hetzner-hosted YouTube stream, first determine whether the mismatch is a steady offset or grows as the stream runs. A fixed offset and accumulating drift point to different checks; the provider name alone does not identify the cause.
Compare the stream close to its start and again later, then check whether the same mismatch exists in FFmpeg’s local output and YouTube playback. That gives you a basis for testing source clocks, timestamps, delivery and playback one at a time rather than changing encoder settings at random.
Identify where the sync problem appears
Begin by locating the symptom. If you have a local recording of FFmpeg’s output, compare it with YouTube’s Live Control Room preview and, when available, the resulting playback. Use a recognisable event: a person clapping, a spoken word that matches a visible mouth movement, or a sharp sound paired with a clear action. Avoid judging sync from background music over a static image, where the timing is harder to assess.
If local output and YouTube both show the same mismatch, look first at the input sources and FFmpeg’s treatment of them. If the local recording looks aligned but YouTube does not, leave the timestamp filters alone for the moment. Check the ingest status and playback path, and repeat the test with representative movement and sound. A preview or player can behave differently from the local file, so record what you observed and where.
Keep the comparison fair. Use the same clip or live segment, and note whether the audio leads or trails the corresponding action. A spoken word arriving after the speaker’s mouth moves is different from sound arriving first. That direction matters when you later test a shift. If you use a playlist or loop, ensure the comparison is not crossing a file boundary or a deliberate transition. For context on preparing a continuous file-based stream, see this guide to choosing a format for a 24/7 YouTube live stream.
Write down the result before changing anything: where the test was viewed, what event you used, which medium appeared early, and roughly how far apart they were. Do not publish or share a stream key with logs. Redact it from any command line, screenshot or support message; the key is a credential, not a diagnostic detail.
Measure whether the offset is fixed or growing
A single observation tells you that sync is wrong, but not what kind of correction to investigate. Compare two or more matched events separated by a meaningful interval. Record which one leads and an approximate displacement at each point. A similar lead at the beginning and later suggests a mostly fixed offset. A lead that steadily increases, decreases or changes direction suggests a timing-rate problem or a discontinuity. If the mismatch suddenly jumps, note when; that is not the same pattern as smooth drift.
You do not need laboratory equipment for an initial diagnosis. A short test containing a visible clap or another sharp, well-defined event can make the relationship easier to compare. Use the same event in a local output recording and in YouTube playback, and write down the time in the programme as well as the observed timing difference. Treat the measurement as approximate: a browser, display or audio device can introduce its own delay. Repeat the check before making a change.
Think of the mismatch as a pattern, not as a verdict. A constant offset is compatible with one stream starting earlier than the other, but does not prove why. Growing drift is compatible with independent clocks or samples progressing differently from their timestamps, but does not prove which source is responsible. A sudden jump may align with an interruption or timestamp reset. These are leads for the next checks, not conclusions.
Preserve a baseline: the exact FFmpeg command with secrets removed, the FFmpeg version, relevant startup and runtime log lines, input types, and the two observations. Note whether audio and video come from one media file, one capture device, or separate live sources. Change one setting per test and compare against this baseline. If you modify several filters at once, a better result will not tell you which change mattered.
Check source timestamps and shared capture clocks
Find out how each input is produced. A video file with its audio track normally carries both streams in one media timeline. Separate microphones, cameras, capture cards or network feeds may each report timestamps against a different clock. FFmpeg’s documentation cautions that expected results for synchronising inputs depend on their timestamps deriving from the same clock source. If two live sources have independent clocks, a small timing-rate difference can accumulate even when both appear correctly aligned at the start.
Inspect the input metadata and logs rather than assuming that a nominal frame rate or sample rate proves correct timing. ffprobe can help you examine stream start times, time bases, frame rates, sample rates and packet timestamps. Those fields are evidence to interpret, not a simple pass/fail score: a time base describes timestamp units, while the timestamp sequence shows how media is placed on that timeline. Compare the reported progression with the real capture behaviour where possible. For basic command and output context, consult the FFmpeg documentation and its ffprobe documentation.
For a source made from separate devices, check how they are connected and whether the capture software supplies a common clock or synchronises them. Inspect logs around the point where drift begins or jumps. A capture reconnect, missing packets, a stalled device or discontinuous timestamps could change the relationship between streams. Do not reset timestamps broadly just because the values look unfamiliar: you could hide the point at which the source actually changed timing.
For a single pre-recorded file, verify that the file itself plays in sync outside the live pipeline. A problem already present in the source should be corrected at the source or in a controlled conversion, not attributed to the Hetzner host. If the material is assembled from multiple clips, check joins and transitions as well as the middle of each segment. A loop that appears fine in one clip can still expose a mismatch at the next boundary. A workflow that plays files in filename order with FFmpeg can help you reason about the sequence, but ordering does not itself correct timestamp alignment.
Inspect FFmpeg audio and video timing
Next, inspect the FFmpeg command for options that affect timestamps, frame cadence or audio resampling. Keep a copy of the original command and remove the stream key before sharing it. Check where input-specific options sit in relation to their input, and read the log for warnings, dropped or duplicated frames, reconnects and timestamp discontinuities. A command copied from another setup may target a different input arrangement, so do not add a filter merely because its name sounds relevant.
Video sync modes are not interchangeable fixes. FFmpeg’s fps_mode choices include passthrough, which keeps demuxer timestamps; constant frame rate (CFR), which duplicates or drops frames to meet a requested rate; and variable frame rate (VFR), which passes timestamps or drops frames with duplicate timestamps. If source cadence is irregular, forcing CFR can alter the video sequence. It does not, by itself, correct audio clock drift. Choose a mode only after checking the source cadence and intended output. FFmpeg documents these behaviours in its video options reference.
Compare the media’s actual characteristics with the output settings you have requested. Look for conversions, frame-rate forcing, audio sample-rate changes and any filters that can alter timing. An output may be playable even when its timestamps do not reflect the source’s real-time progression. Logs and a local recording help distinguish a repeatable timing pattern from an occasional encoding or capture interruption.
YouTube’s encoder guidance is useful for checking delivery configuration, but it is not a sync diagnosis. Its current recommendations include RTMP or RTMPS ingestion, up to 60 fps, a recommended two-second keyframe interval (not over four seconds), AAC or MP3 audio, and CBR. These are platform guidance, not reasons to force a particular audio or video filter. Confirm the current requirements and bitrate table on YouTube’s live encoder settings page before relying on a setting.
Test delivery and YouTube playback separately
A timestamp mismatch and a delivery disruption can look similar to a viewer, but they are different problems. Check Live Control Room’s stream health and messages during the same period you are measuring. Then compare them with FFmpeg’s runtime log and, if possible, a local capture. If the local file is smooth and aligned while the stream health shows interruptions, investigate network delivery and ingest before changing timestamps. If the local file contains the same growing drift and delivery is stable, the evidence points back towards source timing or FFmpeg handling.
Measure the actual outbound capacity available to the Hetzner instance and region; do not infer it from the provider name or a plan label. Add the primary and backup stream bitrates if both are being sent, then compare the total with observed upload capacity. YouTube recommends leaving 20% headroom beyond the stream bitrate. This is a bandwidth margin, not proof that the network caused an audio offset. Its streaming tips explain the headroom recommendation and advise monitoring the stream.
For bitrate and picture-quality decisions, refer to the current YouTube table and a separate live streaming bitrate checklist. Do not lower or raise bitrate to fix a stable timestamp offset without evidence of delivery trouble. RTMPS can protect the connection in transit, but switching transport does not synchronise audio samples to video timestamps. YouTube provides RTMPS setup instructions; treat that as a connection-security choice rather than a timing filter.
Also compare playback conditions. Test the Live Control Room preview and a viewer playback on a second device or browser if practical. A display or audio route may add a constant delay that is absent in the encoded output. If only one playback path is affected, note it and avoid compensating in FFmpeg for a delay that is local to a listener’s device.
Apply a measured offset or correct drift
Choose a remedy to match the measured pattern. For a nearly constant displacement, first confirm which input is early and how far apart the matched events are. FFmpeg’s -itsoffset shifts input timestamps; a positive value delays the relevant input. Its position in the command matters because it applies to an input, not as a generic output correction. Consult the FFmpeg input options reference, make a controlled test using your measured value, and compare the same event at the beginning and later. Do not copy an arbitrary delay from someone else’s setup.
If the displacement grows over time, a simple fixed shift may make the start look better while leaving the end wrong. Check whether audio sample progression follows its timestamps and whether audio and video share a clock. FFmpeg’s aresample filter can stretch or squeeze audio, or add or cut samples, to match timestamps. That capability is a tool for a confirmed sample/timestamp mismatch, not a blanket cure for separate-clock sources. Compensation can affect the sound, so test a short representative segment and listen for unwanted changes before using it on a continuous stream. See the FFmpeg resampler filter documentation.
If the observations show jumps rather than smooth drift, investigate the source or the timestamp discontinuity at the time it occurs. Find which input changes, then address that interruption or capture behaviour. Broad timestamp resets or resampling may obscure the symptom without repairing its source. If frame cadence is irregular, test the sync policy against the input’s real cadence; CFR may add or drop frames, while passthrough preserves timestamps. Keep the original command so you can revert if the new behaviour is worse.
Run one change at a time. Make a private or unlisted test where appropriate, use a clear sync event, and compare both the initial and later points. Keep the change only if it improves the measured relationship without introducing audio or frame artefacts. If there is no clear improvement, undo it and return to the evidence: source clocks, timestamps, logs, delivery status and playback path.
Verify sync over a sustained stream
A short test can confirm that a correction addresses the pattern, but an always-on stream needs a longer observation. Repeat the same kind of sync check after the stream has run for a while, including after a loop or file transition if your channel uses one. You are checking whether the relationship stays stable, not proving that it can never change. Keep notes for each observation so a later change can be compared with the baseline.
Monitor FFmpeg’s logs and YouTube’s stream-health messages alongside the playback. If sync changes after a reconnect, a source transition or a process restart, note the event and time. That information can distinguish an accumulating clock mismatch from a one-off discontinuity. Save the working command and the input details, but store stream keys securely and never include them in shared logs.
YouTube advises testing before a live stream with audio and video movement similar to what the actual programme contains. For a devotional channel, that might mean a voice or bell with a visible performer; for a lofi station, use a deliberate visual/audio marker in a test file rather than trying to judge sync from a static cover image. The point is to test the timing your viewers will encounter without making an unsupported promise about perfect alignment.
If the repeated work of keeping an FFmpeg process running on a host, checking interruptions and restarting it is the practical problem you need to remove, StreamNeo can take an uploaded video and run it as a YouTube live stream while your computer is off; that addresses operation, not an existing timing fault in a source file.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How can I tell whether the audio delay is fixed or drifting?
Compare a matched audio/video event near the start with one later, and record which medium leads and by roughly how much. A similar displacement suggests a fixed offset; a consistently growing or shrinking gap suggests a timing-rate mismatch. A sudden change is a separate clue to investigate in the logs and source.
Will adding -itsoffset fix every FFmpeg sync problem?
No. It shifts input timestamps and is relevant when you have measured a stable offset. It will not necessarily correct accumulating drift or an interruption that changes timestamps during the stream.
Should I use aresample when audio and video drift apart?
Only after checking whether audio samples are progressing in line with their timestamps and whether the sources share a clock. The filter can adjust audio to match timestamps, but applying compensation without evidence can affect the sound or mask another problem.
Does hosting on Hetzner mean the server is causing the mismatch?
The provider name alone does not establish a cause. Compare local FFmpeg output with YouTube playback, inspect source and runtime timestamps, and check delivery capacity and stream health before deciding which part of the chain needs attention.