When an FFmpeg gaming VOD stream reports “Invalid data found when processing input”, the message tells you that FFmpeg could not parse data at an input stage; it does not identify a single cause. To fix the playlist, first find the exact input that failed, then inspect that resource and its response rather than adding a guessed flag.
This applies whether you are opening a local M3U8, reading a remote HLS playlist, or trying to capture a VOD. Work through the main playlist, any variant playlist, and the media segments it references. A failure at one of those stages calls for a different check.
Capture the complete FFmpeg log
Keep the full command and the complete console output from a failed run. Do not retain only the final line: earlier messages often show whether FFmpeg opened the initial URL, selected a demuxer, followed a nested URL, or started reading a segment. Redact stream keys, signed query strings, cookies, and other credentials before sharing a log, but preserve the structure of the URLs and the surrounding error messages where possible.
Run the command again with enough diagnostic output to see the sequence of events. For example, you can add -loglevel warning for a concise record, or use -loglevel verbose when the warning-level output does not expose which resource was reached. Keep the original command too, since options before and after -i can have different effects. Avoid changing several inputs and options at once; doing so makes it harder to connect a changed result to a specific cause.
Read the log as a sequence, not as a verdict. An error immediately after opening the main M3U8 points you towards format recognition, playlist text, or its response. An error after a variant or segment URL appears directs attention to that child resource. A protocol-whitelist message is different from a parser message, and an HTTP response containing an access-denial page is different from a malformed media playlist.
Write down the exact input URL or filename associated with the first relevant failure, and whether it is the main playlist or a referenced child. If the log does not name a child URL, inspect the playlist and test its references individually. The aim is not to guess at the error message but to identify the earliest input FFmpeg cannot read.
If your eventual goal is a continuous YouTube broadcast rather than an FFmpeg capture, keep the ingest and publishing workflow separate from this file-level diagnosis. The guide to streaming multiple pre-recorded videos continuously covers the broadcast side; it does not replace verifying that each source file or playlist can be read.
Identify the exact failing input
An HLS arrangement can involve more than one text playlist. The URL you pass to FFmpeg may be a master playlist that points to a variant playlist, which in turn points to media segments. FFmpeg’s HLS demuxer documentation describes the demuxer as presenting streams from variant streams. That means the initial URL is not necessarily the last resource FFmpeg needs to read.
Use the log to make a simple map: initial input, any playlist it references, then the segment that fails. If the first URL is a local file, note its path and inspect that file. If it is remote, test the actual URL from the same machine and environment where FFmpeg runs. A browser test from another device or network may use different credentials, cookies, or routing and cannot establish that FFmpeg receives the same response.
Treat the error text as FFmpeg’s invalid-data report, not a diagnosis. The bytes might be incomplete, damaged, in a format that is not recognised, or not media at all. A playlist may also be malformed. Those are possibilities, not conclusions: the exact cause depends on the failing input, its content, and the log. The FFmpeg error-code listing identifies the invalid-data code, but it cannot tell you what a particular URL returned.
Separate input recognition from output writing. Options such as -c copy affect what happens after FFmpeg has parsed packets; they cannot make unreadable playlist text or a failed segment parse correctly. Likewise, changing the output container does not establish that the input is valid. First reproduce the input failure with the smallest command that still reads the same resource.
Inspect the playlist and HTTP response
Open the playlist as text and check that it contains playlist directives and plausible references rather than an HTML page, an empty response, or an error message. For a local M3U8, inspect the exact file FFmpeg opened, not an older copy with the same name. Confirm that the referenced child paths are the ones you intend: relative paths are interpreted in relation to the playlist location, so a copied playlist can point somewhere different when moved.
For a remote playlist, inspect the HTTP response from the FFmpeg machine. Check the status and the returned body, using a method that preserves whatever authentication the URL requires. A successful connection alone is not proof that the body is media: a server can return a login page, access denial, or other error document instead. Do not publish private signed URLs or headers in support posts; they can grant access until they expire or are revoked.
If you have access to response headers and body, compare them with what the log implies. An HTTP denial or missing resource calls for resolving access or the URL, not changing HLS demuxer settings. If the response is a playlist, inspect its child entries next. If it is a segment, establish whether it contains the expected media data before pursuing a playlist-format theory.
A main playlist can parse correctly while one child has gone missing or is no longer accessible. For a gaming archive assembled from multiple clips, check every referenced item and the playlist version that points to it. Do not assume that a URL is permanent because it worked previously; access links can change or expire, and the available evidence should decide the next step.
Probe the same input with ffprobe
Run ffprobe against the exact input that failed, rather than a parent playlist or a different copy. A useful first check is:
ffprobe -v warning -show_format -show_streams "playlist.m3u8"
Replace the example with the exact local path or URL from the log. If FFmpeg failed on a variant playlist or segment, probe that resource directly when its format and access method allow it. Keep any required authentication available to the probe, and take care not to put sensitive tokens into a shell history or a shared log.
If ffprobe reports a format and streams, that is evidence that this probe could recognise the input; it does not prove the entire HLS chain is readable or that every child will work during a full run. If it returns the same invalid-data error, compare its log with the FFmpeg run. If it fails at a child URL, follow that URL back to the playlist entry and inspect the response there.
When probing succeeds on the same resource but the original command fails, compare the input-related options and environment rather than concluding that the playlist was repaired. FFmpeg and ffprobe may be using different command-line options or different authentication context. Reproduce the original conditions as closely as possible, changing one relevant input setting at a time.
This staged approach is also useful before building an overnight workflow. The overnight video-encoding guide addresses a separate operational concern: it is worth confirming that a source is readable before committing time and disk space to a long job.
Test explicit HLS format when appropriate
If the failing input is an HLS .m3u8 and the log suggests FFmpeg did not recognise its format automatically, test explicit HLS demuxer selection:
ffmpeg -f hls -i "playlist.m3u8" -c copy "output.mp4"
For a remote input, substitute the actual playlist URL, and run it from the environment that has access to that URL. The -f hls option tells FFmpeg which input demuxer to try; it is a diagnostic test for format detection, not a universal repair. It cannot turn an error page into a playlist or restore a missing segment.
Compare the result with the original run. If explicit selection gets past initial recognition, continue checking child playlists and segments rather than treating the first improvement as proof that the whole input is sound. If the same invalid-data error appears on the main playlist, inspect its bytes and response. If it moves to a child URL, the failure has been narrowed and that resource needs attention.
Do not generalise from a single example of a playlist that worked after adding -f hls. Playlist syntax and content matter, and a particular community example does not describe every valid HLS arrangement. In particular, a command option cannot make invalid playlist entries valid. Use the actual log and playlist text to decide whether the test changed format recognition or merely moved the point of failure.
Check child-resource URLs and responses
When the parent playlist is accepted but a child fails, copy the exact child reference and resolve it according to the playlist’s location. If it is relative, do not treat it as a standalone path without its base. Check whether the resulting URL or file exists, whether it returns media rather than an error body, and whether the same access credentials are available to FFmpeg.
Distinguish child playlists from media segments. A variant playlist should be inspected as playlist text and its own references followed. A media segment should be checked as media data. If a URL is expired or access-controlled, address that access condition at its source; widening a protocol or extension setting cannot recover a resource the server will not provide. If a referenced file has been removed, update the playlist or restore the file rather than trying to make FFmpeg parse a response that is not there.
Do not concatenate HLS playlist URLs using the concat: protocol, for example concat:a.m3u8|b.m3u8. That protocol joins resource contents; it does not merge playlists while preserving the original base URL for every relative segment. Nicolas George explains this failure mode in an FFmpeg-user mailing-list discussion: once playlist text is concatenated, relative segment references can resolve from the wrong base and lead to a failed first segment. Use the HLS demuxer for HLS inputs, and diagnose each playlist’s references separately.
If the actual task is to make a continuous sequence from independent recordings, do not assume that joining their M3U8 text is the right operation. Check how the recordings and their playlists are structured first. The playlist-streaming guide for prayer meetings is about planning a YouTube programme, rather than using concat: to rewrite HLS inputs.
Review protocol and extension policy
Only investigate protocol restrictions when the log points to a nested-protocol or whitelist failure. FFmpeg documents protocol_whitelist as a comma-separated list and notes that nested protocols have restrictions in its protocol documentation. A local playlist may refer to HTTPS resources, and the exact required schemes depend on those references and the installed FFmpeg build. Check available protocols with ffmpeg -protocols and consult the documentation for that build.
If a whitelist is genuinely indicated, allow only the schemes needed for the known playlist and child resources. Do not reflexively set ALL: doing so expands what the process may open without explaining why the input failed. Put input options in the appropriate position before the relevant -i, and rerun against the same input so that the comparison remains meaningful.
The HLS demuxer also has extension-related controls, including allowed_extensions and extension_picky. Investigate them only when the log points to a child segment being rejected because of its extension. The HLS documentation explains that extension-picky mode can block disallowed extensions from probing and requires matching extensions except for MPEG-TS. Prefer a correct, narrow whitelist over relying on file extensions to identify content.
Neither a protocol allowance nor an extension allowance changes the bytes at a URL. These settings cannot fix a removed segment, an authentication page, or damaged media. If the log does not point to the relevant restriction, leave the setting alone and return to the failing input’s response and content.
A useful hand-off note records the command, FFmpeg version, failing input stage, relevant uncut log lines, playlist entry, and response observed. That is more useful than a list of flags that happened to be copied from another case. If the issue remains unclear, include a redacted sample of the playlist structure while keeping private tokens and personal access details out of it.
Before committing to a separate always-on YouTube workflow, decide whether your actual need is to debug a live FFmpeg input or to broadcast a prepared video without keeping your computer running. In the latter case, StreamNeo removes the need to leave a local machine running once the video and YouTube channel are ready; it does not diagnose or repair an invalid M3U8.
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 “Invalid data found” prove that my M3U8 is malformed?
No. It means FFmpeg could not parse data at the input stage that failed, but the data might be a playlist, a child resource, or a non-media response. Use the complete log and inspect the exact bytes or HTTP response before deciding the cause.
Should I always add -f hls?
No. Try it when the input is an HLS playlist and automatic format detection appears to be the failing stage. If a child segment, access response, protocol restriction, or playlist entry is the problem, explicit demuxer selection will not address it.
Can concat: safely join two M3U8 URLs?
No. It concatenates resource contents and can cause relative segment references to resolve against the wrong base. Use the HLS demuxer for HLS inputs and inspect each playlist and its child resources.
What should I send when asking for help?
Include the exact command, FFmpeg version, complete relevant log, and whether the failure is on the main playlist or a named child resource. Redact signed URLs, keys, cookies, and other credentials, and say what response or playlist content you observed without sharing access secrets.