A timestamp warning in FFmpeg does not, by itself, tell you what is wrong with a YouTube Live looping playlist. To find the cause, inspect the complete log, the exact concat list and source files, then test the joined sequence first without looping and then across its loop boundary.
The concat demuxer already shifts timestamps as it moves between files. The reliable fix depends on whether the files, their duration information, the installed FFmpeg build, or the live output settings explain the first bad timestamp; no single flag is a guaranteed repair.
Recognise the timestamp symptom
“Non-monotonous DTS” means FFmpeg encountered a decode timestamp that did not move forward as expected for the stream being processed. It is a clue to investigate, not a diagnosis. A warning may appear at a file boundary, only when the playlist returns to its first clip, or alongside other messages that identify a different problem.
Start by noting what you hear or see and when it happens. Does video freeze briefly, jump, or go black? Does audio click, drop out, or drift out of sync? Does the stream stop, or does YouTube show an ingest warning while local playback remains clean? Write down the clip and approximate point where the behaviour begins, and whether the first pass is clean.
A defect at every transition points you towards the clips meeting at those boundaries. A defect only at the return from the last file to the first gives you a narrower place to inspect, but still does not prove a timestamp reset is the cause. Compare the last and first files just as carefully as any other adjacent pair.
Keep three branches separate: the local media sequence, FFmpeg’s processing of that sequence, and YouTube’s ingest. A clean local join does not prove the live ingest is healthy, and a YouTube warning does not establish that the local timestamps are wrong.
Read the complete FFmpeg log
Save the full log from the start of the process through the first bad transition and the messages immediately after it. A copied error line often omits the evidence you need: the input being opened, stream details, mapping, output format, preceding warnings, and whether FFmpeg continued or exited. Include the command line and the installed FFmpeg version when asking someone to review it. Remove the stream key before sharing anything.
Find the earliest relevant warning, not just the most alarming line near the end. Record which input FFmpeg was reading at that moment and, if the output identifies streams, whether the message concerns audio or video. Then compare the warning time with the clip durations and observed playback. A timestamp warning at a transition matters differently from one that appears before any boundary or only after the live output starts.
FFmpeg options and behaviour can vary by build and release. Check the help and documentation for the version you are actually running before adding a flag copied from an old forum post or a different command. In particular, do not treat a historical proposal such as -force_dts_monotonicity as a supported current fix without confirming it exists in your build and understanding its effect.
A log is most useful as a sequence of evidence. Keep an unmodified copy, then make one controlled change at a time and save a new log. If several options and files change together, you may remove the symptom without finding the cause, or introduce a second problem that is harder to identify.
Validate the concat file list and paths
The concat demuxer reads a text file containing directives for the input files, typically one file line per clip. Check the actual file passed to FFmpeg, not a separate draft playlist. Confirm every entry is present, spelled as intended, points to the correct file, and appears in the intended order. Look especially for a duplicated clip, omitted transition, or a path that resolves to an unexpected file.
Paths can be a source of confusion when a process starts from a different working directory than you expect. Use unambiguous paths where practical, and confirm FFmpeg can open each listed file. If filenames contain characters that need escaping in an ffconcat file, follow the quoting and escaping rules in the FFmpeg concat demuxer documentation. A list that looks right in an editor can still refer to the wrong media at runtime.
Make a small working copy of the list for diagnosis and test it without endless looping. Preserve the original so that a result can be compared against the production sequence. If you maintain a devotional or meditation rotation, the practical steps for building its ordered list may also help in looping a Gujarati guided meditation playlist on YouTube Live.
Check whether each listed file can be opened and probed individually. A truncated file may report a plausible name and still end early or contain damaged packets. If the first bad timestamp follows one particular clip, test that file and its immediate neighbours before editing the entire playlist.
Compare source durations and streams
The concat demuxer positions later files using the duration it determines for earlier ones. If that duration is wrong, the next file may start at an unsuitable timestamp; a truncated or damaged source can also make the reported duration misleading. Unequal audio and video lengths may leave a gap when the demuxer adjusts the sequence. These are reasons to inspect the actual files, not reasons to assume every warning is a duration error.
For every clip, compare the reported duration and stream layout. Note the number of audio and video streams, codecs, time bases, frame rates, and audio format. Pay particular attention to the two files that meet where the log first becomes problematic, and to the last and first files at the loop boundary. Different containers can obscure differences, so compare the streams rather than relying on filenames or playback duration alone.
The concat demuxer expects the files to have the same streams, codecs, and time base for reliable joining. A playlist made from camera exports, downloaded clips, and edited title cards may look consistent in a player while having different stream parameters. Stream copy does not make those sources equivalent: it copies encoded packets rather than normalising their properties.
If a file is truncated, damaged, or has an incorrect duration, repair or replace it where possible. The concat script supports a duration directive for a file, but use one only if you know the correct duration independently. Guessing a duration to suppress a warning can shift subsequent timestamps and make audio/video timing worse.
For a practical explanation of keeping multiple inputs in order, see streaming multiple VOD files in sequence with FFmpeg on Ubuntu. It is useful background, but your own list, media properties, and log still decide the diagnosis.
Understand how concat adjusts timestamps
The concat demuxer emits packets from each file in list order. It shifts timestamps so the first file begins at zero and positions each following file at the estimated end of the previous one. It is not simply resetting every clip to zero and forwarding those separate timelines unchanged. That is why a timestamp that appears to reset in an individual source does not automatically explain the output warning.
This adjustment relies on the duration information being suitable and the streams being compatible. If a file’s duration is inaccurate, the following file can be positioned too early or late. If audio and video do not end together, a gap can result. If streams or time bases differ, copying packets across the boundary may produce a sequence that the output cannot handle as expected.
Keep the remedies in proportion to the evidence. If all inputs match and the durations are correct, changing timestamp behaviour may be unnecessary. If the source set is incompatible, consider creating normalised intermediate files or transcoding them to consistent properties. Re-encoding costs processing capacity and can affect quality, but it lets you standardise streams that stream copy cannot reconcile.
Timestamp tools are specialised, not a substitute for examining inputs. FFmpeg’s setts bitstream filter documentation describes expressions that can change PTS, DTS, duration, or time base; it does not promise one expression will repair every concat. The documentation specifically warns against setting PTS equal to DTS when B-frames are involved. Avoid adding -copyts, -copytb, -fflags +genpts, or -avoid_negative_ts as a ritual. Their effects depend on the demuxer, codecs, time base, and whether packets are copied or encoded.
Test the sequence without looping
First test the concat input as a finite sequence on the same machine and FFmpeg build, without -stream_loop -1. The goal is to reproduce the boundary that fails while removing infinite repetition from the test. Keep the input list and output settings as close as possible to the live command, but send the result to a local file or another non-live output so you can inspect it without YouTube ingest in the way.
Review playback across each transition and compare it with the log. Seek around the first suspect boundary, listen for a gap or click, and check that picture and sound remain in step. Do not check only the start and finish: a short glitch at one join can disappear in a general viewing pass. If the sequence is clean locally, note which exact command and files produced that result.
If the test fails at the same boundary as the live stream, focus on the source pair, duration, or stream compatibility before changing YouTube settings. If it fails at a different point, use the new log and playback to identify that point rather than assuming the original theory still applies. A useful diagnostic changes one factor at a time: replace one suspect file, correct one confirmed path, or test a normalised set, then compare.
When stream copy is appropriate, it is the lighter path because FFmpeg does not decode and re-encode all the media. It is appropriate only when the inputs satisfy the compatibility assumptions and the output works across boundaries. If they do not, a consistently encoded diagnostic set may help establish whether mismatched sources are the issue. Choose encoding properties for the intended output and available capacity, then check the resulting quality and synchronisation rather than assuming transcoding is free of trade-offs.
Add looping and check live ingest separately
Once the finite joined sequence plays correctly, introduce repetition. FFmpeg’s -stream_loop -1 repeats an input indefinitely; -re reads file input at its native rate rather than sending it as fast as possible. These options control looping and pacing. They do not repair incompatible streams, inaccurate durations, or damaged media. Place input-scoped options before the input they apply to, and verify the actual command line used by the running process.
Watch the transition from the last item back to the first, not only the internal joins. Compare the looped run’s log with the finite test and note whether the first new warning appears only at that return. Confirm audio and video stay in sync on both sides. If the finite sequence and local loop are clean but YouTube reports a problem, move to the ingest branch instead of continuing to rewrite timestamps.
YouTube’s current live encoder settings list supported protocols, video and audio formats, constant bitrate guidance, frame-rate limits, and keyframe recommendations. Use the current official table for the resolution, codec, and frame rate you actually send rather than applying one generic bitrate to every stream. Its encoder setup guidance explains entering the server URL and stream key. Treat the key as a password, and check stream health and the specific messages in Live Control Room during a test.
A clean local file does not guarantee a successful live broadcast, and a successful ingest does not make a defective source sequence sound or look right. Keep the branches distinct: inspect FFmpeg and media when the local output glitches; inspect encoder configuration and Live Control Room when the local output is sound but ingest is not. If your operating plan also depends on recovering after a household power cut, the separate restart setup for a 24/7 stream after a power cut in India covers that operational issue rather than timestamp diagnosis.
For a channel that should keep playing while your computer is switched off, StreamNeo removes the need to leave your own machine running after you have prepared the file and channel. It does not change the need to verify that your playlist and content are ready before broadcasting.
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 “non-monotonous DTS” mean the source timestamps reset?
Not necessarily. The concat demuxer shifts timestamps as it joins files, and the warning alone does not establish whether a source reset, duration estimate, stream mismatch, or another condition caused trouble. Check the full log at the failing boundary and compare the relevant source files.
Should I add -fflags +genpts or -copyts?
Not as a general first step. Their effect depends on the demuxer, stream timing, and whether you copy or encode, so first identify the actual problem in the list, files, and log. Make a controlled test only when you can explain what the option is intended to change.
Why does the playlist work once but glitch when it loops?
The return from the last file to the first is another boundary, and its two files may have different duration or stream properties from the other pairs. Compare that boundary’s log and playback with the finite sequence before changing loop or timestamp options.
Does -stream_loop -1 fix timestamp problems?
No. It repeats the input indefinitely; -re paces file input at its native rate. Neither option normalises streams or corrects duration metadata, so test and repair the joined sequence before using them for a live loop.