How to Check Whether a Downloaded Video Is Complete: Header Checks & Stream Health
Few experiences are more disappointing in digital preservation than discovering months after downloading an important video that the file is broken. The media player opens the video, plays smoothly for six seconds, and then abruptly freezes, displays distorted green digital macroblocks, or cuts off entirely before reaching the conclusion.
Video download errors are frequent on mobile connections and congested networks. Browsers often close HTTP connections prematurely without throwing a visible download error, creating a truncated file that appears complete on disk. This guide walks you through the technical methods required to verify that every downloaded MP4 video in your archive is 100% complete, fully decodable, and free of corruption.
Why Downloads Get Truncated or Corrupted
Video downloads fail or truncate due to three primary network and architectural factors:
- Premature TCP Socket Termination: When downloading over high-latency cellular networks or through rate-limited CORS proxies, connection timeouts can occur mid-stream. If the server does not declare a strict
Content-Lengthheader, the browser assumes the connection closed normally and writes a truncated file to disk. - Fragmented MP4 Streaming vs. Progressive Downloads: Modern streaming platforms deliver video using segmented HLS (HTTP Live Streaming) playlists (
.m3u8chunks). If a scraper fails to stitch the final media segment, the resulting file is missing its tail end. - Bitrot and Filesystem Write Errors: Flaky USB flash drives, faulty SD cards, or sudden system power losses during file writes can corrupt filesystem allocation tables, leaving corrupted bytes in the media payload.
Checking the MP4 Container: The moov Atom Problem
The MP4 container format (ISO/IEC 14496-14) organizes media into logical data blocks known as atoms or boxes. The two most critical atoms in any MP4 video are:
mdat(Media Data Box): Contains the actual raw encoded video frames and audio packets.moov(Movie Box): Contains the metadata index, frame offsets, duration, codec parameters, and track configurations necessary for a player to decode themdatpayload.
Fast Start vs. Trailing moov Atoms
If an MP4 was generated with the moov atom placed at the very end of the file (rather than at the beginning via "faststart"), any download that terminates even 1% early will lack the moov box entirely. Without this index, standard media players cannot decode the video at all, producing the error "This file is invalid or corrupted."
You can inspect atom placement using open-source tools like mediainfo or FFprobe:
ffprobe -v error -show_entries format=duration,size,bit_rate -of default=noprint_wrappers=1 sample.mp4If FFprobe returns valid duration and stream mappings without error, the container headers are structurally intact.
Automated Stream Verification with FFmpeg
Just because a file has a valid container header does not guarantee that every video frame inside the mdat box is decodable. The most rigorous, battle-tested way to verify stream integrity is to run a full decode pass with FFmpeg directed to the null output device:
ffmpeg -v error -i target_video.mp4 -f null -Here is how this command functions:
-v error: Suppresses benign informational messages and prints only genuine codec errors, dropped frames, or corrupted packet notices.-i target_video.mp4: Reads the input file.-f null -: Decodes the entire video and audio stream at maximum CPU speed without writing anything to disk (discarding raw frames in memory).
If the command completes with zero text output and returns exit code 0, congratulations: your video file is 100% complete, uncorrupted, and decodable from the first frame to the very last millisecond.
What Corrupted Output Looks Like
If you see output like [h264 @ 0x...] error while decoding MB or [mp4 @ 0x...] truncated file, the download terminated prematurely. Delete the broken file and re-fetch the stream from the source.
The 5-Step Archive Quality Assurance Checklist
Before moving any downloaded video into your permanent cold archive, run through this five-point QA checklist:
- File Size Sanity Check: Does the file size make sense? A 1080p video clip should typically be between 2 MB and 25 MB per minute depending on bitrate. A file measuring under 100 KB is almost certainly an empty error page.
- Duration Verification: Open the file and verify the progress bar duration matches the source post length.
- End-of-File Scrub: Seek to the final 5 seconds of the video to ensure audio and video play smoothly without freezing.
- Audio Track Inspection: Confirm the audio track is present and audible (and not silent due to mute toggles).
- Generate Checksum: Compute and record the SHA-256 hash in your archive catalog.
Frequently Asked Questions
Can a truncated MP4 file be repaired?
If a file was truncated mid-download, the missing audio/video packets simply do not exist on your computer. While utilities like untrunc can sometimes reconstruct a partial video using the header of a healthy reference clip, the missing ending cannot be recovered without re-downloading.
Why do some downloaded videos play fine in VLC but fail in QuickTime?
VLC Media Player contains extremely forgiving built-in fault tolerance routines that skip over broken frames and damaged headers. Apple QuickTime enforces strict ISO standard compliance; if a header atom is slightly malformed, QuickTime refuses to open it.
How can I batch-check 100 downloaded files automatically?
You can write a simple shell or PowerShell loop that executes ffmpeg -v error -i "$file" -f null - on each file. Any file that prints an error message can be automatically flagged for re-download.