When an FFmpeg YouTube stream exits at a playlist entry, first find out which component is reading that playlist: FFmpeg’s concat demuxer, an HLS manifest, or a downloader such as yt-dlp. Each reads a different kind of input, so there is no single FFmpeg flag that skips every bad item.
Capture the first error and test the named entry on its own before changing options. A missing path, an unreadable segment, a damaged packet and a dropped HTTP connection are different failures, and each calls for recovery at the layer that encounters it.
Start with the component reading the list
Write down the exact command that starts the broadcast, including each -i argument, any wrapper script and the first error printed before FFmpeg exits. The word “playlist” is not enough to identify the input. A YouTube page URL, an .m3u8 file and a text file passed to the concat demuxer are not interchangeable.
Look for the part of the command that consumes the item. If you see -f concat -i list.txt, FFmpeg is reading a local concat-demuxer list. If the input ends in .m3u8, FFmpeg may be reading an HLS manifest and requesting the segments it names. If a YouTube playlist URL is passed to yt-dlp, the downloader handles playlist selection and continuation; FFmpeg may only receive media streams or merge downloaded formats.
There may be more than one reader. A script could ask yt-dlp for each video, then use FFmpeg to combine or broadcast the result. In that case, determine which process printed the first relevant error. Changing FFmpeg’s input flags will not repair a playlist item that yt-dlp has failed to retrieve, and changing downloader settings will not fix an incompatible local file later in the chain.
This distinction also helps separate a source problem from a YouTube ingest problem. If FFmpeg is reading and sending valid media but the broadcast is not visible or stable, check the platform-side requirements in this YouTube Live troubleshooting guide. Keep that investigation separate from an error showing that a local input could not be opened.
Three workflows that look like playlists
A concat-demuxer list is a text file containing file entries and directives that FFmpeg reads in sequence. It can be useful when files are compatible and you want to join them without re-encoding. FFmpeg’s FAQ distinguishes the concat demuxer from the concat filter and concat protocol; their jobs and constraints differ. In particular, the demuxer does not turn arbitrary files into a uniform stream merely because they appear on consecutive lines.
An HLS manifest, often an .m3u8, describes a media presentation and points to media segments. FFmpeg reads the manifest and then requests the referenced resources. An invalid or expired segment reference is therefore not simply a bad line in a local file list: inspect the manifest and the segment request that failed. HTTP reconnection may help with certain transport failures, but it cannot make a stale reference point to a valid segment.
A YouTube playlist handled by yt-dlp is a playlist at the downloader layer. yt-dlp can select and retrieve items; FFmpeg may be involved in merging separate audio and video formats. The yt-dlp FAQ explains that YouTube can provide separate audio and video formats and describes FFmpeg’s role in merging them. If a playlist item cannot be fetched, investigate the downloader’s output and the item URL before treating the error as an FFmpeg media-decoding failure.
If the workflow turns recordings into a repeating broadcast, keep the preparation step visible and testable. This guide to automating a Tamil devotional playlist on YouTube Live can help you think about how the source sequence is assembled; the immediate job here is to identify which program reads each item and what it reports when one fails.
Preserve the first error and isolate the item
Do not diagnose the cause from the fact that the process exits. Save the complete command and enough log output to see the first failure, not only the final shutdown message. Record the item name or URL, any HTTP status, the time of failure and whether a second run stops at that same item. The first error often identifies the layer to investigate; later messages may only describe the consequences.
For a concat-demuxer list, make a backup before editing it. Check that the entry’s path is spelled correctly and that the file exists and can be read by the account running FFmpeg. If the path is valid, try the file separately with the same FFmpeg build and relevant options. Compare its streams with the other list entries rather than assuming that an extension such as .mp4 establishes compatibility.
For HLS, inspect the manifest around the failed reference and check whether the segment can be retrieved under the same conditions as the stream. A segment can fail because its reference is wrong or no longer available, because the media cannot be read, or because a request is interrupted. Keep the HTTP status and exact failed URL if the log shows them. Do not share credentials or signed URLs in a public support request.
For yt-dlp, note which playlist item was selected and whether the downloader reports a retrieval or extraction failure before FFmpeg starts. Test the item directly through yt-dlp where appropriate. If yt-dlp completes but FFmpeg fails while merging or reading its output, then investigate the media streams and the FFmpeg stage instead.
A repeated failure on the same item makes that entry or its source worth checking first. Failures that move among items can be consistent with a transient network problem, though that pattern alone does not prove the cause. The FFmpeg-user discussion of failed segments offers this kind of troubleshooting distinction; treat it as a clue, not a diagnosis.
Match recovery to the failure
Use an option only when it addresses the error you have observed. FFmpeg documents discardcorrupt as an input flag to “Discard corrupted packets” in its Formats Documentation. The commonly used spelling is -fflags +discardcorrupt before the relevant input. It can discard packets that the demuxer recognises as corrupted, which may lose some content. It does not promise to skip a missing file, invalid URL, malformed list entry or input that fails to open.
For native HTTP inputs, FFmpeg’s Protocols Documentation documents reconnect controls for selected network, end-of-file and HTTP failure cases. Options include reconnect, reconnect_at_eof, reconnect_on_network_error, reconnect_on_http_error, and delay or retry controls. Which controls apply depends on the input protocol and failure. A retry can make sense for a temporary interruption; it cannot repair a typo in a manifest or replace an unavailable playlist item.
For a list of local paths or URLs, the most direct recovery is often to validate entries before passing them to FFmpeg. A wrapper or playlist producer can check that each file or resource is available, then omit it, replace it, or report it for review. If your workflow processes items individually, it can record a failed item and continue with the next one rather than treating the whole batch as one indivisible operation. The trade-off is that you must decide what “continue” means: a skipped item may leave a gap in the programme, while a replacement may need editorial approval.
When concat entries open but fail because their stream layouts do not match, packet-discard and reconnect flags are beside the point. FFmpeg’s concat documentation says the input files need the same streams; it also warns that inaccurate durations can affect timestamps in later files. Check the concat demuxer section of FFmpeg’s documentation and consider re-encoding or using a concat-filter workflow when the inputs need normalising. That can take more processing and may reduce quality compared with stream copy, so test the finished output before using it in a live loop.
| Approach | Failure it targets | Main limit |
|---|---|---|
| Validate or filter entries before processing | Missing, stale or invalid paths and references | Requires control of the playlist producer or wrapper |
-fflags +discardcorrupt |
Corrupted packets the demuxer can read | Can lose damaged content; does not skip an entry that cannot open |
| HTTP reconnect controls | Selected transport, EOF or HTTP failures | Protocol-specific; cannot fix an invalid playlist reference |
| Re-encode or use a concat filter | Inputs with incompatible stream layouts | More processing and possible quality loss than stream copy |
The practical question is not “which flag skips corruption?” but “which program has the failing item, and can that program validate, retry, replace or continue safely?”
Test the next invalid item deliberately
A fix is not tested just because the current bad entry no longer stops the stream. Make a small test sequence containing a known-good item, the suspected failure and another known-good item. For a local concat workflow, do this with copies of the inputs and list, not the production playlist. Confirm whether FFmpeg opens the first item, reports the middle item and reaches the last one under the recovery logic you intend to use.
Then test a different failure class if the workflow needs to handle it. A path that does not exist is not the same test as a readable file with a damaged packet. An HTTP timeout is not the same as an invalid manifest URL. Avoid creating failures on a live channel: run the tests locally or against a private/unlisted test broadcast where practical, and keep the production process untouched until the expected behaviour is clear.
For HLS, use a test manifest or controlled source so you can verify what happens when a referenced segment is unavailable and when the request merely drops. For yt-dlp, check whether playlist processing continues to later items when one item cannot be retrieved, and confirm whether FFmpeg is invoked for that item at all. The relevant recovery setting belongs to the component that can observe and handle that failure.
Also test the case where recovery cannot proceed. A wrapper should not silently loop forever over a bad entry, and a retry policy should not obscure a permanent error. Decide what should be logged, when an item should be marked failed, and whether the broadcast should pause, skip or switch to a known-good fallback. Keep those decisions explicit rather than relying on an option whose behaviour you have not verified.
Confirm valid entries reach the broadcast
Once the test passes, verify the complete path from the playlist reader to YouTube. Check that the next valid input actually begins, that audio and video are present, and that timestamps continue in a sensible order. A process that remains alive is not sufficient evidence if it is outputting silence, a frozen picture or badly shifted media.
For concat-demuxer sequences, inspect the joined output or test broadcast for a discontinuity around the skipped or replaced item. Compare stream layouts and durations, particularly if you use stream copy. FFmpeg notes that inaccurate durations can create timestamp artefacts in later files. If the joined result is wrong, fix the inputs or use a normalising workflow before returning to the 24/7 schedule.
For HLS, confirm that the manifest reader requests a later valid segment after the failure and that the stream advances rather than repeating an old segment. For yt-dlp, confirm that the downloader moves to the intended later playlist item and that the subsequent FFmpeg step receives valid media. Keep the downloader log and FFmpeg log separate so you can tell which stage recovered.
Write down the tested failure and the observed result. Include the relevant command, FFmpeg version, input type, first error and recovery behaviour, but redact stream keys, cookies and private URLs. If the process stops again overnight, that record will be more useful than a remembered guess about what “corrupt” meant.
If your actual problem is keeping a prepared recording on air after your own computer is switched off, that is a separate operational choice from repairing a broken playlist entry. StreamNeo can remove the need to keep a local FFmpeg process running for a prepared video, but it does not change what a malformed source list means or make YouTube accept a stream automatically. For more background on making one recording repeat as a channel, see building a 24/7 channel from one video.
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
Will -fflags +discardcorrupt skip a bad playlist entry?
No. FFmpeg documents it for discarding corrupted packets that can be read, not for skipping every missing, malformed or unopenable input. Identify the reader and the first error before deciding whether it applies.
How do I skip a bad segment in an FFmpeg playlist?
First establish whether you mean a concat-demuxer list or an HLS manifest. For a local list you control, validate entries or process them with wrapper logic that can record a failure and continue; for HLS, inspect the manifest reference and segment request. Do not assume packet-discard or HTTP reconnect options will repair either kind of reference.
Why does FFmpeg exit on an invalid m3u8 segment?
The manifest may name a resource that is unavailable, or the request or media read may be failing for another reason. Preserve the first log error and test the referenced segment under the same conditions before choosing between fixing the manifest, retrying a transport interruption or addressing unreadable media.
Does a YouTube playlist use FFmpeg’s concat demuxer?
Not necessarily. If yt-dlp receives a YouTube playlist URL, it handles playlist items; FFmpeg may be used later to merge or process downloaded formats. Follow the logs to find which component fails, then apply recovery at that stage.