How to Fix an FFmpeg Playlist Skipping Videos in a YouTube Live Stream

A video that appears to be skipped in an FFmpeg YouTube live stream is usually a playlist, file, compatibility or timestamp problem rather than a YouTube playlist problem. Start by identifying how FFmpeg reads the files, then test the files and transitions locally before changing the live command.

If you are using the concat demuxer, the listed files must have compatible streams and reliable duration information. If the files differ, re-encode them to a common format or use FFmpeg’s concat filter, which is intended for workflows that re-encode during concatenation.

Identify what kind of playlist the command uses

The word “playlist” can describe several different things in an FFmpeg setup. The repair depends on which one is actually in your command.

A concat-demuxer playlist is usually a plain text file passed with syntax similar to this:

file '/media/01.mp4'
file '/media/02.mp4'
file '/media/03.mp4'

The command then refers to that file with an input such as:

ffmpeg -f concat -safe 0 -i playlist.txt ...

This is not the same as an HLS M3U8 playlist, a shell loop, a media-player playlist or a script that launches a separate FFmpeg process for every video. Each approach has different rules for ordering, paths, looping and timestamps.

For a concat-demuxer script, FFmpeg opens the listed media files as parts of one logical input. It expects those files to have the same streams, including matching codecs and time bases. The official concat demuxer documentation states that all files must have the same streams, rather than treating the playlist as a place to combine arbitrary videos.

Before changing flags, copy the exact input portion of your command and answer these questions:

Is the input a concat-demuxer script or another playlist format?
Does the script contain the file you expected at the position where the jump occurs?
Is FFmpeg reading the script once, or is another loop repeatedly starting the command?
Does the log show FFmpeg opening the supposedly skipped file?

This first distinction matters because adding -stream_loop, -re or timestamp flags to an HLS input will not repair a missing path in a concat script. It is also why a command copied from a different playlist method may appear plausible while solving the wrong problem.

Capture the transition before changing the command

Do not begin by adding several options at once. You need to know whether FFmpeg skipped a file, opened it but could not decode it, or sent it correctly while YouTube later displayed a frozen or damaged transition.

Make a short copy of the command and run it with output directed to a local file instead of YouTube. Keep the same playlist and output settings where possible, but use a short test output that you can inspect. Save the console output as well. The useful evidence is the point where one file ends and the next should begin.

Compare three things:

The order in the text script.
The order of the Opening or input-report messages in the FFmpeg log.
The order of pictures and sound in the resulting test file.

If the log never opens a listed file, investigate the path, permissions, quoting and playlist syntax. If it opens the file and reports decoder errors, investigate that file and its streams. If it opens the file and decodes it normally but the output jumps at the boundary, inspect durations, timestamps and stream compatibility.

A YouTube viewer’s description of a “skipped” video does not identify which of these occurred. A black section, a frozen final frame, a rapid jump to the next clip and a silent transition can have different causes. The command, the FFmpeg version, the media metadata and the log around the transition are needed for a command-specific diagnosis.

This evidence-first approach also helps with problems that are not caused by concatenation. For example, a continuous stream can look broken when the local encoder is still running but the outbound connection is dropping packets. If FFmpeg processes the transition correctly, check the local output before editing the playlist again.

Check every listed file and path

Read the playlist as FFmpeg reads it, not as a file manager displays it. A path that works from an interactive shell may fail when a service, scheduled task or container starts FFmpeg from a different working directory.

For a concat script, use explicit paths while diagnosing. If the path contains spaces or special characters, keep the required quoting and check that the quotes are part of valid concat-script syntax. A relative path such as file 'videos/01.mp4' is interpreted in relation to the concat input context, not necessarily the directory you had in mind when launching a service.

Check each entry for:

spelling and capitalisation, particularly on case-sensitive systems
the file extension and actual file type
readable permissions for the account running FFmpeg
moved, renamed or partially copied files
unusual characters in the path
duplicate entries that may look like a skip
a final line that is incomplete or accidentally joined to the next line

Do not check only the file that appears to be missing. A damaged preceding file can cause FFmpeg to stop decoding cleanly at its end, making the next file look as if it was skipped. A file can also exist and be readable while containing a stream that FFmpeg cannot decode with the selected input and output workflow.

A simple way to isolate path problems is to create a temporary playlist containing just the suspect file. If FFmpeg cannot open that one-entry playlist, the issue is not the transition from the previous video. If it opens and plays, add the preceding file and then the following file. This narrows the failure to an entry or a boundary without disturbing the complete live schedule.

For a long-running channel, keep media in a stable directory and avoid changing filenames while FFmpeg is reading them. If you update the contents of a playlist, make a new copy and replace it deliberately rather than editing a line while the process may be reading it. For a broader workflow, see the guidance on adding new videos to an always-on YouTube stream.

Verify concat demuxer stream compatibility

The concat demuxer is designed for files that already have compatible streams. It is not a general conversion layer. Matching only the file extension, resolution or visible appearance is not enough.

Inspect every input with ffprobe, which is distributed with FFmpeg. A useful starting point is:

ffprobe -v error -show_entries \
  format=duration:stream=index,codec_type,codec_name,profile,width,height,\
  sample_rate,channels,time_base,r_frame_rate \
  -of default=noprint_wrappers=1 input.mp4

The exact output varies with the media. Compare the video and audio streams between files. Pay attention to whether one file has no audio, whether audio uses a different sample rate or channel layout, whether the video codec or pixel format changes, and whether frame rate or time base differs.

The important requirement is the complete stream arrangement, not just “both are MP4”. Two MP4 files can contain different codecs, different audio properties, different frame timing and a different number of streams. They may play perfectly by themselves and still be unsuitable as direct concat-demuxer inputs.

The same applies to files exported from different phones, editing applications or download tools. One clip may use variable frame timing while another uses a fixed rate. One may have an attached data stream or an unusual time base. These differences can surface only at the boundary, where the demuxer moves from one file’s timestamps and stream descriptions to the next.

If the streams do not match, do not treat -c copy as a normaliser. Stream copy avoids decoding and re-encoding; it does not make unlike inputs identical. The practical choices are to normalise the files first, use a concat-filter workflow that re-encodes them into a common output, or replace the incompatible source.

You can also compare your setup with this guide to fixing an FFmpeg YouTube stream black screen when looping videos. A black screen has other possible causes, but the same discipline applies: inspect the input and output rather than changing several flags blindly.

Inspect duration and timestamp assumptions

Even when the stream layouts look compatible, the reported duration of a file affects where FFmpeg places the next one. The concat demuxer adjusts timestamps across the joined input, and the duration assigned to each file helps determine the starting point of the following file.

A duration can be wrong because a file was truncated, because metadata is inaccurate, or because the duration was estimated from bitrate information. The result may be a pause, an overlap, a jump, a section of stale video or an apparent skip at a boundary. It is not safe to assume that a timestamp option will correct an inaccurate source duration.

Use ffprobe to compare the format duration with the stream durations and inspect the end of each suspect file:

ffprobe -v error -show_entries format=filename,duration \
  -show_entries stream=index,codec_type,duration,start_time,time_base \
  -of default=noprint_wrappers=1 input.mp4

Treat these values as evidence, not as proof that the entire file is healthy. A file may report a duration and still have a damaged tail. Play the last part of the file separately, and check whether the final video and audio remain usable until the reported end.

Also inspect whether a file starts with a non-zero or unusual start time. Mixed start times can make a boundary appear mistimed, particularly when the input has been edited, recorded from a broadcast or remuxed several times. Do not remove timestamps without understanding what they represent; doing so can replace one boundary problem with another.

If the concat script explicitly supplies duration information, compare it with the actual media. A manually supplied duration that is too short can make the following file begin early. One that is too long can leave a gap or extend the previous timestamp range. If the script does not supply durations, FFmpeg still relies on the media’s timing information and may encounter the same underlying issue.

A useful test is to create a short output containing only the boundary between the last part of one file and the first part of the next. If the transition is wrong in that local output, focus on the two files and their metadata. If the local output is correct but YouTube shows the problem, continue with the encoder and stream-health checks rather than altering the playlist.

Test suspect clips individually

Testing each file alone is the fastest way to separate a bad input from a bad concatenation. Use the same decoder and, as far as practical, the same output settings as the live command. Do not rely only on a desktop player, because a player may conceal recoverable decode errors or compensate for unusual timestamps.

For a suspect input, create a short local output:

ffmpeg -v warning -i 'suspect.mp4' -t 60 \
  -c:v libx264 -c:a aac -f mpegts suspect-test.ts

The duration here is a test choice, not a repair for the source. Select a section that includes the beginning, a normal middle portion and, if the problem is near the end, the final section as a separate test. Watch the output and read the log for invalid data, decoder errors, missing audio, timestamp warnings or unexpected end-of-file messages.

Then test the same file with the output format used by your live pipeline. A file may decode correctly when copied into a local container but fail when it is decoded, scaled, converted or passed to an encoder. If the individual test fails, repair or replace that file before rebuilding the complete playlist.

Next, test the transition with a two-entry playlist. Use the file before the apparent skip and the file that should follow it. This removes unrelated entries and makes the log easier to read. Repeat with the preceding file and the suspect file if the boundary is unclear.

For a channel carrying devotional recordings, local news loops or study material, keep a small test set representing the real content. A playlist made from identical exports may work while a later clip from a different editor breaks the concat assumptions. Testing representative files before an overnight broadcast is more useful than testing only the first item.

If the individual files and the two-file transition are sound, build the playlist back up in small groups. When the failure returns, the new group contains either the problematic file or the transition that exposes a compatibility issue. This is slower than changing the command once, but it produces evidence you can use again when the library changes.

Choose re-encoding or another fix when inputs differ

There are two main concatenation strategies, and they should not be presented as interchangeable fixes.

Approach	Best fit	What it does	Main trade-off
Concat demuxer	Files with matching streams and reliable timing	Joins compatible inputs without re-encoding the media	Sensitive to differences in codecs, stream layouts and timing
Concat filter	Files that need conversion to a common output	Decodes and re-encodes the inputs while joining them	Uses more processing and may introduce generation loss

If the files already match, the concat demuxer can avoid unnecessary re-encoding. Preserve that simplicity, but verify the streams and durations rather than assuming matching filenames mean matching media.

If the files differ, normalise them before the live run. Decide on a common resolution, frame rate, video codec, pixel format, audio codec, sample rate and channel layout that suit your output. Convert each source to that profile, inspect the converted files, and use the normalised copies in the concat script.

The alternative is to use the concat filter in a command that decodes and re-encodes the inputs as one output. FFmpeg’s official FAQ documents the concat filter as the approach for concatenating while re-encoding. The exact filter graph depends on the number of inputs and whether each has audio, so do not copy a complex graph without adapting it to the actual streams.

For a long-running YouTube channel, pre-normalising a library can make the overnight command easier to understand and troubleshoot. It also moves the processing away from the live transition. The cost is extra storage, conversion time and another set of files to manage. Re-encoding during the live run avoids a preparation step but places more work in the process that must keep sending video continuously.

If the problem is a single damaged file, converting the entire library may be unnecessary. Replace or repair that input, then repeat the two-file transition test. If the media comes from several sources and incompatibilities are common, a documented normalisation profile is usually easier to maintain than repeated one-off fixes.

When a broadcaster needs to change recorded material without ending a live broadcast, the operational issue is separate from concat compatibility. The article on updating a YouTube live stream video without ending the broadcast covers that different scheduling and handover question.

Check the YouTube side after FFmpeg is clean

Once the local output shows the correct files in the correct order, inspect the live path. YouTube Live Control Room can show stream-health messages and encoder warnings that are not visible in the playlist itself. YouTube recommends monitoring stream health, checking the encoder output and keeping a local archive or recording for comparison in its live streaming troubleshooting guidance.

Compare the local recording with what viewers report. If the local recording contains the missing clip but the live preview freezes, the issue is likely after playlist processing: encoder load, output timing, connection quality or ingestion. If both local and live outputs omit the clip, return to the input and concat tests.

Review the output against the requirements for the actual YouTube stream. YouTube’s recommended encoder settings cover RTMP or RTMPS, supported video and audio codecs, constant bitrate, keyframe timing and bitrate choices. YouTube recommends a keyframe interval of two seconds and says it must not exceed four seconds. The suitable bitrate depends on the ingestion codec, resolution and frame rate, so use the official table for your chosen output rather than copying a generic value.

A stream that becomes unhealthy when a larger or more complex clip starts may be exposing an encoder or upload-capacity limit, not a skipped playlist entry. Check CPU or hardware-encoder load, available upload capacity and the output resolution and frame rate. Keep the test output representative of the real channel; a quiet still image does not exercise the pipeline in the same way as a clip with regular motion and audio.

For a 24/7 channel, also make recovery part of the diagnosis. A local process manager can restart FFmpeg after a genuine process failure, but it cannot repair a bad path or incompatible media. The guide to using systemd to restart an FFmpeg YouTube stream automatically is relevant after the input and output command are already reliable.

StreamNeo removes the need to leave your own computer running for this particular uploaded-file-to-YouTube workflow, but you should still validate the media and channel settings before relying on a long broadcast.

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

Why does FFmpeg skip only some files in a concat playlist?

The affected files may have different codecs, time bases, audio layouts or timing information, or one path may be invalid. Check the log to confirm whether FFmpeg opened the file, then compare its streams and duration with a file that works.

Can I fix a concat playlist by adding `-stream_loop`?

Not usually. Looping controls how input is repeated; it does not make incompatible streams match or correct inaccurate duration metadata. Establish whether the problem is a path, stream or timestamp issue before changing loop options.

Should I use the concat filter instead of the concat demuxer?

Use the demuxer when the inputs already meet its compatibility requirements and you want to avoid re-encoding. Use the concat filter when the inputs need to be decoded and re-encoded into a common output, then test the resulting stream locally before sending it to YouTube.

What should I collect before asking for help?

Provide the exact FFmpeg command, the playlist entries, FFmpeg version, ffprobe output for the affected files and the log lines around the transition. Also say whether the local output skips the clip or only the YouTube broadcast does, without assuming that both failures have the same cause.