Lag in an FFmpeg stream to YouTube can come from timestamp problems, but a delay alone does not prove that timestamps are at fault. Start by finding where the problem first appears: in FFmpeg’s output, in a local recording, at YouTube ingest, or only in viewer playback.
Then match the remedy to the evidence. Input timestamps, B-frame reordering, stream-copy versus re-encoding, muxer behaviour, encoder load and outbound network conditions can all affect what you see; no single FFmpeg flag fixes every case.
Identify what kind of lag you are seeing
“Lag” can describe several different symptoms. The live picture may arrive late but remain smooth; it may stutter or freeze; audio may drift away from the picture; or playback may fall behind while the stream itself is still being received. These point to different parts of the path, so write down exactly what you observe before changing the command.
First establish whether the output is already late or uneven before it reaches YouTube. Watch or inspect a local recording made from the same source, and compare it with the preview in YouTube Live Control Room. If the local result has the same pauses or audio drift, investigate the source, timestamps and encoding first. If local output looks and sounds right while YouTube reports ingest trouble, shift attention to the encoder’s connection and ingest configuration.
A delay that is steady from the start is not the same as a delay that grows over time. A growing audio/video offset, repeated freezes or a sudden jump may help narrow the cause, but none identifies a timestamp fault by itself. Note when the symptom begins, whether it repeats, and whether it is visible to you locally or only in the YouTube preview.
Keep an exact copy of the command and the relevant log lines. Record your FFmpeg version and build, the input container and codecs, and whether you use -c copy or re-encode. Without those details, a seemingly plausible flag change can conceal the symptom, damage timing or make the output less reliable.
Read the timestamp and DTS messages in context
FFmpeg messages about timestamps are clues, not a complete diagnosis. In particular, a warning about non-monotonic DTS means FFmpeg has encountered decode timestamps that do not increase as expected for the packets being written. It does not, on its own, prove that YouTube is adding delay or that the picture’s presentation timestamps are wrong.
Decode timestamps (DTS) tell a decoder when to decode a frame; presentation timestamps (PTS) tell it when to show it. With codecs that reorder frames, including streams with B-frames, decoding and display order can differ. A sequence of presentation times that reflects reordering should not be confused with permission for decode timestamps to be arbitrarily non-monotonic. Check the surrounding log messages and the stream’s frame structure rather than treating the word “DTS” as a recipe.
Look for the first relevant warning, not merely the last one before an output stops. Does it appear as soon as the input opens, only after a stream-copy output begins, or when an output container is written? Is it repeated for video, audio or both? Those distinctions can help separate bad or irregular input timing from a problem introduced while copying, synchronising or muxing streams.
Preserve enough of the log to see the command and the context around the warning. A single copied line often omits the input stream mapping, codec details and options that determine what the message means. Do not remove warnings from your logs simply to make the run look clean; they may be the only evidence that identifies when timing changes.
Check the input timestamps and stream-copy path
Before adding options, inspect what arrives at FFmpeg. Use its input and stream information to note the reported start time, time base, frame rate and codecs. If you can compare packet timing at input and output, check where an irregular sequence first appears. A variable-frame-rate source or a file assembled from mismatched segments may behave differently from a regular, single-file source, especially when packets are copied rather than decoded and encoded again.
Stream copy (-c copy) passes encoded packets through without decoding and creating new video frames. That avoids the work of re-encoding, but it also means FFmpeg has less opportunity to correct properties inherited from the input. If timing is irregular in the source, copying may carry that pattern into the output. Re-encoding can create a new timed output, but it costs processing capacity and cannot be assumed to cure every source or synchronisation fault.
-copyts is not a general timestamp repair. The FFmpeg documentation describes it as retaining input timestamp values rather than applying FFmpeg’s usual sanitising. The initial start-time offset is retained too, and FFmpeg cautions that synchronisation and muxer processing can still make output timestamps differ from input timestamps.
-start_at_zero belongs in that specific conversation: used with -copyts, it shifts input timestamps so they begin at zero. It is not a stand-alone cure for arbitrary gaps or non-monotonic values. Likewise, -copytb controls the time base used when copying streams; the FFmpeg documentation notes that a demuxer time base may be useful in some variable-frame-rate stream-copy cases. Treat it as a possibility to test against the input and installed build, not a default instruction for every stream.
Check for options that change timestamp treatment, including -copyts, -start_at_zero, -copytb and -fflags +igndts. Confirm their placement and effect using the documentation for the FFmpeg build you actually run. Output synchronization and muxer options matter as well, so the same input option may not produce the same packet timeline in every output path.
Be particularly cautious about -fflags +igndts. A case discussed in the FFmpeg user community warned that ignoring DTS can lead to faulty reconstructed decode timestamps when B-frames reorder presentation. That example is not a universal rule for all inputs, but it is a good reason not to suppress DTS evidence before understanding how the source is encoded. If your command includes this flag, test a run without it and compare the logs and local result rather than assuming the flag is harmless.
Check encoding load and source quality
Timestamp warnings can coexist with an encoder that cannot keep up. If you re-encode video, inspect FFmpeg’s reported output speed and the machine’s CPU load during the actual stream. A speed that repeatedly falls behind real time or a processor under sustained pressure can produce stutters even if the incoming packet times are reasonable. Also check whether other tasks are competing for the same machine’s CPU or storage.
Watch the local output directly, or record a short sample while the stream runs. If it is already choppy, blocky or out of sync there, YouTube is not the first place to look. Check whether the source file plays smoothly on its own, whether audio and video are aligned before FFmpeg processes them, and whether a filter, scaling step or other processing task has increased the encoder’s work.
Re-encoding and stream copy have different trade-offs. Copying usually requires less processing, but preserves more of the source’s encoded characteristics and timing. Re-encoding gives control over the new encode, but adds load and can create a new bottleneck. If only the re-encoded test falls behind, compare output speed and CPU load before changing timestamp flags. If both paths show the same timing irregularity, investigate the source or its timestamps.
Readers deciding how much work belongs on a local machine can use this guide to run a prerecorded stream on a cloud VM. Moving the workload elsewhere changes where you monitor and maintain it; it does not automatically correct faulty input timing or poor output configuration.
Review codec reordering and the output muxer
The output is shaped by more than the input timestamps. Codecs can reorder frames, while FFmpeg’s synchronisation choices and the output muxer determine how packet timestamps are represented and adjusted. That is why a command copied from another setup may behave differently with another codec, container or source, even if the visible symptom sounds the same.
When B-frames are present, presentation order and decode order need to be interpreted separately. Do not label every reordered presentation timestamp an error, and do not assume that an output warning can be solved by forcing timestamps to increase without checking what the decoder needs. A change that makes a warning disappear may still leave playback incorrect.
The muxer may shift timestamps to handle negative values. For example, avoid_negative_ts is an output-muxer option whose behaviour depends on its configuration and the relevant muxer. Shifting leading timestamps is not the same as repairing arbitrary non-monotonic sequences later in a stream. Consult the documentation for the particular output format and test the result; do not add the option merely because the log mentions a timestamp.
Option placement matters. Input options, output options and format-specific options have different scopes in an FFmpeg command. If you test a setting, change one applicable option at a time and keep the input, output destination and other settings fixed. Compare the resulting log and local playback with the original run so you know what the change actually affected.
For a channel that uses a fixed video file rather than a live camera, first make sure the source is suitable for continuous playback and that the delivery method fits the operating setup. A guide to preparing a recorded lecture stream with a static image in OBS covers a different workflow, but the distinction between source preparation and delivery remains useful: a different streaming tool does not remove the need to check the source.
Compare local output with YouTube stream health
YouTube Live Control Room gives you another point in the diagnostic path. Check its stream-health status and timestamped error messages while the stream is running. A platform message is evidence about what YouTube is receiving, but a viewer noticing delay is not, by itself, evidence of a timestamp error. Compare the platform information with FFmpeg’s log and your local output rather than treating any one signal as conclusive.
Review YouTube’s current live encoder settings and recommendations independently of the timestamp investigation. Its guidance covers supported ingest protocols and codecs, frame rate, keyframe interval, audio and bitrate. These are platform recommendations, and the applicable details can depend on resolution and ingest mode; consult the current table for your stream instead of assuming one setting applies to all channels.
YouTube recommends testing with representative video and audio and monitoring stream health. Use a short test that resembles the real channel: movement in the image, the normal audio path and the output settings you intend to keep. A static test image might not expose a problem that only appears during scene changes or more demanding encoding. Keep the test evidence so you can distinguish a change in timing from a change in picture quality or ingest status.
YouTube’s troubleshooting guidance for live streams also directs creators to check the encoder output, errors, CPU load and local archive, as well as the outbound connection. If the recording or direct encoder output is poor, investigate the source and local processing first. If it is healthy but the platform preview is not, test the outbound network and ingest path before rewriting a command that already produces good local output.
A connection can be unstable even when its headline speed sounds adequate. Watch for dropped or interrupted output, and consider whether other users or scheduled tasks share the connection. If you are deciding between running an always-on stream from your own machine or a remote computer, this guide to a cloud PC billed in rupees explains the operating trade-offs. The location of the machine changes the network path; it is not a timestamp fix.
Match one change to the diagnosed cause
Use the first point at which the output departs from expected behaviour to choose your next test. If the input already has irregular timing, investigate how it was created and whether stream copy carries the irregularity through. If the warning begins only with a particular copy or muxing path, check the time base, applicable options and container behaviour. If local output is clean but YouTube reports a problem, check ingest settings and the outbound route.
If re-encoded output falls behind while a copy test remains smooth, examine output speed, CPU load and processing steps. Reducing work or changing the encoding path may help, but it is a trade-off: a lighter encode changes quality, while copying limits how much you can alter the source. Make an adjustment only after identifying which path is failing, and confirm that both sound and picture remain usable.
Avoid stacking several timestamp flags in one experiment. For example, do not add -copyts, -start_at_zero, -copytb and a negative-timestamp muxer option together because one warning appeared. Their effects depend on the input, whether packets are copied, and the output muxer. Keep a known-good command, change one relevant setting, run a comparable test and retain the new log.
For a sustained channel, a stable process matters as much as a successful short test. Keep the source file, command, FFmpeg build details and representative logs together, and note whether the local archive and YouTube health agreed. If the repeated manual work of keeping a file-based channel running and recovering it after interruptions is the specific pain, StreamNeo can remove that machine-side burden by turning an uploaded video into a YouTube broadcast without leaving your computer on; it does not diagnose or repair a faulty FFmpeg source.
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
Does -copyts fix stream lag?
No. It retains input timestamp values rather than applying FFmpeg’s usual sanitising, so it can preserve an offset or irregularity you need to investigate. Synchronisation and muxer processing can still change output timestamps, so compare the input, output and local playback before deciding whether it belongs in your command.
Should I add -start_at_zero?
Only consider it in the context of -copyts: FFmpeg documents it as shifting timestamps to zero when used with that option. It does not repair every non-monotonic sequence or other cause of lag. Test the paired behaviour with your actual input and output path.
Does a non-monotonic DTS warning mean YouTube is causing the delay?
Not necessarily. It identifies a decode-timestamp issue in the output path, but the source, stream-copy behaviour, codec reordering and muxer can all affect it. Compare FFmpeg’s log and a local recording with YouTube’s stream-health messages to find where the symptom first appears.
What should I check if local playback is smooth but YouTube is not?
Check Live Control Room stream health and its timestamped messages, then review the current YouTube encoder requirements and test the outbound connection. A clean local result makes the source and local encode less likely to be the first failure point, but it does not prove a single network cause. Keep the logs and compare a representative test before changing the command.