An FFmpeg invalid DTS warning tells you that packet timestamps need attention; it does not, by itself, identify the cause or prove that YouTube rejected your stream. Start by finding out whether the warning concerns an incoming playlist or segments, or a playlist you are creating for YouTube, then inspect the timestamp sequence before changing output settings.
FFmpeg may substitute or adjust timestamps as it processes packets. That can affect timing in the resulting stream, but the right response depends on the input format, the command and where the warning appears. Preserve the original inputs, capture the full context and test any change on a short sample.
Read the warning as evidence, not a diagnosis
You may see messages such as “Non-monotonic DTS in output stream” or “Invalid DTS: … PTS: …, replacing by guess”. DTS means decoding timestamp: it indicates when a packet is to be decoded. PTS, or presentation timestamp, indicates when its content is to be shown or heard. In streams with reordered video frames, those values need not be identical, but the decoding sequence still has to make sense for the output muxer.
The important clue is that FFmpeg is reporting a timestamp condition at a particular processing stage. In FFmpeg 9.0 muxer code, an invalid DTS condition can prompt a guessed replacement; handling non-monotonic DTS can also involve changing timestamps, with a warning that the resulting timestamps may be incorrect. This describes FFmpeg’s response to packet timing, not a full account of how the bad sequence arose.
A warning is not synonymous with a failed broadcast. The process may continue, and the output may play, but altered timing can contribute to sync problems or other unwanted behaviour. Conversely, a stream that goes offline may have a different cause. Do not treat the text as proof that YouTube rejected your stream, that the playlist is malformed, or that one particular FFmpeg option is responsible.
Save the exact warning and the lines immediately before and after it. Note whether FFmpeg labels an input or output stream, which stream number is involved, and whether the message repeats at a file boundary or throughout the job. That context helps distinguish a transition problem from a general timestamp issue.
Establish which way the playlist is flowing
“Playlist” can refer to different parts of a workflow. You might give FFmpeg an HLS manifest or a set of local transport-stream (TS) segments to read. You might instead use FFmpeg to create HLS output and send it to YouTube. A warning from the first situation should not be debugged as though YouTube were already ingesting an outgoing playlist.
Write the workflow down in order: input file or manifest, any concatenation or filtering step, output container or protocol, and destination. Then identify whether the warning is emitted while reading packets or writing the output. The mux-side warning described in FFmpeg’s source concerns output timestamp handling; it is not, on its own, a YouTube rejection message.
Record the full command, ffmpeg -version, the input type and whether the command copies streams (-c copy) or decodes and re-encodes them. Include the warning context. If you are sending HLS to YouTube, say so explicitly; if YouTube is only the destination for a continuous live stream and your workflow is not HLS ingest, say that too. Those are materially different paths.
Keep the distinction between copying and encoding in view. Stream copy avoids decoding and re-encoding, but it also carries the input packets and their timing into the output path for FFmpeg to handle. Re-encoding creates new packets, but it does not make a broken input sequence irrelevant: you still need to determine where timing becomes irregular and confirm the output behaviour. Neither mode is an automatic cure.
If you are weighing local operation against another way to keep a channel running, separate that operational question from the timestamp diagnosis. A low-cost VPS for a continuous YouTube livestream may suit someone who needs direct control over the process, but it will not make an unordered playlist valid by itself.
Inspect the inputs and their timestamp clues
Start with the files or manifest FFmpeg actually receives, rather than a playlist you believe it should receive. Confirm which segments appear, their order and whether the list changes while the process is running. For an HLS manifest, note its segment references and any discontinuity markers. For a local sequence, compare the filenames and the order the command uses; lexical order is not always the intended playback order.
Use FFprobe to inspect packet timestamp data for the relevant input and adjacent segments. The aim is not to collect every packet from a long-running channel, but to find the area surrounding the first warning and compare the end of one segment with the start of the next. Look for missing values, repeated or backward DTS, large gaps, or a reset to an earlier range. Treat these as leads: container time bases and stream layout affect how raw values should be interpreted.
Keep the exact media sample that reproduces the warning, plus its manifest if applicable. If the issue occurs only after several files have been joined, test the files individually and then as the same sequence. If only one boundary causes the warning, that is useful evidence for a transition issue; if each file causes it independently, focus on the individual inputs or the command’s treatment of their timestamps.
Do not “repair” the originals during investigation. Make a working copy or a short test output, retain the original command and record each change. That makes it possible to tell whether a change removed the warning, merely hid it, or changed playback in another way. A before-and-after log is more useful than a remembered impression from a stream that has already been replaced.
Compare timestamps at file boundaries
A playlist can contain individually playable files and still present a problematic sequence when one ends and the next begins. For example, a TS segment may carry timestamps that start again from a low value after a preceding segment ended at a later point. That is a plausible cause to investigate, not something an invalid-DTS line proves. The same symptom can arise from other input or option interactions.
Compare the final packet timestamps in one segment with the first relevant packet timestamps in the next, separately for audio and video. Check whether the values progress as the playlist expects, whether there is a genuine gap or reset, and whether a manifest signals a discontinuity. Do not compare bare numbers without their stream and time-base context. A timestamp measured in one stream’s time base is not directly interchangeable with a timestamp from another.
Where you have an HLS manifest, compare the declared sequence and segment order with the media you inspect. A segment list can be syntactically present while its contents still have an unexpected timing transition. Equally, a discontinuity marker can describe a real change in a sequence; it does not automatically correct timestamps inside a segment or guarantee that downstream processing will accept them.
The distinction matters in continuous channels made from repeated clips, scheduled blocks or local loops. If the playlist joins separately prepared files, investigate how those files were generated and whether their time bases or start points differ. Readers building a longer programme from clips may also find it useful to review how to schedule product demo videos in a continuous YouTube Live stream, while keeping scheduling logic separate from timestamp repair.
Review timestamp options in context
Before adding flags, read the options already in the command. In particular, check for -copyts, -start_at_zero, -copytb and any discontinuity-related settings, and note which inputs or outputs they apply to. A timestamp option that is appropriate for one workflow can preserve a problematic condition in another.
FFmpeg’s command-line documentation describes -dts_delta_threshold correction for formats that accept timestamp discontinuities, including MPEG-TS and HLS. The documented default threshold is 10 seconds. The same documentation says that this automatic correction is disabled by -copyts, except when timestamp wrapping is detected. Therefore, if you find -copyts in a command, ask whether preserving the input timestamps was intentional. Removing it for a controlled baseline test may be reasonable when it was not intentional, but it is not a universal fix.
Avoid treating a threshold change as a general-purpose repair. It only has a role in the documented discontinuity-correction context, and the observed timing condition may not be one of those discontinuities. Likewise, do not add -copyts on the assumption that preserving timestamps will make them monotonic. It may preserve the values that are causing the issue and disable normal correction in the relevant formats.
If you generate HLS, FFmpeg’s format documentation describes an option to insert #EXT-X-DISCONTINUITY before a segment’s information. Consider a marker only when your sequence has a real discontinuity and your playlist-generation flow supports the intended semantics. The presence of an option in the documentation does not establish that it repairs invalid packet DTS, and adding markers without diagnosing the transition can obscure rather than explain the sequence.
Keep unrelated output settings out of the first test. Bitrate, resolution, audio layout and keyframe settings may matter to the wider stream, but changing them does not directly establish why DTS values went backward or became invalid. A guide to adding a logo and scrolling text to an FFmpeg YouTube stream concerns a different layer of the output; do not use graphics filters as a substitute for checking packet timing.
Separate YouTube HLS rules from timestamp repair
If your workflow really is YouTube HLS ingest, validate the ingest requirements separately from FFmpeg’s timestamp warning. YouTube’s HLS ingest guidance specifies TS segments with durations of 1–4 seconds, a rolling playlist with no more than five outstanding segments, no byte-range mode, and HTTPS POST/PUT. These are requirements for how the HLS feed is sent; meeting them does not prove that packet timestamps are valid or monotonic.
That distinction prevents two common troubleshooting detours. A compliant segment duration cannot repair a timestamp reset inside the media. Conversely, a DTS warning does not establish that the playlist violates YouTube’s segment or transport rules. Check each question with the evidence that applies to it: manifest and delivery behaviour for ingest rules, packet timing and FFmpeg logs for DTS.
For other YouTube live workflows, do not assume HLS ingest rules apply just because you use a playlist locally. YouTube’s live encoder guidance discusses encoder settings such as constant bitrate and keyframe intervals. Its current guidance recommends a 2-second keyframe interval, not exceeding 4 seconds. Those settings are relevant to stream configuration, but they are not a direct diagnosis or guaranteed repair for a DTS warning.
If playback or stream health is in question, make a test broadcast and monitor YouTube’s stream health indicators while you compare the FFmpeg log. Check audio-video sync as well as whether the broadcast stays active. A clean-looking manifest alone cannot show that playback is in sync; a continuing FFmpeg process alone cannot show that YouTube is receiving a healthy stream.
Choose a fix only after locating the cause
There is no source-backed command that repairs every invalid-DTS warning across every playlist. A useful fix follows from what you observed. If one boundary resets timestamps, investigate how those segments were made and how they are joined. If a command intentionally preserves input timestamps, test a baseline without that preservation only if preserving them is not required. If the warning appears with each input independently, inspect those inputs and the relevant processing path rather than only the playlist boundary.
Change one thing at a time on a short, reproducible sample. Keep the original files and command, note the FFmpeg version, and compare the new log around the same packets. Then check playback and sync. If the warning disappears but the media becomes out of sync, the test has not established a good fix. If it remains, restore the baseline and investigate the next evidence-backed possibility rather than stacking flags.
When asking for help, include the exact command with secrets such as stream keys removed, FFmpeg version, input type, whether you are reading or generating HLS, stream-copy versus encoding mode, and the warning context. Add a short manifest and segment metadata where you can share them safely. Without those details, anyone naming one universal option is guessing.
For channels where the repeated task is keeping a prepared file live rather than debugging a custom FFmpeg playlist, StreamNeo removes the need to leave your own computer running to repeat that broadcast; it does not change the need to prepare a sound source file and confirm the channel behaves as intended.
If you need a continuously running stream, choose the operating approach separately from the cause of the DTS warning. A 24/7 pre-recorded stream data-use guide for India can help you assess the network side of a locally run workflow, but it cannot tell you whether a particular packet sequence is correctly timed.
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 an invalid DTS warning always mean the stream has failed?
No. It means FFmpeg encountered a timestamp condition and may have substituted or adjusted a timestamp. The process can continue, but you should check the surrounding log, playback and sync rather than assume either success or failure from the warning alone.
Should I add -copyts to fix non-monotonic DTS?
Not as a generic fix. FFmpeg documents that -copyts preserves input timestamps and disables normal discontinuity correction for supported formats, except when timestamp wrapping is detected. Check whether preservation is intentional and test any change on a short sample.
Will an HLS discontinuity marker repair bad timestamps?
Not necessarily. A marker can signal a real discontinuity between segments in a playlist, but it does not by itself correct packet timestamps within media or prove that a given DTS warning is resolved. Use it only when the sequence and playlist-generation flow call for it.
What information is needed to identify the cause?
Provide the complete FFmpeg command with credentials removed, ffmpeg -version, the exact input type, and the log lines around the warning. Also state whether the workflow reads a playlist or creates HLS for YouTube, and whether it copies or re-encodes streams; a short sample or packet metadata around the affected boundary can help confirm the hypothesis.