FFprobe Can Tell You Where a Video Generation Pipeline First Went Wrong

“The video looks pixelated” is a useful report from a viewer, but it is not a diagnosis.The visible problem may have entered during capture. It may have been introduced by an editor export, a messaging app, a cloud-storage preview, a video platform’s transcode, or the player’s current rendition. Those failures can look similar while requiring completely different remedies. The fastest way to make the problem worse is to process the wrong file. Upscaling a clean master because a browser temporarily selected a low-resolution stream adds another transformation without fixing the delivery problem. Re-exporting a compressed attachment at 4K creates a larger file, not a recovered original. This workflow uses FFprobe and FFmpeg to answer a narrower, more defensible question: Between which two available generations did the measurable and visible quality change first appear? FFprobe cannot decide whether a video looks good. It can make each file report comparable facts, which turns visual inspection into a reproducible investigation instead of a memory test. Build a file lineage before opening an editor Place copies of every available generation in a working folder. Do not rename or overwrite the only surviving original. Use filenames that record the files’ positions in the chain: 01-capture-original.mov 02-editor-export.mp4 03-shared-download.mp4 04-platform-download.mp4 05-player-screen-recording-reference-only.mp4 Write down how each file was obtained. “Downloaded from a messaging app on 7 August” is useful provenance. “final-v8-new.mp4” is not. A screen recording can document what a viewer saw, but it is not the delivered stream. It adds a new capture, scale, frame-rate decision, and encode. Keep it as reference evidence rather than treating it as a substitute for the uploaded master or decoded platform rendition. If only one file remains, record that limitation. The correct conclusion may be “the earliest surviving copy is already damaged,” not “the camera captured the damage.” Produce the same FFprobe report for every generation Run one command against each file without changing the requested fields: ffprobe -v error \ -select_streams v:0 \ -show_entries stream=codec_name,profile,width,height,pix_fmt,avg_frame_rate,r_frame_rate,bit_rate,color_range,color_space,color_transfer,color_primaries \ -show_entries format=format_name,duration,size,bit_rate \ -of json \ 01-capture-original.mov \ > 01-capture-original.ffprobe.json Repeat it for the editor export and every downloaded copy. FFprobe reads the file without re-encoding it. The official FFprobe documentation describes the available stream and format fields. Keeping the same command matters. A comparison remains legible when fields are requested in the same order and missing values are represented consistently. The report is evidence, not a quality score. Each field answers a specific question: Field Question to ask between adjacent generations width, height Was a smaller rendition created, or was a smaller file enlarged later? codec_name, profile Was the video transcoded even though its dimensions stayed the same? avg_frame_rate Did the average presentation rate change? r_frame_rate Does the stream expose a different base rate or timing pattern? stream or format bit_rate Did the data rate collapse between files containing the same scene? duration Was the clip trimmed, stretched, or handled differently? pix_fmt Was bit depth or chroma sampling reduced? color fields Did range, primaries, or transfer interpretation change? Suppose the reports show this chain: Generation Dimensions Codec Average bitrate Capture original 3840×2160 HEVC 48 Mb/s Editor export 3840×2160 H.264 24 Mb/s Shared download 1280×720 H.264 2.1 Mb/s This does not prove that the editor export is visually perfect or that 24 Mb/s is universally sufficient. It does establish a major resize and bitrate boundary between the export and shared download. That boundary deserves inspection before anyone attempts restoration. Bitrate requirements depend on codec, dimensions, frame rate, encoder settings, and scene complexity. A static slide can survive a rate that destroys handheld night footage, water, smoke, foliage, or confetti. Compare adjacent files containing the same scene instead of treating bitrate as a universal grade. Some containers do not expose a reliable per-stream bitrate. A missing value is not zero. In that case, use duration, total file size, and format bitrate as supporting evidence: approximate bits per second = file size in bytes × 8 / duration in seconds The approximation is most useful for a dramatic change within one lineage. It should not be used to rank unrelated videos or codecs. Treat dimensions as a lineage clue, not proof of detail A larger frame is not automatically a better source. If a 1280×720 attachment is imported into an editor and exported at 3840×2160, the new file contains more output pixels but not the original 4K samples. The dimensions may now match the camera file while block boundaries, ringing, and invented interpolation remain. Look for both downward and upward changes: a reduction can reveal a smaller platform or messaging rendition; a later increase can reveal that an undersized copy was enlarged; unchanged dimensions can still hide a destructive transcode. This is why filename labels such as “4K final” are weak evidence. The file lineage and stream report are stronger. Inspect frame timing when motion looks wrong Viewers often describe judder, duplicated frames, or uneven motion as “low quality” even when the spatial resolution has not changed. Mobile and screen recordings may use variable frame rate. Converting them to an unrelated constant rate can duplicate, drop, or blend frames. Compare frame timestamps around a motion-heavy section: ffprobe -v error \ -select_streams v:0 \ -show_entries frame=best_effort_timestamp_time,pkt_duration_time,pict_type,key_frame \ -of csv \ 02-editor-export.mp4 \ | head -n 180 Do not assume that r_frame_rate and avg_frame_rate mean the same thing. The first is a stream rate that can be misleading in some files; the second is an average. The actual timestamps reveal the cadence that the decoder receives. If timing changed at the editor-export boundary while dimensions and bitrate remained similar, investigate the timeline and export frame-rate settings before applying sharpening or upscaling. Check pixel format and color interpretation A change from a higher-bit-depth format to 8-bit 4:2:0 can make gradients, colored text, and keyed edges more fragile. A mismatch in color_range, color_transfer, or color_primaries may produce washed-out blacks, crushed shadows, or unexpected contrast. Those symptoms are not fixed by adding detail. Metadata can be incomplete or incorrect, so it must be checked against a color-managed player. Its value is diagnostic: it identifies the boundary where the stored description changed and tells you what to test next. Two video players can use different scaling, hardware decoding, color management, or quality settings. Comparing them side by side introduces variables that have nothing to do with the files. Extract frames from identical timestamps: mkdir -p frames ffmpeg -ss 00:00:07.500 \ -i 01-capture-original.mov \ -frames:v 1 -vsync 0 \ frames/source-007500.png ffmpeg -ss 00:00:07.500 \ -i 02-editor-export.mp4 \ -frames:v 1 -vsync 0 \ frames/export-007500.png ffmpeg -ss 00:00:07.500 \ -i 03-shared-download.mp4 \ -frames:v 1 -vsync 0 \ frames/shared-007500.png Repeat the extraction for at least three scene classes: slow movement with fine texture; rapid movement or a camera pan; a dark gradient, smoke, water, hair, foliage, or small text. A bright paused portrait may hide the exact failure that appears in motion. Keep the native extracted frames. If the files have different dimensions, create separate scaled copies for display comparison and label them clearly. Scaling is part of the experiment; it should not be mistaken for recovered source detail. Locate the first bad adjacent pair Review the files in order rather than jumping directly from the first to the last. The original and editor export differ Inspect timeline resolution, proxy usage, export preset, rate control, frame-rate conversion, and whether the editor encoded the file more than once. Re-export once from the clean source with corrected settings. Do not enhance the damaged export while a clean source remains available. The editor export is clean, but the shared download differs The transfer path is the likely boundary. Send the original as a file, use a download link that preserves it, or disable media optimization when the application permits. Repairing the received attachment is a fallback, not the first choice. The local export and download are clean, but playback is soft Check whether the platform is still processing higher-quality renditions, whether the player selected a low stream, and whether the displayed video is being enlarged beyond the decoded frame. The master does not need another encode simply because one playback session was soft. Every surviving file contains the same defect State the limit of the evidence. The loss happened before or within the earliest file you possess. Look for an earlier source, camera original, editor archive, cloud backup, or recipient who retained the original transfer. Use SSIM only when the inputs are aligned SSIM can support a comparison when two files represent the same frames, geometry, and timing: ffmpeg \ -i reference.mp4 \ -i candidate.mp4 \ -lavfi "[0:v]setpts=PTS-STARTPTS[ref]; \ [1:v]setpts=PTS-STARTPTS[dist]; \ [ref][dist]ssim=stats_file=ssim.log" \ -f null - A crop, one-frame offset, frame-rate conversion, scale difference, or color-range mismatch can dominate the result. A higher score also does not guarantee a better-looking video. Sharpening can create halos, denoising can erase texture, and generated enhancement can produce plausible but incorrect letters, faces, or repeated patterns. Use metrics to support a controlled moving comparison, not replace it. Create the smallest reproducible test Once the first bad generation is identified, isolate a short section that contains the defect. A stream copy avoids a new encode when the cut can begin at a suitable keyframe: ffmpeg -ss 00:00:05 \ -i 03-shared-download.mp4 \ -t 00:00:08 \ -c copy \ diagnostic-sample.mp4 If the copied segment begins at the wrong visual point, create a controlled test encode and record the settings: ffmpeg -ss 00:00:05 \ -i 03-shared-download.mp4 \ -t 00:00:08 \ -c:v libx264 -crf 16 -preset slow \ -c:a aac -b:a 192k \ diagnostic-sample.mp4 The second command is lossy. Its advantage is that the additional transformation is explicit, repeatable, and limited to a short diagnostic sample. Write a bounded conclusion A useful report does not claim more than the available files prove. Good conclusions look like these: “The shared download is the first available generation with reduced dimensions and motion blocking.” “The editor export preserves the source dimensions, but its frame timestamps show a new constant-rate cadence.” “The uploaded master matches the local export; only the selected playback rendition is soft.” “Every surviving generation contains the same focus error, so the capture boundary cannot be evaluated.” Record the filenames, hashes, FFprobe JSON, exact timestamps, commands, tool versions, and matched frames together. Someone else should be able to repeat the comparison without relying on your memory or your preferred player. Decision table First bad generation Best first action Capture or earliest surviving file Search for an earlier source; otherwise preserve it and test limited cleanup on a short segment Editor export Re-export once from the clean source with corrected project and encoder settings Messaging or cloud download Transfer the original instead of processing the derivative Platform rendition Wait for processing and verify the selected stream and rendered size Editor preview only Judge a saved test export outside the editor The principle is simple: fix the stage that introduced the loss. Resolution is not quality. A new encode is not automatically a repair. FFprobe does not replace visual judgment, but it makes the judgment traceable by showing where the files stopped being equivalent.