If audio matches the picture at the start of a continuous church YouTube stream but is off later, first work out whether the difference stays constant or grows over time. A fixed offset and audio drift that gets worse over time point to different diagnostic paths; neither symptom, by itself, identifies a universal FFmpeg fix.
Measure a recognisable sound against its picture at the beginning and again later, then preserve the command, version, source details and logs. Without those details, changing flags or buying equipment is guesswork.
Check whether the error is fixed or growing
Choose an event that is easy to recognise both in the picture and in the sound: a spoken word, a clap, or the start of a hymn. Compare the audio and video near the beginning of the stream, then repeat the observation after a known period. Note which arrives first and roughly how far apart they are. You do not need a laboratory measurement to establish whether the difference seems stable or is increasing; you do need to record the same kind of observation each time.
If audio leads or trails by about the same amount throughout, you may have a fixed offset. That suggests examining initial alignment, timestamps, and where the audio and video enter the command. Moving an entire stream’s audio earlier or later might be relevant to a stable offset, but it would not explain why the alignment changes over elapsed time.
If the sound begins in step and then increasingly leads or trails, treat it as cumulative drift. Investigate timing and rate behaviour: separate clocks, capture cadence, timestamp continuity, and dropped or duplicated data are possible branches, not diagnoses. FFmpeg Cookbook’s discussion of audio drift that gets worse over time also distinguishes a growing error from a stable offset.
A reconnect or source change is useful context. Record whether the alignment resets, changes direction, or jumps after either event. Those observations can help narrow the investigation, but they still need to be interpreted alongside the actual command and signal path.
| What you observe | What it can suggest | What to check next |
|---|---|---|
| Similar lead or lag at the start and later | A fixed alignment difference | Input and output timestamps, initial source alignment, and the mapping in the command |
| Little apparent difference at first, more later | Accumulating timing difference | Clock sources, capture rates, timestamp continuity, and whether data is being dropped or duplicated |
| Sudden change after a reconnect | A discontinuity or source restart may be relevant | Logs and timestamps around the reconnect, plus the input format and reconnect behaviour |
| Different result after changing a source | A changed signal or clock path may matter | Which device changed, its configured rate, and the corresponding input in FFmpeg |
These are working hypotheses, not a fault table. A particular row does not prove that a device or option is responsible. Record what you observed before making a change, so the next test can be compared with it.
Measure at startup and later in the stream
Make a short evidence sheet before touching the production command. Write down the stream start time, the elapsed time of each check, the recognisable sound event, whether sound leads or lags, and an approximate description of the gap. Repeat using a similar kind of event where possible. If a hymn has a clear attack, for example, compare that sound with the corresponding visible action rather than comparing unrelated moments in speech and music.
Check the YouTube preview or player as well as the local FFmpeg output. The local output can show encoder messages, while the viewer’s experience includes the path through YouTube. If the local recording or preview appears aligned but the public player does not, keep that distinction in your notes; it changes what you need to investigate. Avoid treating one playback path as proof that every other path has the same timing.
For a representative test, include speech and music or instrumental passages that resemble the real service. A quiet spoken introduction alone may not reveal the same issue as a longer musical section. YouTube’s guidance recommends a preflight test with audio and movement similar to the planned stream, and ongoing monitoring of stream health and messages. See YouTube’s live encoder settings and testing guidance.
Also note what else is happening at each measurement: a camera switch, a computer waking, a network-source reconnect, or a change in the audio feed. That does not establish a cause, but it helps distinguish a steady accumulating pattern from a timing jump tied to an event. Keep the comparison method consistent rather than relying on memory of how the stream sounded an hour earlier.
Map the audio and video source paths
Draw the signal path from each physical or software source into FFmpeg. For video, record the camera or file, capture device if present, input name, and whether the input is local or network-based. For sound, record whether it comes from a mixer, an interface, a camera, a USB input, a separate computer, or a network source. These are questions to ask of your installation, not assumptions about church equipment.
Then trace the command: which input supplies each stream, how the audio and video are mapped, and whether each is copied or re-encoded. Note any resampling, buffering or timestamp rewriting that happens before or inside FFmpeg. Include the configured audio sample rate and video frame rate where known, but do not assume that matching nominal settings prove that two devices share a clock or produce timestamps in the same way.
A single device may supply both picture and sound, or two devices may supply them independently. Separate devices can have separate clocks, so their timing can diverge even if they appear aligned at first. Whether that is happening here depends on the equipment and capture topology; the title alone cannot answer it. If the audio comes from a mixer while video comes through a capture device, document both paths and how their timing enters the same FFmpeg process.
Keep a redacted copy of the complete command. Remove stream keys and other credentials, but preserve input options, maps, timestamp options, codec choices, and option ordering. Capture the FFmpeg version and build output, startup stream metadata, representative logs, and your measurements at more than one elapsed time. This is the useful packet to bring to a technician or a focused troubleshooting discussion.
When setting up that test, a private FFmpeg YouTube stream test can help you plan how to observe the output without making the trial public. It does not replace capturing the command and measurements; its value is in letting you examine a representative stream before relying on the production run.
Inspect timestamps and relevant FFmpeg logs
Read the command in context rather than searching for one flag to paste in. FFmpeg’s command-line documentation describes synchronisation modes and timestamp handling, but behaviour depends on the selected mode, input and output, option scope, and version. Check the documentation available for the installed build before changing a live command. Options can apply to inputs or outputs, and placement can affect what they do.
In particular, -dts_delta_threshold is about sufficiently large timestamp discontinuities in formats that allow them, including MPEG-TS and HLS. It is not a general remedy for clocks that steadily diverge. FFmpeg documents that this correction is disabled when -copyts is used, except in the case of timestamp wrapping. Before considering it, establish that the input format and logs actually show the relevant discontinuity.
FFmpeg also documents -adrift_threshold in relation to synchronization behaviour: it is a minimum difference between timestamps and audio data that can trigger adding or dropping samples, with the documented threshold behaviour requiring positive -async. That description does not make it a universal setting for every command. Confirm the sync mode, option placement, installed version and relevant timestamps before interpreting it as applicable to your stream.
Look for the pattern around the problem, not just one alarming line. Keep log excerpts from startup, a period when the stream appears aligned, and a later period when the mismatch is clear. Include reconnects or source switches. Compare what the logs say about timestamps, input detection and output timing with the clock path you mapped. If there is no clear matching event in the logs, retain that fact rather than claiming the log proves a cause.
FFmpeg notes that its online documentation is regenerated and tracks a newer revision; the documentation index and version note are useful reminders to check the installed build’s own help or matching documentation when commands differ. Do not take an option description from the newest web page as proof that an older build behaves identically.
Check capture devices and clock behaviour
Once the source map is complete, ask whether audio and video are generated by the same device and clock. If they are separate, note the configured rates and how each is captured. A USB sound input, camera audio feed, mixer output and network audio source can each enter the chain differently; none should be presumed at fault without measurements. If one source is resampled or buffered, record where and by what software.
Check whether capture cadence is regular and whether the source can pause, restart or change rate during a long run. A dropped or repeated frame, timestamp jump, or source reconnect may explain a sudden shift, while a gradually changing difference has a different shape. These clues narrow the questions; they do not identify a specific defective interface, camera, or cable from the symptom alone.
Do not buy a capture card, interface, sync generator, or adapter merely because the audio is out of sync. Those devices address different signal paths, and the evidence here does not single out one as generally useful. First identify where the separate clocks or irregular timing enter, if they do. Then consider whether a device change is actually a relevant test, with a way to compare the result against the original setup.
For YouTube ingest, compare the output with the current live encoder recommendations: the page lists RTMP or RTMPS, AAC or MP3 audio, constant bitrate encoding, up to 60 fps, and a two-second keyframe interval recommended, with no more than four seconds. It lists 44.1 kHz for stereo. These are platform recommendations, not a diagnosis or a promise that compliant settings prevent drift. Confirm current guidance on YouTube’s page before relying on it.
Check output and monitoring separately
A stream can have a well-behaved local encoder and still need observation at the actual viewer endpoint. During a test, compare the local FFmpeg output, any local archive, and YouTube’s preview or player. YouTube’s live streaming tips advise monitoring audio and video quality and checking that a local archive file grows. For a church service, listen to and watch representative speech and music rather than checking only that the stream has connected.
Keep notes on stream health messages alongside sync measurements. A bitrate or connection warning is not proof of an audio clock problem, but it can provide context if the stream changes at the same time. Conversely, a healthy ingest indicator does not establish that audio and picture are aligned. Treat health status, local logs and what you hear in playback as separate observations.
If you use a recurring video loop rather than a live camera and mixer feed, the signal path is different and should be documented accordingly. This guide to a pre-recorded 24/7 YouTube stream from a VPS addresses a different operating setup; it is useful context for separating a file-based source from a capture-based service, not a substitute for diagnosing the latter.
Test one change at a time
After the evidence points towards a particular branch, make a controlled test outside the live service if possible. Change one relevant setting or source at a time, repeat the same measurements at startup and later, and keep the command and logs for each run. If several settings change together, an improvement or worsening will not tell you which change mattered.
Choose a test that resembles the actual service in source devices, audio content, motion, and duration enough to see whether the observed pattern recurs. The precise test duration depends on how quickly the symptom develops; do not infer that a brief aligned preview rules out slower drift. If the error is stable, test the alignment path. If it grows, retain the focus on rates, clocks and timestamps rather than applying a single whole-stream shift.
Make one change at a time and keep a rollback copy of the known command. If a setting increases instability or causes the sound to jump, return to the previous version and preserve the logs. A technician reviewing the full redacted command, FFmpeg build, signal map, timestamp evidence and measurements can reason from facts; a screenshot of one flag without that context cannot.
For a continuous broadcast, a bitrate and encoder-settings troubleshooting guide may help separate ingest and encoding warnings from the sync symptom. Do not treat bitrate advice as an audio-drift correction: use the warning it addresses, while continuing to measure sound against picture independently.
A long-running stream also needs an operating plan for when the computer or source must remain available. If the specific pain is having a local computer run continuously, StreamNeo removes that requirement by turning an uploaded video into a YouTube live stream that continues with your computer switched off; that is a different source model from diagnosing a live camera-and-mixer chain, and it is YouTube-only.
When the evidence and test plan are ready, decide whether to continue with the existing capture chain or use a file-based channel instead.
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 audio has a fixed offset or drift?
Compare the same kind of recognisable sound and picture near startup and at a later elapsed time. If the lead or lag remains similar, the error may be a fixed offset; if it grows, investigate timing and rate behaviour. Record direction and approximate size at both points rather than relying on memory.
Should I add -dts_delta_threshold to fix audio drift?
Not without evidence that the relevant input has a timestamp discontinuity in a format where FFmpeg applies that correction. The option is not a universal cure for clock drift, and FFmpeg documents an interaction with -copyts. Check the installed version, command and logs first.
What should I send someone who is helping troubleshoot?
Share the complete FFmpeg command with keys and credentials removed, the version/build output, input and device map, startup metadata, and representative logs. Include sync observations at startup and later, noting whether audio leads or trails and any reconnects or source changes. These details make it possible to discuss your actual setup rather than guess at a flag.
Does meeting YouTube’s encoder recommendations fix sync?
No. Those recommendations are an ingest baseline, not proof that the separate audio and video paths share timing or remain aligned over a long run. Test representative speech and music, monitor the preview and local output, and continue measuring sync over elapsed time.