If audio disappears after FFmpeg reconnects, first determine whether FFmpeg is reading a YouTube or HLS playlist, or sending a stream to YouTube Live. Those are different workflows, and a reconnect setting can restore a connection without correcting timestamps or bringing audio back.
The phrase “YouTube playlist stream loses audio after reconnecting” does not identify a single failure. A timestamp warning may be part of the problem, but you need the command, stream direction and logs around the reconnect before choosing a fix.
Determine whether FFmpeg is reading or sending a stream
Start with the command line, not with a proposed flag. Identify the input after -i and the output destination. An input might be a local file, a playlist file, an HLS URL or another network source. An output might be YouTube’s RTMP endpoint or an HLS ingest endpoint. Redact stream keys, usernames, passwords and signed URL parameters before sharing a command or log.
If FFmpeg is reading a playlist, it is pulling media into a process you control. The playlist could reference files or segments, and its timestamp behaviour depends on the actual format and how FFmpeg reads it. A YouTube video playlist, an HLS media playlist and a local text playlist are not interchangeable; do not assume that the word “playlist” means YouTube’s HLS ingestion protocol.
If FFmpeg is sending a stream, it is encoding or remuxing input and pushing an output towards YouTube Live. You need to inspect the outgoing audio stream and YouTube’s ingest health messages as well as FFmpeg’s input. A clean input does not prove that the outgoing stream contains the expected audio.
Write down the input protocol, output protocol, container and installed FFmpeg version. Check whether the command includes -copyts, audio mapping such as -map 0:a, codec options, and reconnect options. These details determine which diagnostics apply. If you need a broader example of the outbound loop workflow, the FFmpeg command for a 24/7 YouTube loop stream is relevant, but do not transplant its flags without matching them to your own input and output.
Capture the timestamp warning and audio symptom
Save enough log output to see what happens immediately before and after the interruption. Record the exact timestamp warning, including whether it says “non-monotonous DTS”, reports a discontinuity, or describes timestamps moving backwards. The wording matters: these messages point to timestamp handling, but they do not by themselves establish why audio became inaudible.
Describe the symptom separately from the warning. Does the audio stop at the reconnect and stay absent? Does it return after a delay? Does the video continue while audio is silent? Does audio return but drift out of sync? Does the output show an audio stream before reconnect but not afterwards? A timestamp message and an audio dropout can occur together without one being the sole cause of the other.
Compare the stream information before and after the event. Note the selected audio stream, its codec and channel layout, and whether FFmpeg reports packets continuing after reconnect. If you use explicit mapping, check whether the input still has the stream that the mapping selects. If the source playlist changes variants or files, its audio streams may not be identical across entries.
Keep the relevant lines with timestamps and the command’s stream mapping. For an outbound YouTube stream, record the matching time in Live Control Room as well. This gives you two observations: what FFmpeg attempted to send and what YouTube reported receiving. Avoid publishing a full key-bearing command; an exposed stream key should be replaced in YouTube settings.
Separate reconnect behaviour from timestamp handling
Reconnect and timestamp correction solve different classes of problem. Reconnect options tell FFmpeg whether and how to retry a network operation after a disconnection or selected error. Timestamp handling governs how packet presentation and decoding times are interpreted or adjusted. A successful retry does not prove that the resumed stream has continuous timestamps, contains audio packets, or maps the intended audio track.
FFmpeg documents -dts_delta_threshold for input formats that allow timestamp discontinuities, including MPEG-TS and HLS. When an absolute discontinuity exceeds the threshold, FFmpeg adjusts the current DTS and PTS by the corresponding delta. The documented default is 10 seconds. That is not a universal setting for every input, nor evidence that a warning below or above it caused your audio loss. See the FFmpeg timestamp options documentation and confirm the option applies to the format you are actually reading.
The -copyts flag is especially important to inspect. FFmpeg documents that the discontinuity correction is normally disabled when -copyts is used, except when timestamp wrapping is detected. If a command preserves input timestamps, adding or changing a threshold without understanding that interaction can leave the observed problem untouched. Do not add -copyts or remove it as a guess: first establish why it is present and whether downstream timing depends on it.
For an outgoing stream, a timestamp warning can also arise at a boundary between source segments, while an absent audio stream can result from mapping, source content, encoding or output format. Look for evidence that distinguishes these possibilities. If video packets continue but no audio packets are produced, inspect source selection and mapping before treating a timestamp flag as the answer.
Review applicable HTTP reconnect and retry options
FFmpeg’s HTTP protocol options include automatic reconnect for disconnections, end-of-file, network errors and selected HTTP errors. They also include retry and delay controls. Their availability and exact behaviour depend on the protocol and the FFmpeg build, so consult the FFmpeg protocol documentation and the help for your installed version.
These controls may suit an HTTP-based input such as an HLS playlist or segment request. They are not generic instructions for every output protocol. In particular, do not assume that an option intended for HTTP input applies to an RTMP output simply because the eventual destination is YouTube. Confirm which URL FFmpeg is opening, which protocol handles it, and whether the option is valid at that input or output position.
When retrying an input, consider what a retry does to the source sequence. Does FFmpeg resume the same live playlist, reopen a static resource, or encounter a new segment? Does an end-of-file mean the playlist ended normally or that a request failed? A retry that repeatedly reopens an exhausted input may not restore a continuous programme. Capture the error that precedes each retry rather than increasing retry limits without a reason.
Change one relevant reconnect setting at a time, and note the effect on the interruption itself. If retries become more reliable but the resumed audio remains missing, you have evidence that connection recovery improved while the audio path remains unresolved. Do not claim that a reconnect option fixes timestamp errors or restores audio unless the logs and listening test support that specific conclusion.
Check the relevant workflow’s stream and audio path
For a playlist-reading workflow, inspect the format and timestamps of the affected source and segments. If the input is HLS or MPEG-TS, check whether the timestamp discontinuity occurs at a segment boundary or after reopening the playlist. Review whether audio is present in each source item, whether the stream selection changes, and whether the command’s timestamp flags allow the documented correction to run. Test with a short, representative copy of the input before changing a long-running channel command.
For a stream being pushed to YouTube, compare FFmpeg’s output mapping and encoder settings with YouTube’s timestamped Live Control Room health messages. YouTube’s live streaming error messages identify issues such as no audio stream, multiple audio streams and unsupported codecs. If the health message says the ingestion stream contains no audio, investigate whether FFmpeg is selecting and sending audio. If it reports multiple audio streams, verify that the output contains the intended track rather than relying on an input’s stream count.
YouTube documents HLS ingestion requirements separately. If, and only if, FFmpeg is sending HLS to YouTube, check its HLS setup guide for the specified segment format, rolling playlist, request method and codec/audio settings. The guide calls for TS segments, a rolling playlist with no more than five outstanding segments, HTTPS POST or PUT, and segment durations of 1–4 seconds. Its audio guidance recommends 128 Kbps for stereo and 384 Kbps for 5.1 surround sound. These are requirements or recommendations for that stated ingest workflow, not universal remedies for a playlist being read as an input.
If your setup is a straightforward prerecorded loop, compare its source and mapping with the advice on looping a prerecorded playlist on YouTube with FFmpeg. For a different protocol or a machine that also handles the stream, the guide to keeping a YouTube livestream running after closing an SSH session may help separate process lifetime from media continuity. Neither reference replaces checks of your own logs.
Retest reconnects and confirm audio
Make a copy of the command and change only the setting tied to the evidence you collected. Keep a note of the original value, the modified value and the time of the test. That way you can revert a change that worsens the stream and avoid making several interacting changes that obscure the cause.
Test first with a short run that includes the affected source transition or a controlled interruption, if you can do so without disrupting your public channel. Watch FFmpeg output through the reconnect. Confirm that it selects the expected audio stream, continues producing audio packets, and does not repeat a timestamp error that breaks timing. Then listen to the received stream; log output alone cannot confirm that the audio is audible and in sync.
For YouTube output, check Live Control Room health messages at the same time as the FFmpeg log. If the warning clears but audio remains absent, return to mapping, source content and encoder output. If audio returns but timing drifts, investigate timestamp continuity separately. If the logs show a new error, treat it as new evidence rather than assuming the original change is broadly successful.
A useful record contains the FFmpeg version, redacted command, input and output protocols, the exact warning, the before-and-after audio stream mapping, and any matching YouTube health message. That is also the information to provide when asking for command-specific help. Without it, there is no responsible way to prescribe one timestamp option for every case described by this title.
For a channel that repeatedly loses its local process or computer overnight, moving the continuous playback off the machine you use day to day can remove that particular operational burden. StreamNeo takes an uploaded video and runs it as a YouTube live stream after you provide the stream key, so you do not need to keep your own computer on for that broadcast; it does not diagnose an arbitrary FFmpeg command or remove the need to verify the channel’s audio and stream health.
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 reconnecting FFmpeg fix timestamp errors?
No. Reconnect options address recovery from disconnections and selected errors; timestamp interpretation and correction are separate. Check the input format, timestamp flags and log evidence before changing timestamp handling.
Should I add -dts_delta_threshold when audio disappears?
Not automatically. FFmpeg documents it for inputs that accept timestamp discontinuities, including HLS and MPEG-TS, and -copyts normally disables the correction. Confirm your input format and options, then test a cause-related change while checking both packets and audible output.
What should I check if YouTube says there is no audio?
Compare the Live Control Room message time with FFmpeg’s output log. Check that the selected input has audio, that the output mapping includes the intended audio stream, and that the resulting codec and format match YouTube’s current guidance.
What information is needed to identify the cause?
Provide the FFmpeg version, a command with keys and credentials removed, the input and output protocols, exact timestamp warning, and audio mapping before and after reconnect. For a stream sent to YouTube, include the matching timestamped Live Control Room health message.