A skipped track is a diagnostic clue, not proof that one particular FFmpeg setting is wrong. First establish whether it is missing from the local playlist playback or only from the stream YouTube receives; then collect the playlist, command, FFmpeg version and logs before changing encoding options.
For a conventional YouTube Live encoder output, send video as well as audio. The template below pairs a still image with a repeating audio playlist, but it is only a starting point: paths, the installed FFmpeg build, output settings and the RTMPS URL must match your setup. It has not been tested against your files, and the command does not itself start or end a broadcast in Live Control Room.
Find where the track disappears
Write down the expected order of tracks and the approximate point where the missing one should begin. Then compare three stages: the files in the playlist, the audio produced by FFmpeg locally, and the audio heard or reported by YouTube. A track may be absent before FFmpeg ever opens it, may fail while the playlist is being read, or may be present in local output but not arrive as expected at YouTube. Those are different problems and call for different evidence.
Start with a small, representative test rather than changing a long-running channel. Play the relevant files locally in playlist order, including the track before and after the apparent skip. Note whether the “missing” track is silent, very quiet, unusually short, or simply not opened. If local playback also skips it, investigate the file, the playlist entry and the application used for playback before treating the YouTube connection as the cause.
Next, check FFmpeg's output on a local recording or other controlled destination if you can do so without interrupting a live broadcast. Compare the same passage with the YouTube output. If the local output contains the track but YouTube does not, preserve stream-health messages and the time of the discrepancy; look at the outgoing encoder and ingestion path rather than rewriting the playlist first. YouTube advises testing a broadcast before relying on it and monitoring stream health during it; see its live encoder setup guidance.
Keep a short incident note: track filename, expected start, what you heard locally, what you heard on YouTube, and any status message at that time. This makes it possible to distinguish a reproducible omission from a player buffering, monitoring or observation issue. If your channel is built around long recorded programmes rather than separate audio files, the workflow in streaming podcast episodes from a folder continuously may help you compare playlist-level assumptions with your own arrangement.
Capture the version, command and logs
Before editing the command, capture the exact FFmpeg version and build configuration. Run ffmpeg -version in the same environment that launches the broadcast, and retain the complete output. Different machines, containers or shell sessions can use different FFmpeg installations; a version captured on your desktop does not establish what a scheduled job or remote session is running.
Save the exact command as executed, including the order of options, input names, maps, filters and output format. Redact the stream key and any credentials before sharing it. Keep the playlist text as well, preserving its line endings and spelling. If a wrapper script, service or scheduler launches FFmpeg, capture how it expands variables and the working directory it uses: a relative path is interpreted in relation to that context, not necessarily the directory you expect.
Capture stderr from the start of a test through the point where the track should have appeared. FFmpeg often prints useful stream discovery, timestamp and muxing information there. Do not keep only the final error line: the earlier messages can show which streams were detected, whether a file was opened and whether a timestamp discontinuity began at an earlier track. Record the local clock time and which file was current when any warning appeared.
A useful evidence bundle contains the version output, the playlist, the redacted command, logs, the relevant filenames and a precise description of where the omission was heard. Avoid changing several things between tests. If you change the playlist and encoder settings at once, a later successful run will not show which change mattered. For an example of a different continuous-media use case, see how relaxing music can be streamed without the file ending; the same discipline of checking the media sequence before altering output settings applies.
Inspect the concat playlist text
The concat demuxer reads a text script. For automatic format recognition, its first line must be exactly ffconcat version 1.0. A minimal file named audio.ffconcat might contain:
ffconcat version 1.0
file 'music/track-01.mp3'
file 'music/track-02.mp3'
Each file entry should identify the intended file in the intended order. Relative paths are often easier to move with a project, but they depend on the process's working directory. During diagnosis, try absolute paths or confirm the working directory and resolve each relative path yourself. Check capitalisation, punctuation, file extensions and whether the process user can read every file. A typo may look like a playback gap from a distance, while the log identifies an open failure.
Paths containing spaces or quote characters need appropriate quoting or escaping in the concat script. Do not assume that quoting for your shell command also quotes a filename inside the playlist: the shell parses the command, while the concat demuxer parses the script. Consult the FFmpeg concat demuxer documentation for its syntax and escaping rules. A simple diagnostic is to make a temporary playlist containing only the track before the gap, the suspect track and the following track, with paths that are easy to verify.
Check for accidental omissions, duplicate lines and blank or malformed entries around the point of failure. Confirm that the playlist on disk is the same file the command references; similarly named copies in different folders are a common source of confusing tests. If editing on another operating system, inspect the actual text rather than trusting how an editor displays it. Keep a copy of the original before making corrections so the evidence remains available.
Check stream and time-base compatibility
The concat demuxer is designed to join inputs by treating their packets as though they had been muxed one after another, with timestamps adjusted between files. That model has an important condition: the inputs should have matching streams, codecs and time bases. Two files that both play as music are not necessarily equivalent as media inputs. They may differ in codec, sample rate, channel layout, stream count or timing metadata.
Use ffprobe or FFmpeg's input diagnostics to inspect the streams of the track before the skip, the suspect track and the next track. Compare what FFmpeg reports, not just what a media player displays. If a particular file has a different stream layout, or if FFmpeg reports timestamp warnings at its boundary, preserve that output and test the file separately. Do not infer a cause solely from an extension such as .mp3 or .wav.
There are two broad approaches. If the inputs have compatible streams and you want to avoid re-encoding, the concat demuxer may suit the job. If they need conversion, filtering, fades or level processing, decode and process them with a concat filter workflow that re-encodes the result. FFmpeg's concat FAQ guidance describes the distinction. The trade-off is that re-encoding gives you a place to standardise or process inputs, but adds processing and another set of output choices to verify. It is not automatically the right fix for a track that is missing because its path is wrong.
For diagnosis, test the suspect file by itself and then in a short sequence with its neighbours. If it works alone but not in the sequence, the boundary or compatibility deserves attention. If it fails alone as well, inspect its decode messages and properties first. Preserve the original media and make any converted test copy separately; this keeps a useful reference for comparing the output.
| Approach | When it fits | What to verify |
|---|---|---|
| Concat demuxer | Inputs are compatible and you want to join packets without a processing stage | Matching streams, codecs and time bases; correct paths and duration metadata |
| Concat filter | Inputs need processing, or you need a re-encoding route to handle differing parameters | Explicit mapping, filter inputs, output codec settings and the resulting file or stream |
Review durations and boundary timestamps
A playlist entry does not guarantee that the next track begins exactly where your ears expect. The concat demuxer relies on duration information to place later inputs. If a file reports an inaccurate duration, or if durations differ in how they are represented, timestamp gaps or artifacts may appear around a boundary. A brief silence can therefore be a timing issue even when every file is present and decodable.
Compare the reported duration of the suspect file with its actual playback length. Look at the FFmpeg log around the end of that input and the start of the next; note discontinuities, unexpectedly large timestamp changes or a new stream appearing at an unexpected point. Do not add duration directives by guesswork. The concat script's duration directive can override duration metadata where appropriate, but an inaccurate override can shift later timestamps rather than repair them.
Test one boundary at a time. Make a short copy of the playlist that includes the preceding track, suspect track and following track. Record the audible transition locally and compare it with the timestamps in the log. If the problem moves when the sequence changes, that is useful evidence. If it consistently occurs at the same media time inside a file, the file itself or its decode path is more relevant than the previous file's duration.
Avoid adding arbitrary silence, trimming or fades until you know whether the issue is a gap, a cut, a quiet passage or a lost input. Those symptoms can sound similar during a casual listen. A channel that uses recorded sermons or other long-form material may also benefit from comparing its sequencing assumptions with a continuous recorded-sermon stream, while keeping the underlying audio-file checks specific to its own playlist.
Compare local playback with the outgoing stream
A local test answers a narrower question than a YouTube test. It can show that FFmpeg reads and emits the audio sequence, but it does not prove that the outgoing stream is configured correctly or that YouTube receives the same material. Conversely, a gap heard in a browser may come from playback buffering or monitoring conditions rather than from the source file. Use the same track sequence and note the location of the transition in each observation.
For RTMP or RTMPS output, follow the codec and stream settings shown for your broadcast in Live Control Room and consult YouTube's current encoder settings and recommendations. YouTube recommends RTMPS. Its guidance includes codec, keyframe and bitrate recommendations that vary with the output format; do not copy a bitrate intended for a different resolution, frame rate or codec. Its audio guidance also lists stereo settings such as 44.1 kHz and 128 Kbps as recommendations, not a diagnosis for a skipped playlist entry.
YouTube's HLS ingestion is a different workflow from the RTMP(S) template here. If your Live Control Room setup uses HLS, follow YouTube's current HLS instructions and use an encoder configured for that protocol rather than treating an FLV output example as interchangeable. Keep protocol choice, encoder output and the actual stream health messages together in your test notes. A change to the audio playlist cannot resolve a mismatch in the outgoing protocol.
A still image supplies a video stream while the playlist supplies audio. This template illustrates the mapping, not a required visual choice or universally suitable quality setting:
ffmpeg \
-loop 1 -framerate 30 -i cover.png \
-re -stream_loop -1 -f concat -safe 0 -i audio.ffconcat \
-map 0:v:0 -map 1:a:0 \
-c:v libx264 -tune stillimage -pix_fmt yuv420p -r 30 \
-g 60 -b:v 2500k -maxrate 2500k -bufsize 5000k \
-c:a aac -b:a 128k -ar 44100 \
-f flv "<YouTube RTMPS stream URL>"
In this template, -stream_loop -1 requests indefinite looping of the playlist input, and -re reads file input at its native rate. Both appear before the playlist's -i because they are input options. The first input is the looping image; explicit -map options select its video and the playlist's audio. The URL placeholder is not a usable destination: use the RTMPS URL and stream key supplied for your broadcast, and never publish the key in logs or screenshots.
The example's video bitrate and other output values are not universal recommendations. Choose output settings for the visual format and current YouTube guidance shown for your stream. Once you have evidence that the audio is present locally but absent at YouTube, inspect the outgoing audio mapping, encoder messages and stream health before changing playlist compatibility settings. For a separate comparison of visual-looping workflows, see OBS and FFmpeg for looping videos on YouTube Live.
A file-driven FFmpeg process also depends on the computer and process that keep it running. If that particular operational burden is the problem, StreamNeo removes the need to leave your own computer running by taking an uploaded video into a YouTube live stream; it does not replace diagnosing a missing track in a playlist you intend to run through FFmpeg.
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 -stream_loop -1 loop the playlist forever?
It requests infinite looping of that input, provided it is placed before the playlist input in the command. It does not establish that every entry is readable, compatible or audible, so check the logs and test the sequence. The broadcast still depends on a valid output configuration and a running process.
Why does a track play alone but disappear in the playlist?
That points to evidence worth checking at the boundary, including stream compatibility, duration metadata, path resolution and timestamp messages. It does not prove which of those is responsible. Compare a short sequence containing the neighbouring tracks and retain the exact command and log.
Can I send only audio to YouTube Live?
The example uses a still image because a conventional encoder stream needs a video source as well as audio. Choose a visual appropriate to your channel and confirm the currently available settings in Live Control Room. Do not assume an audio-only playlist supplies video.
Should I use the concat demuxer or concat filter?
Use the demuxer when the input streams are compatible and joining packets without re-encoding suits the job. Use a filter-based re-encoding route when you need to process or standardise inputs. Decide from the file properties and intended processing, not from the fact that one track was skipped.