Video Repair Command Generator — the safest FFmpeg command for your broken file

Every repair tool on the internet wants to re-encode your video. Re-encoding is the universal solvent: it dissolves container damage, index damage, and timestamp damage alike — and it dissolves ten to twenty percent of your quality on the way through, forever, on the one copy you have. Almost none of those problems need it. This generator takes the symptom you already diagnosed and emits the single gentlest FFmpeg command that could plausibly fix it, always stream-copy, never re-encode unless you have exhausted everything else. Each command ships with three annotations: what it does, what it explicitly does not do, and a quality statement — because a repair command you do not understand is just a gamble with extra steps.

The repair ladder — why order is the whole game

Video damage is layered, and each layer has exactly one lossless fix. The ladder descends from least to most destructive, and the cardinal rule is: never skip down.

1. Remux (stream copy). The media is fine; the container is confused. Copy every stream byte-for-byte into a fresh container. Zero quality loss, seconds of work. This fixes the majority of "plays weird" files.
2. Timestamp rebuild. The media is fine; the timing table is damaged or missing. Copy the streams while regenerating presentation timestamps and tolerating read errors. Still zero quality loss.
3. Stream extraction. One stream is dead, the other survives. Pull the survivor out into its own file rather than losing both to a failed whole-file operation.
4. Index rebuild (reference-based). MP4-specific: the moov atom never wrote. Reconstruct it from a matching reference recording, then stream-copy the result. No quality loss once the index exists again.
5. Re-encode. Last resort. Decode whatever survives, write a new file. Permanent generational loss, frozen artifacts, and no path back. The generator deliberately never suggests this step — if you have arrived here, you are making a human judgment call with your eyes open.

The reason the ladder matters is asymmetric: running step 5 when step 1 would have worked destroys quality you can never recover, while running step 1 when step 5 was needed merely fails cleanly and leaves the original untouched for the next attempt.

The six modes, one by one

Remux — ffmpeg -i "broken.mkv" -c copy "fixed.mp4" Copies every stream without decoding. Fixes damaged container metadata, stale indexes, and wrapper mismatches. Does not rebuild a missing MP4 index and does not touch truncated packets — if the input cuts off mid-frame, this command stops at the cut. Quality: lossless, the output contains exactly the input's video and audio bytes.

Timestamps — ffmpeg -err_detect ignore_err -fflags +genpts -i "in.mp4" -c copy "out.mp4" Two flags do the work. -err_detect ignore_err tells the demuxer to treat damaged structures as end-of-data instead of aborting the whole operation. -fflags +genpts regenerates presentation timestamps where they are missing or non-monotonic. This is the fix for files that play but stutter, desync, or refuse to seek. It invents no frames; it rebuilds the schedule the frames play on.

Extract audio — ffmpeg -i "in.mp4" -vn -c:a copy audio.m4a Saves the survivor when the video stream is past help. The -vn flag drops video entirely; the audio is copied verbatim into an M4A wrapper. For a three-hour lecture with a dead video track, this is the difference between losing everything and keeping the content that actually matters.

Extract video — ffmpeg -i "in.mp4" -an -c:v copy video.h264 The mirror image: -an drops audio and copies the video stream into a raw elementary file. Useful when audio is the damaged half, and as a salvage step before attempting anything more ambitious with the video.

Rebuild — untrunc good.mp4 "broken.mp4" then ffmpeg -i recovered.mp4 -c copy "fixed.mp4" The MP4-missing-index path. Untrunc scans the orphaned media bytes and reconstructs the moov atom using a reference file recorded with identical settings — same codec, resolution, frame rate, and time base. The follow-up stream copy validates the rebuild and optionally relocates the index to the file's front. This is the only mode that is two commands, because rebuilding an index is genuinely two operations: reconstruct, then verify.

MKV to MP4 — ffmpeg -i "in.mkv" -c copy -movflags faststart "out.mp4" The compatibility finish: wraps MKV media in an MP4 container and moves the moov atom to the front so the file streams progressively over HTTP. This is what lets you record crash-safe MKV forever and still hand clients a standard MP4. No re-encoding — the media bytes do not change, only the wrapper and index placement.

The backup rule — non-negotiable, and here is why

Every command this generator prints assumes you first ran:

`` cp "broken.mkv" "broken.mkv.bak" ``

This is not caution for its own sake. Repair tools write new files, but they also read the input while partially parsing damaged structures — and the failure mode of a confused demuxer is not always clean. More importantly, the repair you run first is not always the repair you needed, and several attempts on the same source file are normal. Each attempt that reads the original is one more chance for a tool to trip over the same damaged bytes in a new way. The copy costs you disk space equal to one file; the original costs you the recording. There is no version of that trade where the original should be the working copy.

Three repairs, walked through — hypothetical, labeled

Note for video-repair-command-generator: The three repairs below are hypothetical examples (illustrative, not sourced case studies) for this specific tool — representative commands and outcomes, not documented incidents.

Repair 1 — MKV stream that stopped mid-recording. A 4-hour session in MKV ends when the machine sleeps; the file is 11 GB, plays for a while, then freezes. Diagnosis: truncated tail. Mode: remux. Command: ffmpeg -i "stream.mkv" -c copy "stream_fixed.mkv". FFmpeg walks intact clusters, copies their bytes, rebuilds the seek index, and reports a skipped cluster at the cut. Output: 3:58:40 of playable, seekable video. Quality identical to the original for every recovered minute; the last few seconds in the write buffer are gone and no command anywhere can bring them back.

Repair 2 — MP4 with audio drift after a crash. The file opens and plays, but audio pulls ahead of video by about a second every ten minutes. Diagnosis: damaged timestamp table. Mode: timestamps. Command: ffmpeg -err_detect ignore_err -fflags +genpts -i "interview.mp4" -c copy "interview_fixed.mp4". The regenerated timeline is monotonic and matches the declared frame rate; playback stays locked. If drift persists after this pass, the source was variable frame rate, and the honest fix is a constant-rate transcode — a human decision, made knowingly, after the lossless option was proven insufficient.

Repair 3 — MP4 that will not open at all, 8 GB on disk. OBS crashed before writing the index; ffprobe reports the moov atom missing. Diagnosis: missing index, media intact. Mode: rebuild. First, record ten seconds on the exact same OBS profile to produce good.mp4 — this reference is what makes reconstruction possible. Then: untrunc good.mp4 "broken.mp4", followed by ffmpeg -i recovered.mp4 -c copy "fixed.mp4". The rebuilt index maps every sample; the stream copy confirms the file opens, seeks, and reports the right duration. Total elapsed: about ten minutes for an 8 GB file. Quality: identical to capture — the bytes were never decoded.

Edge cases the generator's commands hit

Filenames with spaces, quotes, or unicode. The generator wraps both paths in double quotes for exactly this reason. If your filename itself contains a double quote (rare, but camcorders do strange things), rename the file before repairing — fighting shell quoting during a recovery is a mistake you only need to make once.

Batch-repairing many files. The commands are one-file-at-a-time by design. For a folder of damaged MKVs, a shell loop over the remux command works well — but run the loop over copies, verify each output before moving on, and never let a batch script delete originals. One bad file in a batch should cost one file, not the loop's entire output directory.

The output is larger than the input. Normal for the faststart remux (the relocated index adds a few megabytes) and for timestamp regeneration on some inputs. Growth is metadata, not bloat — the media streams are byte-identical, and ffprobe will confirm the same stream sizes.

The output is smaller than the input. Also normal when the input contained damaged or orphaned trailing bytes that the demuxer declined to copy. The smaller file is the honest one.

Remux fails immediately with "Invalid data found." The damage is earlier in the file than a clean walk can skip. Try the timestamps mode, which adds error tolerance; if that still fails at the same offset, extract whichever stream survives and accept the partial recovery.

Verifying the repair before you trust it

A command exiting zero is not proof the file is good. Three checks, in ascending order of effort:

1. ffprobe sanity: ffprobe -v error -show_entries format=duration,size -of default=noprint_wrappers=1 fixed.mp4 should print a duration matching your expectation and a size consistent with the bitrate math.
2. Seek test: open in VLC, jump to the beginning, middle, and final minute. Seek failures are the most common residue of index damage, and they only show up when you actually seek.
3. Spot-watch the damage boundary: if the original failed at a specific moment, watch across that timestamp in the repaired file. The repair should hold on both sides of the scar.

Only after all three pass should the original be archived or deleted — and even then, keep the original until the repaired file has been copied to its permanent home and verified there.

How this connects to WeaverClip — without bullshit

Repair commands are a tax on a failure that already happened; the generator exists to make that tax as small as possible. The product's position is simpler: recordings that never need this page. One-minute segments are verified byte-for-byte against the vault before the local copy is released, a crash costs sixty seconds instead of a file, and every segment is a complete, closed container by construction. Use the generator when you must — it is free and always will be — and use it exactly once per problem if the prevention is worth more to you than the repair.

FAQ

Why won't the generator just give me a re-encode command? Because re-encoding is irreversible and usually unnecessary, and a tool that hands you the most destructive option first is not helping you triage. When every lossless rung on the ladder has been tried and failed, re-encoding is your decision to make with full information — not a default the generator should normalize.

Do these commands work on Windows? Yes — FFmpeg's syntax is identical across platforms. Install via winget or a static build, run the commands in PowerShell or cmd, and keep the double quotes around paths.

Is `-c copy` really lossless? Yes, in the strict sense: the compressed bitstream is copied without decode or re-encode, so the output bits are the input bits. What copy cannot do is fix data that is already wrong inside the stream — it repairs the wrapper, never the content.

What if I have no reference file for a moov rebuild? Record one now: ten seconds, same OBS profile, same resolution, frame rate, and encoder. If the original settings are truly unrecoverable, try a reference at the closest matching resolution and frame rate — results vary, and this is where honest odds replace guarantees.

The repaired file plays but my editor still rejects it. Editors are stricter than players about variable frame rate and some index layouts. A constant-frame-rate transcode into an edit codec (ProRes or DNxHR) is the standard bridge — a deliberate re-encode of an already-salvaged file, which is a different trade than re-encoding a damaged one.

How long do these commands take? Remux, timestamps, and extraction run at disk speed — multi-GB files finish in seconds to a minute. A moov rebuild is slower because it scans the entire media region, but it is still minutes, not hours, for typical session sizes.

The flags, decoded — know exactly what you are pasting

Every command here is short enough to memorize, and understanding each flag turns copy-paste into informed use.

`-i "file"` — the input. FFmpeg reads it, and only it. Nothing in these commands writes to the input file; output always goes to a separate named file. This is why the backup rule exists as insurance, not necessity — the commands themselves are read-only on the source.

`-c copy` (or -c:v copy -c:a copy) — the heart of every lossless repair. -c selects the codec; copy means "do not decode, do not re-encode, move the compressed packets as-is." The container gets rebuilt around identical media. Any command with this flag is safe in the quality sense; the only thing it can lose is data that was already unreadable.

`-err_detect ignore_err` — changes how the demuxer reacts to damage. Default behavior: hit a broken structure, abort the whole operation, write nothing. With this flag: hit a broken structure, stop reading there, keep everything parsed so far. This is the difference between "repair failed" and "recovered up to the damage point" for truncated files.

`-fflags +genpts` — regenerates presentation timestamps. PTS values tell the player when each frame and audio sample belongs on the timeline. Crashed recordings often have gaps, duplicates, or missing PTS entries; +genpts recomputes a clean monotonic timeline from frame counts and the stream's declared frame rate. Pair it with -err_detect ignore_err and you have the standard timestamp-rebuild pass.

`-vn` / `-an` — "no video" / "no audio". Strips the named stream from the output entirely. Combined with -c:a copy or -c:v copy, this is surgical extraction of one healthy stream from a mixed bag.

`-movflags faststart` — MP4-specific. Moves the moov index to the beginning of the file after writing. Without it, MP4s keep the index at the end (fine locally, bad for streaming). With it, the file plays progressively over HTTP — YouTube, your website, a client link, all start instantly instead of buffering the whole file first. Costs a few megabytes; worth it for anything that will live on the web.

`untrunc good.mp4 broken.mp4` — not FFmpeg at all: a dedicated index-reconstruction tool. It reads codec parameters (SPS/PPS headers, audio decoder config, time base) from the healthy reference file, then walks the broken file's raw media bytes, identifies every sample boundary, and writes a new moov atom mapping them. The -s variant writes a safe truncated output if it hits confusion near the end. Its one absolute requirement: the reference must match the broken file's encoder settings, or every timestamp it assigns will be wrong.

Reading the does / does-not / quality labels

The generator annotates every command with three fields because each answers a different worry:

• "What it does" tells you the mechanism — which layer of the file gets touched. If the described mechanism does not match your diagnosed problem, you picked the wrong mode.
• "What it does NOT do" is the boundary of expectations. A remux that "does not rebuild a missing moov" means: if your MP4 will not open at all, this command will fail, and that failure is expected, not a bug. Reading the does-not list before running saves you from misdiagnosing the tool when you actually misdiagnosed the file.
• "Quality" answers the fear everyone has: will this make my footage worse? Every mode in this generator answers "lossless" — that is the entire design constraint. The moment a repair path cannot say that, it does not belong in this tool.

When to stop repairing and re-record

Repair has a cost ceiling, and knowing it in advance saves hours. Stop and re-record when:

• The recovered content is a scratch take anyway. Rehearsal footage, test recordings, B-roll you can reshoot in ten minutes — spending an hour rebuilding an index for disposable material is negative-value work.
• More than one stream is damaged. One dead stream is a salvage job; two dead streams means the file's damage is systemic (usually disk-level), and the odds of a clean full recovery drop fast.
• The repaired file would need a full re-encode anyway. If your destination platform or editor demands a transcode regardless, a damaged-but-recoverable file and a clean re-recording may cost you the same final step — choose whichever gets you there faster.
• You are on attempt four with no progress. Each rung of the ladder gets one honest try. If remux, timestamps, extraction, and a rebuild attempt have all failed, the problem is almost certainly below the container level (disk sectors, overwritten clusters), where software repair stops and only the original write location — long gone — had the answer.

The generator will happily give you commands for attempts one through three. Attempt four is where human judgment takes over, and "re-record tomorrow with better settings" is a legitimate, often correct, repair.

FAQ — the questions that come up during an actual repair

Can I run these on a file that is still being written? No. An open file's container is mid-write by definition — MP4 has no index yet, and MKV's last cluster is incomplete. Every repair here assumes a closed or abandoned file. If the recorder crashed, the file is abandoned; if it is still running, wait.

Which mode for a file that plays but skips every few minutes? Start with timestamps, not remux — skipping on a fixed rhythm is almost always a damaged or gapped timestamp table rather than container confusion. If the skipping is random and clustered near one spot, that is physical damage to the stream, and error-tolerant remux (timestamps mode already includes it) will drop the damaged region instead of looping on it.

The remuxed output lost my chapter markers / metadata. Expected: -c copy moves streams, not every side-channel of container metadata. Chapters, embedded thumbnails, and some tag fields need explicit mapping flags. For recordings, this rarely matters; for a film master, check what the original carried before you overwrite your only copy of it.

Can I repair and convert at the same time? You can — ffmpeg -i broken.mkv -c copy fixed.mp4 is repair plus container conversion in one pass, which is exactly the mkv2mp4 mode. What you cannot do is repair plus re-encode plus convert "while you're at it" without accepting the quality cost of the encode. Keep the operations separate so each one stays accountable.

What about hardware-accelerated decoding for extraction? Not needed and not recommended here — extraction is a copy operation, and hardware decoders add a decode/re-encode round trip that defeats the point. These commands are CPU-trivial; a phone could run them.

Is FFmpeg the only tool that works? For remux, timestamps, and extraction, FFmpeg is the standard and the commands transfer to any build from the last several years. For moov rebuilds, Untrunc and Recover_MP4 are the common choices; the generator names Untrunc because it is the maintained one, but the reference-file principle is identical across tools.