Before you prepare a video for a YouTube loop stream, check its encoded video codec and reported frame rate with either a command-line tool or a graphical app. This tells you useful facts about the local file; it does not prove that a live encoder, a loop setup or YouTube Live will accept it.
If you are comfortable in a terminal, FFprobe can return specific stream fields. If you would rather use menus, VLC shows codec information, with MediaInfo as a useful fallback when you need more detail. In either case, treat inspection as one preparation step, then test the complete live workflow independently.
What a file check can and cannot tell you
A video file has a container and one or more streams. MP4, for example, names a container; H.264 names a video codec. The extension alone does not tell you which codec is inside, so inspect the video stream rather than relying on a filename ending in .mp4 or .mov.
A probe can report the stream’s codec and frame-rate fields, and may reveal that a file contains multiple video, audio or subtitle tracks. Those details help you decide what to use as a source and whether it matches the assumptions of your next step. They do not tell you whether a particular encoder can decode it in real time, whether a loop will restart cleanly, or whether a live broadcast will remain stable overnight.
That distinction matters for an always-on channel. A file may play in VLC but behave differently when opened by OBS, FFmpeg or another encoder; the encoder’s version, settings, hardware and input method all affect the result. A successful metadata check is not a compatibility test. Nor does it establish that YouTube will accept or maintain a live stream.
Use inspection to reduce uncertainty, not to certify the whole chain. If a devotional video reports an unexpected codec, you can investigate before scheduling a night-long broadcast. If it reports the codec and rate you expected, you still need to test the actual stream configuration, including the loop boundary and audio.
Inspect codec and frame rate with FFprobe
FFprobe is part of the FFmpeg project. It can read a media file and print details about its streams in plain text, JSON and other formats. If you already have FFmpeg tools installed, try this command for the first video stream of an MP4:
ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,r_frame_rate,avg_frame_rate -of default=noprint_wrappers=1 input.mp4
Replace input.mp4 with the actual path to your file. If the filename or path contains spaces, enclose it in quotation marks, for example "/home/me/Videos/Evening Aarti.mp4". On Windows, use the path format your terminal accepts and quote a path with spaces, such as "C:\Videos\Evening Aarti.mp4".
The output should show codec_name, r_frame_rate and avg_frame_rate. The -select_streams v:0 part asks for the first video stream; it keeps the output focused if the file also contains audio or other tracks. -show_entries selects the fields to print, and the output option keeps the result relatively compact. The FFprobe documentation explains stream selection, field selection and output formats.
For structured output you can replace the final option with -of json. JSON is useful if you want to save the result with a project note or compare several files consistently. To see all stream fields rather than just the selected fields, use:
ffprobe -v error -show_streams -of json input.mp4
This can help when a file has multiple video tracks and you need to identify which is the intended picture. You can also add -show_format to include container-level information. Keep the layers separate in your notes: the container may be MP4 while the video stream is H.264, and the audio stream has its own codec.
If the command is not recognised, FFprobe may not be installed or available on your command-line path. Avoid downloading a random executable just to get a result; use a trusted source for the software and follow its current installation instructions for your operating system. If installation is more work than you need for a one-off check, use the graphical route below.
Check file properties in a graphical app
In VLC, open the file and choose Tools > Codec Information. The window reports information about the media streams. VLC’s menu labels can differ by operating system or version, so if you do not see the same route, look for codec information in the menus or consult the VLC documentation. VLC notes that its display may not identify a codec in enough detail in some cases.
A graphical check suits a quick inspection: open a file you can already play, find its stream details and record what the app displays. It does not require you to remember command flags. The trade-off is that the app may present fewer fields, or label them differently from a probe tool. If the rate is missing or the codec description is too broad for your decision, try MediaInfo, which VLC’s documentation points to for fuller specifications.
When using any app, check that you opened the actual local file you plan to stream, not a proxy, converted copy or similarly named version. If you have a folder of exports, filenames can be misleading. Keep a short note containing the filename, the reported video codec and both reported frame-rate values when available. That prevents a later decision being based on the wrong version.
A terminal and a GUI are not competing measures of correctness. FFprobe is convenient for repeatable, selected fields and machine-readable output; VLC is a straightforward menu route; MediaInfo can be helpful when you need more descriptive detail. The sources establish what these tools can display, not a controlled comparison of how easy they are on every computer.
| Approach | Useful when | Detail and trade-off |
|---|---|---|
| FFprobe | You want repeatable fields or need to select a particular stream | Compact output is precise, but you must use a terminal and have the tool available |
| VLC | You want a quick menu-based check of a file you can open | Low-friction for a basic check; some codec details may not be identified fully |
| MediaInfo | VLC leaves an important field unclear | Can show fuller specifications; install and use it from a trusted source |
Read the reported codec and FPS
The codec_name field is a machine-friendly name for the encoded video format. It may show values such as h264 or hevc; do not assume a particular value before checking. A filename ending in .mp4 tells you about the container, not whether the picture is encoded as H.264, HEVC or something else.
FFprobe reports r_frame_rate and avg_frame_rate as separate values. Preserve both as reported. A value such as 30000/1001 is approximately 29.97 frames per second, but its rational form is useful when you are matching a source or a project setting. Do not round it to 30 and discard the original value if the distinction could matter to the encoder or edit.
If a rate appears as 0/0, N/A or blank, or if the two fields differ, do not guess which one is the definitive rate. Check the same file with another tool, such as MediaInfo, and consider whether the file uses variable frame timing or has an unusual stream structure. If the distinction matters, FFprobe can expose per-frame information with -show_frames, but this produces much more output and is not usually the first check to make.
For a file with more than one video stream, confirm which stream the selected field describes. Audio needs separate attention if your workflow depends on a particular audio track: select audio streams with FFprobe’s media-type selection rather than assuming the video result describes the whole file. If a channel has a silent visual loop or multiple language tracks, note that separately from the video codec and FPS.
A clear report is still a report about the file as stored. It cannot describe every conversion, scaling or timing change that a live encoder might apply after reading it. If a result looks surprising, compare the output with the source and the intended export settings before changing settings blindly.
Resolve mismatches before preparing the stream
First establish what you need to match. If you are using an existing video as-is, note its codec and rates, then check the documentation for the encoder or workflow that will read it. If you are exporting a new master, use the source and project settings deliberately rather than forcing a familiar FPS value onto every file.
YouTube’s recommended upload encoding settings say to encode and upload at the same frame rate as the recording. They list 24, 25, 30, 48, 50 and 60 frames per second as common rates while allowing other rates. The same guidance recommends MP4 as a container and H.264 as the video codec for its stated upload settings. Those are upload recommendations, not proof that every live loop configuration will work or universal acceptance requirements.
The YouTube guidance also recommends deinterlacing interlaced content before upload. If inspection or an editing app identifies an interlaced source, do not treat a progressive export as a simple codec change: choose a deinterlacing approach appropriate to the material, then check the resulting file again. A field-order or motion problem can be visible even when the codec name and nominal frame rate look plausible.
If the codec is unexpected, decide whether to use a compatible source or make a new export. A conversion can make a file more suitable for a particular workflow, but it can also alter frame timing, picture quality, audio or file size. Keep the original, export a short test copy, and inspect that copy before replacing the file in a playlist. Re-encoding every file in a library without a specific reason can add work without solving the actual playback problem.
For a channel with recurring exports, keep a simple preflight record: source filename, container, video codec, both reported frame rates, audio presence and any conversion made. This is especially useful if several people prepare videos or if you reuse a file months later. If you are also documenting an FFmpeg-based broadcast, a guide to running an FFmpeg YouTube stream with systemd can help you think separately about the running process and the media file it reads.
Test the full YouTube loop workflow separately
After inspecting the file, test the real path from file to broadcast. Open the intended file in the encoder or stream tool, confirm that the expected video and audio appear, and run a private or otherwise controlled test using your actual settings. Check that the stream starts, plays long enough to reveal decoding trouble and returns to the beginning as intended. Watch the transition at the loop point; an abrupt black frame, repeated audio gap or frozen image may not be visible in metadata.
Test on the same computer and with the same input method you expect to use in production. A file may behave differently when read from a network drive or removable disk than from a local folder. Also verify that the broadcast uses the intended stream key and channel, and consult YouTube’s current live streaming requirements and setup guidance before going public. A successful file probe, a local playback and a brief encoder preview each answer different questions.
If the computer must remain on continuously, include power, network and restart behaviour in your test plan. Readers running an FFmpeg setup on a small board may find the Raspberry Pi power-use guide relevant after the codec check, because resource use is a separate concern from file metadata. For playlist-based devotional programming, see the M3U playlist guide for a Punjabi bhangra stream; a playlist’s sequencing behaviour likewise needs testing beyond inspecting one item.
A test that succeeds is useful evidence for that tested combination, not a guarantee for all future runs. Keep a copy of the known-good settings and note the exact media file tested. When you change the encoder, source file, bitrate, loop method or connection, repeat the relevant part of the test rather than assuming the earlier result still applies.
For a setup where keeping a local computer running is the specific obstacle, StreamNeo removes that particular task: you upload the video once, provide the YouTube stream key, and the broadcast can continue with your computer switched off. You still need to prepare a suitable file and check the live channel and content yourself; the file inspection described here does not establish that your stream will be accepted or work as intended.
If you want to compare ways of operating the channel after checking the file, use the pricing page and trial information to decide whether the workflow fits your needs.
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
How do I check a video file codec and FPS?
Use FFprobe to select the video stream and print codec_name, r_frame_rate and avg_frame_rate, or open the file in VLC and choose Tools > Codec Information. If the result is ambiguous, check with a second tool rather than choosing a rate by guesswork.
Is MP4 the same thing as H.264?
No. MP4 is a container that can hold streams, while H.264 is a video codec. Inspect the video stream to learn the codec; the extension by itself is not enough.
Does checking FPS prove my video will loop on YouTube Live?
No. Inspection reports information about the local file, not the behaviour of your complete encoder and live setup. Test the actual file, settings and loop boundary separately, and check YouTube’s current official guidance.
What should I do if the reported frame-rate fields differ?
Keep both reported values and check the file with another tool such as MediaInfo. If the distinction affects your workflow, investigate frame-level timing or the source and export settings; do not invent one definitive FPS from conflicting output.