To check whether a source file is encoded as 4K at 60 fps, inspect the delivered file with ffprobe: confirm its video dimensions, read its frame-rate fields, and compare frame count with duration. Then review frames across the file for repeated motion or signs of enlargement.
Those checks describe the encoded file, not the camera history behind it. A file reporting 3840×2160 and about 60 frames per second may have been edited, upscaled or duplicated; YouTube playback quality is not a direct test of the source either.
What “true 4K 60fps” can mean
People use “true 4K 60fps” to mean different things. For a practical file check, separate three questions: what dimensions are encoded, what frame cadence the stream reports, and whether the material was originally captured by a camera at that resolution and rate. The first two can be inspected in the file. The third needs evidence about how it was made.
For YouTube, 4K commonly refers to a 3840×2160 frame, also labelled 2160p. A video stream can report those dimensions even when its pictures began at a lower resolution and were enlarged during editing or export. Likewise, a stream can have a nominal rate near 60 fps while containing frames repeated from a lower-rate source. File properties are useful evidence, but they do not settle either question by themselves.
For a 24/7 loop, start with the copy you intend to broadcast, not a camera card or an earlier render. Exporting, converting, trimming or recompressing can change stream properties. If you plan to use one file for a long devotional, ambience or study channel, verify that exact file after the final export. If you are still choosing a delivery workflow, the guide to 4K 60fps YouTube Live streaming with FFmpeg covers the live side; this article focuses first on what the source file contains.
Inspect dimensions and frame-rate fields with ffprobe
ffprobe is part of the FFmpeg project. It reads multimedia streams and can report stream and container information in a machine-readable form. Run it against the actual file you have, replacing input.mp4 with its path:
ffprobe -v error -select_streams v:0 -count_frames -show_streams -show_format -of json input.mp4
This selects the first video stream, asks for a frame count, and prints stream and format details as JSON. The exact fields depend on the container and stream. In the video stream, look for width and height; a result of 3840 and 2160 is the expected encoded frame size for 2160p. This tells you the dimensions of the decoded output frames, not how much original detail went into them.
Read the rate fields rather than relying on a file manager’s rounded label. You may see r_frame_rate and avg_frame_rate, often written as fractions such as 60000/1001 or 60/1. A fraction is more informative than an interface rounding both to “60”. The two fields describe rate information in different ways, and unusual or variable-rate material may require closer examination of frames. Do not treat one field as proof that every interval in the clip has the same cadence.
The output may also show nb_frames or, because of -count_frames, nb_read_frames. Some containers do not provide every field, and a missing value is not automatically a defect. Compare the information you do have with the video duration and a frame-level inspection. If you want a quick summary before counting, omit -count_frames, but do not confuse a metadata summary with a complete cadence check.
If you need help interpreting FFmpeg output in a broader live setup, the practical CBR bitrate settings for FFmpeg and YouTube Live guide addresses encoder configuration. Keep the distinction clear: an ingest bitrate setting affects the broadcast you send, not the resolution or history of the file you are inspecting.
Check frames across the full duration
A sample from the opening seconds can miss an edit, a frame-rate change, or a section where frames have been repeated. First compare the frame count with the video duration. As a simple cross-check, divide the counted frames by the duration in seconds. A count around 60 frames per second over the whole clip is consistent with a stream near 60 fps, but the division is an average: it cannot show where the frames occur or whether some are duplicates.
Use -count_frames in the command above and note nb_read_frames for the selected stream if ffprobe reports it. Check that you are comparing the video stream’s frame count with the video duration, rather than accidentally using a container duration that includes a longer audio track or another stream. If a file has variable frame timing or unusual edits, a simple average can obscure local differences; inspect frames and timestamps around representative points instead.
For a long loop, check the start, middle and end, and include transitions or sections with movement. A slow pan over a temple, a lofi animation with drifting particles, or a local news ticker gives more information about cadence than a static title card. You can ask ffprobe to display frame-level information using its frame options, then inspect timestamps and picture types around a suspected interval. FFmpeg’s ffprobe documentation explains the available stream, frame and counting options; fields and behaviour can vary with the media format.
A count that is inconsistent with duration is a reason to investigate, not a verdict. The file might have an unusual time base, edit points, variable frame timing, or a duration reported differently by its container. Re-run the check on the intended video stream, inspect the output, and, when the source matters, compare against the original recording or project export settings. For a converted file, verify the result after conversion; the steps in converting MOV to MP4 on a Mac are relevant to the container change, but conversion alone does not validate capture rate or image detail.
Look for repeated frames or upscaling clues
Frame count is not the same as unique motion. A video can contain 60 encoded frames each second while repeating some pictures from a lower-rate source. Choose stretches with motion and advance through consecutive frames, or use frame comparison tools, to see whether objects move smoothly or appear to hold and jump in a regular pattern. Repeated imagery can be a clue, but fades, intentional holds, slow movement and compression can also make adjacent frames look alike.
Check more than one kind of movement. A gentle camera pan may hide duplication, while a scrolling ticker, moving water or a hand crossing the frame can make cadence easier to see. Compare several moments throughout the duration, especially after cuts. Avoid treating a single still or one short segment as representative of the entire file.
For resolution, inspect fine detail that should be present in the scene: hair, small lettering, leaves, fabric or distant edges. Soft detail, ringing around edges or blockiness may reflect scaling, focus, compression or the camera lens. An enlarged 1080p image can be saved with 3840×2160 dimensions, and a heavily compressed 4K original can look softer than expected. Visual inspection can raise a useful question; it cannot reliably identify the original capture resolution on its own.
Keep a small note of what you tested: file name, reported dimensions, frame-rate fields, frame count and duration, and the sections you reviewed. That makes a comparison between two exports more useful than remembering which one “looked sharper”. For a 24/7 channel, it also prevents checking a preview copy and then uploading a different final render. None of these checks certifies a source; together they tell you what the file reports and whether the motion and detail deserve further investigation.
Separate file inspection from capture provenance
Metadata belongs to the encoded file. It can report the output dimensions and timing, but a derivative file may have been scaled, interpolated, retimed, frame-blended or edited. A filename saying “native 4K 60” is a label someone applied; it is not independent evidence. Metadata can also be changed, removed or carried forward from an earlier stage.
If you need to establish where the footage came from, ask for the camera original or independently retained source material, along with recording notes or production records that connect it to the delivered file. Compare durations, cuts and visible content. If the question has contractual or archival importance, retain the original and document each export rather than relying on a claim in a filename or the final file’s properties. The inspection workflow here is not a forensic method for proving camera capture history.
For everyday loop planning, the level of evidence you need depends on the use. You may only need a delivery check so the finished file has the intended pixel dimensions and smooth-enough motion. If a client, rights holder or archive requires native capture at a stated rate, ask for provenance rather than inferring it from ffprobe. A candid description such as “2160p output, frame-rate fields near 60, source capture not independently verified” is more precise than calling it proven native 4K 60fps.
Configure YouTube Live ingest separately
Once you know what is in the file, configure the live encoder as a separate task. YouTube’s current live encoder settings guidance lists 4K/2160p at 60 fps and recommends 35 Mbps for H.264 ingest. That is a platform recommendation for a live input, not a measurement of your source file or a universal minimum for image quality. The page also gives codec-specific guidance, so check its current table and the options available in YouTube Live Control Room before setting up a stream.
The same guidance lists a recommended two-second keyframe interval, with an interval not exceeding four seconds, and constant bitrate encoding. It recommends RTMPS. Treat those as ingest settings: set the encoder to match the resolution and rate you intend to send, then run a test with representative motion and audio. Check stream-health messages and make sure the loop returns cleanly to its beginning. A successful test tells you whether the configured broadcast is being received as intended; it does not rewrite or verify the source’s capture history.
YouTube transcodes live streams into output formats for different devices and network conditions. As a result, a viewer may not be offered the source resolution at a particular moment, or may receive a different quality setting. A playback menu, a soft-looking picture on a phone, or a sharp picture on a desktop is not a direct test of the uploaded file or incoming encoder signal. Separate the questions: inspect the source locally, inspect the ingest settings, then observe stream health and playback as distinct stages.
Do not mix live-insert recommendations with upload encoding advice. YouTube’s separate recommended upload encoding settings say to encode and upload at the frame rate at which content was recorded. They list 24, 25, 30, 48, 50 and 60 fps as common rates, and give a 53–68 Mbps recommended SDR bitrate range for 2160p high-frame-rate uploads. That upload bitrate guidance concerns an uploaded video, not a YouTube Live ingest recommendation; it is also not a way to prove the source was natively captured at that rate.
If your concern is simply getting a fixed file to run without leaving a home computer on overnight, StreamNeo addresses that specific operational burden: it runs an uploaded video as a YouTube live stream with your computer switched off, and restarts automatically if the broadcast drops. It is YouTube-only, and its role is to run the prepared file, not to certify the file’s resolution or provenance. Check the source first, then choose a live workflow that matches how much control you want over encoding and monitoring.
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 3840×2160 in ffprobe prove a video is native 4K?
No. It reports the dimensions of the encoded video stream, which can be 3840×2160 after a lower-resolution source was enlarged. If native camera capture matters, compare the file with camera originals or other independent production records.
Does a reported 60 fps mean the camera recorded at 60 fps?
No. The frame-rate fields describe the encoded stream, not necessarily the original camera recording. Editing, retiming, interpolation or repeated frames can produce a file whose reported rate is near 60 fps; inspect motion and seek provenance when authenticity matters.
Why does YouTube playback look softer or offer a different resolution?
YouTube transcodes live input for playback across devices and network conditions, and viewers may receive different output formats. Playback is therefore not a direct test of the original source file. Inspect the file locally and check stream-health information separately.
What should I check before looping the file live?
Verify the final file’s reported dimensions and rate, compare frame count with duration, and inspect representative motion across the clip. Then configure the live encoder separately, run a test, and review stream health in YouTube Live Control Room. If the source must be proven native 4K at 60 fps, obtain evidence of its capture history rather than relying on file metadata.