A reliable check for a video file before adding it to an OBS playlist has three stages: inspect its structure with ffprobe, decode the whole file with FFmpeg, then play it in the OBS playlist configuration you intend to use. Each stage answers a different question, so success at one does not establish success at the next.
Keep the original file unchanged while checking a working copy. A probe can read enough metadata to report streams and container details without decoding every frame; a successful decode still does not guarantee that VLC and OBS will play the file correctly on your setup.
Keep an unchanged source copy
Start by preserving the file as it arrived or as it was exported. Do not overwrite it during diagnosis, rename it in a way that loses track of the original, or try a repair tool before you have a separate copy. If a test produces errors, you can then compare the candidate with a fresh download or export rather than wondering whether the diagnostic process changed it.
A practical folder arrangement might be source, checks, and playlist-test. Store the original in source, place a duplicate in checks, and use the duplicate for the probe and decode commands below. The folder names are only an organisational example; what matters is that the source remains available and you know which file you tested.
Check the file’s size and name before running anything. A zero-byte file, a visibly incomplete download, or a filename that differs from the expected item is a reason to retrieve it again before spending time on codec diagnostics. A plausible size is not proof that the content is healthy, but an obviously incomplete transfer is a simpler problem to eliminate first.
For files copied from a memory card, phone or external drive, wait for the transfer to finish and safely close the source device before testing. If a copy operation was interrupted, copy the file again to a local disk. A read failure can come from the storage or transfer path rather than from a video that was originally encoded incorrectly.
Keep a simple record of the candidate path, the commands used and any errors shown. This is particularly useful if a playlist contains devotional, lofi or local-news items that look similar by filename. If you later replace a file, note the new copy rather than assuming the old result applies to it.
Inspect streams and container with ffprobe
ffprobe is a useful first screen because it reports what FFmpeg can identify about a media file: container information and streams such as video and audio. It does not, by itself, decode the whole video or audio payload. The FFmpeg documentation describes its format and stream inspection options in the ffprobe documentation.
With FFmpeg tools installed, open a terminal or command prompt and run:
ffprobe -v error -show_error -show_format -show_streams "input.mp4"
Replace input.mp4 with the candidate’s actual path. Quotation marks matter when a path contains spaces, for example "D:\Videos\Morning Bhajan.mp4". On Windows, use the command interface where your installed FFmpeg tools are available; exact path syntax depends on whether you use PowerShell or Command Prompt.
Review the output rather than looking only for a final success message. Does it report a recognisable format? Is the expected video stream listed? If the file is meant to include sound, is an audio stream listed too? If the output says no streams were found, or includes an error opening the input, you have a reason to investigate before putting it into the playlist.
Missing audio is not automatically corruption. A silent background loop may be intended to contain only video, and an audio-only item may be intentional if you plan to handle it as such. Compare the result with what the export or download was supposed to contain. A mismatch between expectation and reported streams matters more than the mere absence of a particular stream type.
The output can also help identify a wrong file. If you expected a video but the reported format or streams do not match the source you meant to use, check the filename and path. An extension such as .mp4 is just a clue; it is not evidence that the contents are a valid MP4 video or that they will play in OBS.
A clean probe means FFmpeg could read enough structure to provide the requested information without reporting an error at that stage. It is not a full-file integrity test. Some failures only appear when a decoder reaches a damaged packet or later part of the file, which is why the next step is a complete decode.
Decode the full file with FFmpeg
For a deeper software check, ask FFmpeg to decode the candidate and send decoded output to a null destination rather than creating another media file:
ffmpeg -v error -i "input.mp4" -f null -
The command reads the input and attempts to decode it while discarding the output. It is a diagnostic pass, not a conversion. FFmpeg’s documentation explains its input, output and null-format options. The exact messages and behaviour can vary with the FFmpeg build and the codecs available in that build.
Let it reach the end. If the file is long, the command may take a while; stopping it part-way means you have only tested the portion it reached. Watch the terminal for errors as well as the process finishing. If you are checking a playlist of files, run the command separately for each candidate and keep results tied to the corresponding filename.
The check exercises substantially more of the media than a metadata probe, but its result has boundaries. It establishes what the selected FFmpeg build could decode from that file during this pass. It does not reproduce VLC’s playback route inside OBS, test every computer or decoder, or establish that the file will behave correctly when it is looped in a live scene.
A decode command that prints no errors is encouraging, but do not turn that into a guarantee. A decoder may handle or skip some damaged material, and a player using another library or version may behave differently. Conversely, a strict diagnostic mode may object to a bitstream irregularity that a particular player can tolerate. Treat the decode output as evidence, then test the actual playback route.
If a command reports an error, save the message before trying a new file. The wording can point to an unreadable input, a stream or packet problem, or a decoder limitation. Do not assume every warning means the entire file is unusable, and do not assume a command that reaches its end has reported every recoverable issue as fatal.
Interpret probe and decode results
The checks are graduated: each moves closer to the question you need to answer, but none should be mistaken for a universal certificate. A useful summary is:
| Check | What it tells you | What it does not settle |
|---|---|---|
ffprobe |
Whether the tool can inspect readable container and stream structure, and what it reports | Whether all video and audio data can be decoded from beginning to end |
| Full FFmpeg decode | Whether that FFmpeg build can read and decode the file during a complete pass, and what it reports | Whether OBS’s VLC playlist source will open and play it in your target configuration |
| OBS playlist test | Whether the intended OBS source and local playback setup can open and play the candidate | Whether every other player, computer or version will behave the same way |
Read exit status and log output together. A process exit status is useful, but it is not a substitute for inspecting messages. If FFmpeg logs errors but continues, that may indicate recoverable damage or a problem that deserves a closer look. If you need a stricter diagnostic, FFmpeg documents options including -xerror and -err_detect; its error-detection flags can make decoding stop on conditions it would otherwise tolerate.
Use strict flags cautiously. An error from a stricter mode is a reason to investigate the file and compare playback, not proof that every player will fail. Such modes are designed to expose conditions more assertively, and standards deviations or damaged packets can trigger a stop even where a player conceals or skips a problem. Start with the straightforward full decode, preserve the logs, and use strict settings only when the first result leaves a specific uncertainty.
No single result should be read without context. If ffprobe reports the expected streams but the decode reports errors near the end, inspect or replace the candidate rather than relying on the probe. If FFmpeg completes cleanly but OBS shows an error, look at the OBS and VLC route as well as the file. If OBS plays it but you hear no sound, check whether the file contains audio and whether the source’s audio is routed as expected.
When troubleshooting a broader live setup, distinguish media playback from the stream’s connection to YouTube. A file that fails locally in the intended OBS source is a different problem from an encoder disconnect. For the latter, the YouTube encoder error checklist covers a separate class of issues; it is not a substitute for checking the media itself.
Test playback in the intended OBS playlist
If you plan to use a playlist, test the playlist source you will actually use. OBS documents VLC Video as the source intended for playlists, with playlist controls; it depends on VLC being installed. The OBS Media Sources guide explains the distinction from Media Source. OBS also notes that if you use 64-bit OBS, you should install 64-bit VLC.
Make a temporary test scene rather than changing the live scene first. Add the candidate to the intended VLC Video source, open or play it, and check the start, a point in the middle and the end. Listen as well if the item is meant to contain audio. This is a practical check of the route you intend to rely on, not a vendor-certified protocol or proof that every future playback will be identical.
Use the same source settings, VLC installation, OBS version, and local file location you expect to use on air. A video that opens from a desktop player does not prove that the OBS playlist source has the required dependency or can access the same path. If you will run a playlist from an external disk or a network location, testing from that location can expose access or transfer problems that a local test would miss.
Check transitions between items too. A file may open alone but fail to advance or behave differently when the playlist moves from one item to the next. Confirm that the next entry starts and that the source’s loop or shuffle behaviour matches your planned use. OBS’s release notes have documented a fix involving a VLC playlist crash, which is a reminder that application version can matter; see the OBS Studio 29 release notes rather than assuming all versions behave identically.
An OBS error is not automatically evidence that the file is corrupt. VLC may be missing, its architecture may not match OBS, the path may be inaccessible, or a particular codec detail may not work in that playback configuration. Check the dependency and path before discarding a file that passed a full decode. Equally, a supported file extension is not a promise that every file with that extension will play.
If you normally run a 24/7 loop from a laptop, the test scene is useful even when the file passes all FFmpeg checks. The same laptop may later sleep, change power state or lose access to a drive, which are operational problems rather than corruption. This old-laptop loop setup guide addresses the separate question of keeping a local playback setup running. Do not let a successful file check stand in for checking the machine and source configuration.
Replace or re-export only when a check fails
If the probe cannot open the candidate, first verify that you are checking the intended path and that the copy is complete. Re-copy or download it from the original source, keeping the failing file aside until you have compared the new one. If the fresh copy probes and decodes differently, the problem may have occurred during transfer rather than in the original export.
If the probe reads the file but a full decode produces errors, try the fresh source or export before attempting repair. If you control the project, export a new copy using a broadly compatible format and test that new file from the beginning. Do not replace the preserved source until the replacement has passed the same checks; an export that looks similar is still a different candidate.
If FFmpeg decodes fully but OBS does not play the file, check VLC installation and architecture, OBS’s selected source, the file path and access permissions, then test a fresh export if those basics are sound. OBS supports several common media extensions, but compatibility depends on the actual file and playback route, not the suffix alone. The OBS sources guide provides context on source types. If a new export is needed, the YouTube Create editing guide may help with a simple re-edit workflow; it does not diagnose codec errors.
Avoid repair as the first response. Remuxing, transcoding or trying an automated repair may produce a playable file, but each changes the candidate and can hide which stage failed. Preserve the original, record the result, and make a separate repaired or re-exported copy only when there is a clear reason to do so. Then run the probe, full decode and OBS test again on that copy.
For a channel built from long-form loops, media readiness is only one part of preparing a dependable broadcast. If you use a cloud-hosted arrangement rather than leaving a local computer on, this guide to estimating monthly bandwidth for a cloud-hosted live stream covers an operational consideration separate from file integrity.
A graduated check is worthwhile because a bad item can interrupt a playlist after you stop watching it. Once your file and intended playback route are ready, choose the operating arrangement that fits your workflow.
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 a successful ffprobe result mean the whole file is good?
No. It means ffprobe could read enough structure to report the container and streams without the errors it was asked to show. Decode the whole file with FFmpeg, then test it in the intended OBS playlist configuration.
Does a clean FFmpeg decode guarantee playback in OBS?
No. FFmpeg and the OBS VLC playlist source use distinct playback routes, and local dependencies or settings can differ. A clean decode is useful evidence about that FFmpeg build, not a guarantee about VLC or OBS.
Does an OBS playback failure prove the file is corrupt?
No. Check that VLC is installed in the architecture OBS expects, that the source and path are correct, and that the file is accessible. A codec or version-specific playback issue can also be involved.
Should I repair a file as soon as a command reports an error?
Keep the original and first try to obtain a fresh copy or export. Use a separate copy for any repair or re-export, then repeat all three checks so you know whether the new candidate behaves differently.