The short answer
Keep the original and inspect the file you will actually select. Record its size, duration, video dimensions, frame rate and video/audio codecs. A filename ending in MP4 identifies a container convention, not every stream inside it. Then play the complete file and check the destination’s current requirements. A successful probe, a local player and a processed LinkedIn post establish different things.
What you’ll take away
- Keep the file hash and observation with the chosen revision.
- Read the video and audio streams separately.
- Unknown fields should remain unknown until the actual file resolves them.
Start with the file you will actually send
An editor project, an earlier download and the newest export can share a similar name while containing different cuts. Put the intended export in a clearly identified folder, preserve the source project and note its revision. Do the checks after the final copy or download rather than assuming the editor’s settings describe the bytes now on disk.
For a reproducible record, calculate a SHA256 checksum and keep it beside the observations. A checksum helps establish that two copies are identical; it does not establish that either copy is complete, private, accurate or suitable for upload. If the bytes change after a correction, create a new record instead of attaching the old pass to the new file.
Separate the container from its streams
A media container holds streams and metadata. Read the video codec and pixel format as well as the container label; read the audio codec, sample rate and channels separately. Renaming MOV to MP4 does not perform a conversion. An intentionally silent clip can be valid, but an absent audio stream does not become recorded speech just because the editor timeline contains narration.
Your existing editor or media-properties panel may expose some of these fields. If a field is absent, mark it unknown. With FFmpeg installed, ffprobe can report structured stream and format data without uploading the file anywhere. The linked original JSON demonstrates those fields; it is not a private creator export.
| Field | Actual synthetic example | What it resolves |
|---|---|---|
| Container and streams | MP4; H.264 video and AAC audio | Which encoded tracks are actually present |
| Picture | 480 × 270, yuv420p, 24/1 average fps | Stored image dimensions and a reported rate |
| Duration and count | 4 seconds; 96 decoded video frames | A bounded duration/count check for this file |
| Audio | 48,000 Hz; two channels | Track configuration, not intelligibility |
| Bytes | 287,147 | Exact file size, not a quality score |
Save a probe you can read and repeat
The worked file is P02 from our original video study. Running ffprobe with count_frames, show_streams, show_format and JSON output produced the linked observation. Counting frames invokes decoding; a basic metadata read alone does not test the full video stream. Keep the command, tool version and exit status with the result, especially when a tool prints partial information before reporting an error.
Read format duration alongside stream durations and frame count. For this constant-rate example, 96 frames at 24 frames per second correspond to four seconds. That arithmetic is not a general validator for a variable-rate recording. A missing duration, rotation or codec detail needs investigation rather than a fabricated default.
- Open the final export’s properties and record the fields you can establish.
- Optionally run ffprobe -v error -count_frames -show_streams -show_format -of json P02-fast.mp4.
- Save the JSON and exit status, then match the file checksum.
- Keep unresolved fields visible before making the next decision.
Check the picture that the fields do not prove
Stored width and height are not always the displayed shape. Rotation metadata and non-square pixels can change the presentation. Open the exported file in the intended player and inspect a meaningful beginning, middle transition and ending. Look for missing picture, clipped labels, the wrong date range and a final frame that contradicts the narration.
Our controlled browser study independently decoded 96 ProRes video frames in FFmpeg, yet the browser reached the end without reporting video dimensions or a video-frame callback. That is why neither a decoder’s success nor an ended event closes the picture check. The study records software signals in one environment; it does not substitute for watching your own finished content.
Compare the export with the actual destination
LinkedIn’s ordinary-video troubleshooting page lists size, duration, resolution, aspect-ratio, frame-rate and bitrate boundaries. Use the current page for the intended upload surface. It also specifically warns that ProRes may upload but fail processing. A local player that handles a file does not overturn that destination-specific warning.
A file can fall within several numeric ranges and still contain an unsuitable codec, damaged media or wrong content. Do not treat an accepted selection dialog as publication. If a controlled re-export is necessary, preserve the failed revision and change the relevant setting with a stated reason. Recheck the replacement’s actual bytes and playback.
Finish with a usable decision record
For the synthetic example, the record identifies the source hash, MP4/H.264/AAC streams, four-second duration, 480 × 270 stored picture, 96 decoded frames and exact byte size. It then separately records what happened in the tested browser. No LinkedIn upload was performed. This closes the local inspection task without inventing the later processing result.
For your own export, add the intended account, audience and final-content review before publication. After a real upload, reopen the processed post and check picture, sound, captions and the intended version. If only the local inspection is complete, report that stage and retain the remaining work.
Sources & product references
Product details reflect the publication date. External features and interfaces may change.
