Green Screen / Glitched Playback in Recovered Video
The recovered file plays. The structure is clean. The picture is just… wrong. Solid green frames, magenta blocks, pixelated tiling that looks like an old VHS, momentary flashes of corruption, or "smeared" sections where motion looks wrong.
This is codec-data-level corruption, distinct from the structural recovery cases on the rest of the site. It's also the hardest category. Here's what's tractable and what isn't.
Why glitched playback happens
Modern video codecs (H.264, H.265, ProRes) encode using predictive compression. Each frame's data depends on previous frames (P-frames) or surrounding frames (B-frames). Only keyframes (I-frames / IDR) stand alone.
When codec data is damaged:
- Bit flips inside a P/B frame → the decoder produces wrong colour or wrong motion for that frame and every dependent frame after it, until the next keyframe resets things.
- Damaged IDR / keyframe → an entire GOP (group of pictures) decodes wrong.
- Damaged SPS / PPS / VPS → all subsequent frames decode with wrong colour space or wrong resolution.
- Missing frames → the decoder falls back to the last-known-good frame and plays it for the gap, producing a freeze or smear.
Common visual signatures:
| Visual | Cause |
|---|---|
| Solid green frames | Codec couldn't decode anything; fallback colour. |
| Pink / magenta blocks | Macroblock decode failure on partial frame. |
| Pixelated / chunky look | Reference-frame loss, decoder using older reference. |
| Brief flashes mid-playback | Bit flips in specific frames; clean again after next keyframe. |
| Smeared / motion-trail look | Lost P/B frames, decoder extrapolating motion vectors wrong. |
| Wrong colours across whole file | SPS / VPS damage affecting colour metadata. |
What's recoverable and what isn't
| Damage scope | Recoverable? |
|---|---|
| One bad frame, rest of GOP fine | Often — drop the bad frame, continue at next keyframe. |
| One bad GOP, rest of file fine | Usually — splice out the bad GOP. |
| Multiple bad GOPs, scattered | Sometimes — splice each, rebuild index. May leave brief jumps. |
| Damaged SPS / VPS (whole file decodes wrong) | Often — extract codec parameters from a later valid keyframe. |
Bit-flip density > a few percent of mdat | Rarely. Beyond what container-level recovery can do. |
| Compression-internal damage on encoder-modified frames | Almost never. |
What you should try first
Before any recovery, characterise the damage:
ffmpeg -err_detect ignore_err -i broken.mov -c copy -f null -
The output reports decoder warnings frame-by-frame. Count the warnings:
- A handful of warnings on a long file → localised damage, likely recoverable.
- Hundreds or thousands of warnings → widespread damage, recovery will be partial at best.
- Warnings across the entire file → systemic codec damage, possibly unrecoverable.
If the damage is localised, FFmpeg's permissive mode often produces a watchable file:
ffmpeg -err_detect ignore_err -fflags +discardcorrupt -i broken.mov -c copy salvaged.mov
+discardcorrupt drops bad frames rather than playing them as glitched. The output will have brief skips at damage points but the rest plays cleanly.
How our recovery handles glitched files
For glitched playback specifically, our pipeline can:
- Re-extract codec parameters from any valid keyframe in the file. If the SPS at the file's start is damaged, we look for the next valid one.
- Splice out damaged GOPs when they're clearly identifiable. The rebuilt file plays clean at the cost of brief visible cuts.
- Identify uncorrectable damage and report honestly. If most of the codec data is damaged at the bit-flip level, we tell you upfront. We don't take payment for files we can't make watchable.
We cannot:
- Repair frame-internal compression damage. Once bytes inside a compressed frame are flipped, the math doesn't reverse.
- Reconstruct missing frames from surrounding frames. There's no way to interpolate the actual content of a frame that wasn't recorded.
- Fix issues that are actually camera-side problems (e.g. a sensor recorded the green; we can't change what was on the sensor).
What you do
- Upload the file.
- The diagnostic specifically reports glitch density and scope. For glitched files this is the most informative output — it tells you whether recovery will produce a clean file, a partly-clean file, or nothing watchable.
- The free preview shows you the actual recovery output before you decide.
FAQ
My recovered file is glitched but the original was fine before recovery. A bad recovery tool. Sometimes recovery tools introduce damage (wrong codec parameters, mis-aligned frames). Upload the original broken file — we may be able to recover it cleanly.
The file is glitched only at the start. Often a damaged SPS / VPS at the file's beginning. Recovery extracts codec parameters from a later keyframe and rebuilds with correct parameters; the glitches at the start often disappear because the decoder finally has the right initialisation.
The file is glitched only at the end. Truncation tail damage. Trim the bad tail and the rest plays clean. See file truncated.
Mid-file glitches in scattered locations. SD card / SSD bad sectors during recording. Recovery splices around the damage; the result will have brief jumps where the bad data was.
Can you recover from a card with bad sectors? The card-level recovery is a different problem (Disk Drill, R-Studio). Once you've extracted the file, our recovery handles the resulting glitches as well as any container-level tool can.
Is my footage safe? Server in France, auto-deleted after 48 hours, never used to train anything or shared. Privacy policy.
Related
Free preview · No commitment
Ready to recover your video?
Upload your file — get a free 5-second preview in about a minute. Pay only if the preview looks right.
Upload your video →