Ødelagt uafsluttet MP4- eller MOV-videofil efter drone-, GoPro- eller kamerabatteriets død¶

At trække microSD- eller CFexpress-kortet fra en DJI-drone efter et hårdt nedbrud, et GoPro-actionkamera efter et batteri-pop-out eller et Sony-, Canon-, Nikon-, Panasonic- eller Blackmagic-biografkamera, efter at batteriet døde midt i optagelsen under et bryllup, et dokumentarinterview eller en retsmedicinsk deponering, kun for at se en .MP4 eller .MOV fil, der nægter at åbne i VLC, QuickTime eller Premiere Pro (viser "00:00 duration", "This file isn't playable: 0xc00d36c4", eller "moov atom not found"), er en hjertestoppende produktionsnødsituation. Men så længe filstørrelsen i dit operativsystems filstifinder er stor (f.eks. 4.2 GB eller 18.6 GB i stedet for 0 KB), 99,9 procent af dine faktiske H.264-, H.265/HEVC- eller ProRes-videorammer og PCM/AAC-lydprøver sidder stadig fysisk intakte på flash-hukommelseschipsene. I ISO-basemediefilformatet (ISO/IEC 14496-12) brugt af .MP4, .MOV, og .M4V containere, kameraer streamer rå komprimerede video- og lydpakker sekventielt ind i en massiv nyttelastboks kaldet mdat (Media Data) atom, mens man holder masterframe-offset-tabellen, codec-parametre (SPS/PPS), og tidsstempler i flygtigt RAM, indtil du trykker på knappen Stop. Når strømmen afbrydes, før kameraet kan skylle den RAM-tabel til slutningen af filen som moov (Movie Metadata) atom, videoafspillere har ikke noget kort, der viser, hvor hver frame begynder inde i den multi-gigabyte binære stream. Ved straks at skrivebeskytte hukommelseskortet, optage eller vælge en 10-sekunders sund referencevideo fra nøjagtig det samme kamera ved at bruge nøjagtig samme opløsning, framerate og codec-indstillinger og køre en deterministisk Atom Header & Sample Table Rebuilder (untrunc, recover_mp4, eller native camera in-body recovery), kan du rekonstruere en smule perfekt moov indeksere og redde hvert billede helt op til millisekunders magt gik tabt. Hvis videoen blev optaget under en køretøjskollision, luftfartsulykke eller voldelig kriminalitet, hvor der opstod fysiske skader, skal du sikre stedet og ringe til din lokale alarmnumre (911 i USA og Canada, 999 i Det Forenede Kongerige, 112 i hele EU) først. For relaterede nødsituationer med hukommelseskort, lagring og filkorruption, se vores vejledninger om SD-kortkorruption, kamerahukommelseskortfejl og redning af bryllupsfotos, utilsigtet sletning af filer, formaterede drev og fotogendannelse, og beskadiget Word-, Excel-, PDF- og databasefilgendannelse.

Gør dette nu¶

1. Fjern hukommelseskortet fra kameraet med det samme, og skub den fysiske låseknap (hvis SD i fuld størrelse) til LÆSEKUN. Tryk aldrig på Optag-knappen igen på det hukommelseskort, slet aldrig andre klip på kortet, og lad aldrig Windows chkdsk eller macOS Disk Utility "Reparer" kortet før billeddannelse af det. Hvis det pludselige strømtab forlod kortets exFAT eller FAT32 Filallokeringstabel (FAT) med et ulukket filhåndtag (0 KB mappeindtastning), vil optagelse af selv et 5-sekunders testklip på det samme kort overskrive de ikke-allokerede klynger, der indeholder din multi-gigabyte videostream.
2. Tjek, om din drone eller dit kamera understøtter automatisk "In-Body Hardware Finalization" på et frisk batteri (Vent: Billed kortet først). Mange moderne kameraer (inklusive DJI-droner, GoPro Hero-kameraer, Sony Alpha .RSV filer og Panasonic Lumix .MDT filer) skrive en skjult midlertidig journalfil på kortet under optagelse. Hvis du sætter et fuldt opladet batteri i dronen/kameraet og tænder for det, registrerer kameraets firmware ofte den uafsluttede stream og syr automatisk moov header på 15 sekunder. Klon dog ALTID det rå kort til din computer først (trin 3) før du sætter kortet tilbage i kameraet, i tilfælde af at kameraets firmware fejler og sletter den forældreløse .RSV/.MDT fil.
3. Kopiér den beskadigede .MP4/.MOV/.RSV/.MDT fil (eller klon en bit-for-bit .img af hele kortet) til din computers interne SSD. Kør aldrig videoreparationsværktøjer direkte mod SD- eller CFexpress-kortet over en USB-læser. Kopier den ødelagte videofil til en dedikeret redningsmappe på din computers drev (C:\VideoRescue\ eller -/VideoRescue/). Hvis den beskadigede video viser 0 KB filstørrelse (eller mangler fuldstændigt i mappen, selvom kortets ledige plads viser 30 GB brugt), stop og afbild hele det fysiske hukommelseskort ved hjælp af ddrescue eller Win32DiskImager / DMDE før du løber chkdsk.
4. Find, eller optag på et ANDEN hukommelseskort, en "sund referencevideo" fra nøjagtigt det samme kamera med nøjagtig de samme indstillinger. Hver deterministisk moov atom reparationsværktøj (untrunc og recover_mp4) virker ved at læse codec-konfigurationsoverskrifterne (avcC for H.264, hvcC for H.265/HEVC, lydsamplingfrekvens, kanalantal og tidsbase) fra en fungerende .MP4/.MOV fil, der er optaget af det samme kamera og anvender denne plan for at analysere råmaterialet mdat stream af den ødelagte fil. Find et andet fungerende klip fra samme optagelse, eller indsæt et anden ekstra SD-kort i kameraet lige nu og optag et 15 sekunders klip med nøjagtig samme opløsning (f.eks. 4K 60fps 10-bit 4:2:2 HEVC).
5. ** Løb FFmpeg / FFprobe diagnostik, og genopbygg derefter moov header ved hjælp af untrunc (for H.264/H.265/ProRes) eller recover_mp4 (for Sony/Canon/DJI/GoPro).** Følg den nøjagtige kommandolinjesyntaks i vores tekniske sektioner nedenfor for at scanne råmaterialet mdat nyttelast, find hver NAL enhed (Network Abstraction Layer videoramme) og lydrammegrænse, og output en helt ny, spilbar _fixed.mp4 eller _fixed.mov fil uden at ændre din originale beskadigede kildefil.

Beslutningstræ: Diagnosticering og reparation af en uafsluttet eller beskadiget kameravideofil¶

flowchart TD
    A["Kamera-, drone- eller GoPro-videofil afspilles ikke efter batteridød, nedbrud eller korttræk"] --> B{"Undersøg filen på kortet (skrivebeskyttet): Hvad ser du?"}
    B -->|"1. Filen har normal stor størrelse (f.eks. 4,5 GB .MP4, .MOV, .RSV eller .MDT), men 00:00-varighed / 'moov atom ikke fundet'"| C["Klassisk uafsluttet beholder: Rå video-/lydrammer ('mdat') er 100 % intakte; kun 'moov' indeksfødder mangler"]
    B -->|"2. Filen viser en størrelse på 0 KB ELLER filen mangler, men ledig plads på kortet viser, at der stadig bruges gigabyte"| D["Ulukket exFAT/FAT32 Cluster Chain: KØR IKKE CHKDSK endnu; klon hele kortet til rå .img-fil med ddrescue/DMDE først"]
    C --> E["Kopiér beskadiget fil + 1 sund referencevideo (samme kamera, opløsning, FPS, codec) til computerens SSD"]
    E --> F{"Har dit kamera native In-Body Recovery (DJI, GoPro, Lumix .MDT, Sony .RSV)?"}
    F -->|"Ja (efter at have sikkerhedskopieret råfilen til pc først)"| G["Genindsæt kortet i drone/kamera med frisk batteri og tændt i 60 sekunder for at udløse hardware auto-finalisering"]
    F -->|"Nej (eller in-body gendannelse mislykkedes)"| H{"Hvilken codec/kameraarkitektur blev brugt?"}
    G -->|"Hvis stadig ikke kan spilles"| H
    H -->|"Standard H.264 / H.265 / ProRes Interleaved Stream"| I["Kør 'untrunc' (Anthwlock Fork): untrunc reference_good.mp4 corrupted_bad.mp4"]
    H -->|"Sony XAVC / Canon ALL-I / DJI / GoPro High-Bitrate Stream"| J["Kør 'recover_mp4': Udtræk headers fra godt klip -> Carve raw .h264/.hevc & .aac/.wav -> Remux med FFmpeg"]
    D --> K["Brug DMDE / R-Studio eller 'recover_mp4 --ext' på Raw Card-billedet for at gen-linke fragmenterede exFAT-klynger"]

Inde i ISO Base Media File Format: Hvorfor et dødt batteri dræber moov atom¶

For at forstå, hvorfor en 30-minutters, 25-gigabyte 4K-bryllupsceremonivideo bliver fuldstændig ulæselig, når et batteri dør i minut 29:59, skal du se på den interne binære anatomi af en .MP4 eller QuickTime .MOV fil.

Hver .MP4 og .MOV fil er struktureret som et hierarki af "bokse" eller "atomer", hver efterfulgt af et 4-byte-længde heltal og et 4-byte ASCII-id (FourCC):

1. ftyp (Filtypeboks - Bytes 0x00 til 0x1F i begyndelsen af filen):
2. Skrevet det øjeblik, du trykker på Optag-knappen. Identificerer beholderspecifikationen (f.eks mp42, isom, qt, eller Sonys XAVC).
3. mdat (Mediedataboks - optager 99,8 % af hele filen):
4. Når kamerasensoren optager video, og mikrofonen optager lyd, streamer hardwarekoderen komprimerede videorammer (I-frames / Keyframes, P-frames, B-frames) og lydpakker (PCM eller AAC) løbende ind i mdat boksen på SD-kortet.
5. Nøgledetalje: Inde i det rå mdat boks, er der ingen containeroverskrifter, der fortæller en medieafspiller, hvor videoramme #1.402 slutter og lydpakke #1.403 begynder. Det er blot en kontinuerlig multi-gigabyte flod af rå komprimerede bitstream bytes.
6. moov (Filmmetadataboks - Skrevet KUN til sidst, når du trykker på Stop):
7. Fordi kameraet ikke på forhånd kan forudsige, hvor lang tid du vil optage, eller hvor mange bytes hver variabel bitrate-frame vil tage, kan det ikke skrive indekstabellen i begyndelsen af filen. I stedet gemmer kameraet billedindekset i sin interne DRAM-chip, mens det optager.
8. Kun når du trykker på knappen Stop (eller når kameraets batteristyrings-IC udløser en yndefuld lavspændingsnedlukning ved 2 procent batteri), skyller kameraet dette DRAM-indeks helt til slutningen af .MP4/.MOV fil som moov atom, som indeholder seks undertabeller indeni moov -> trak -> mdia -> minf -> stbl (Eksempel på tabelboks):
   • stsd (Eksempelbeskrivelse): Codec-initialiseringsoverskrifter (SPS [Sequence Parameter Set] og PPS [Picture Parameter Set] for H.264/AVC; VPS/SPS/PPS for H.265/HEVC), der definerer opløsning, bitdybde (8-bit vs 10-bit), chroma subsampling (4:2:0 vs 4:2:2), og farveprofil (S-Log3, C-Log, D-Log).
   • stts (Time-to-Sample): Frame-varighed og framerate-timing.
   • stss (Synkroniseringsprøvetabel): Præcise placeringer af hver IDR Keyframe (I-frame) til skrubning og søgning.
   • stsc (Sample-to-Chunk) og stsz (Samplestørrelser): Den nøjagtige byte-længde af hver enkelt videoramme og lydpakke i optagelsen.
   • stco / co64 (64-Bit Chunk Offset Table): De nøjagtige byteadresser (0x...) peger ind i mdat boks, hvor hver eneste del af video og lyd bor.

Når en drone styrter ned og skubber sit batteri ud, et eksternt dummy-batterikabel bliver rykket ud, et SD-kort overophedes og afbrydes, eller et falsk batteri falder direkte fra 15 procent til 0 volt uden varsel, kameraet skriver aldrig moov atom i slutningen af filen, og forlader mdat boksens 4-byte/8-byte størrelse header indstillet til 0x00000000 (ubegrænset).

Kameraspecifik nødmatrix: Filudvidelser og tricks til automatisk gendannelse af hardware¶

Før du kører tredjepartssoftware, skal du kontrollere, hvordan dit specifikke kameramærke håndterer afbrudte optagelser. Kopiér altid den ødelagte fil fra kortet til din computer FØRST som en sikkerhedskopi, før du prøver et trick i kameraet:

Trin-for-trin Teknisk Playbook 1: Genopbygning af moov header med untrunc (Open Source Standard)¶

For 85 procent af uafsluttede .MP4 og .MOV filer (hvor filstørrelsen er normal, f.eks. 3.8 GB, og filen er ikke fragmenteret på en 0 KB ødelagt filsystem), det hurtigste, helt gratis, open source kirurgiske værktøj er det aktivt vedligeholdte anthwlock/untrunc gaffel (som tilføjede fuld understøttelse af moderne GoPro, DJI, Sony XAVC, H.265/HEVC og 64-bit co64 filer over 4 GB).

Trin 1: Bekræft skaden med FFprobe¶

Åbn Terminal (macOS/Linux) eller Kommandoprompt / PowerShell (Windows), og inspicér din ødelagte fil:

ffprobe -v error -show_format -show_streams broken_video.mp4

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x...] moov atom not found
broken_video.mp4: Invalid data found when processing input

Trin 2: Kør untrunc ved hjælp af din sunde referencevideo¶

1. Download den prækompilerede Windows GUI/CLI binær eller byg anthwlock/untrunc repository på macOS/Linux (eller kør det øjeblikkeligt via Docker uden at installere noget).
2. Placer begge din sunde referencevideo (healthy_reference.mp4, optaget på det samme kamera med nøjagtig samme opløsning, FPS og codec) og din kopi af den beskadigede video (broken_video.mp4eller Sony .RSV / Lumix .MDT) i samme mappe.
3. Kør genopbygningskommandoen:

   # Native Linux / macOS / Windows CLI command:
   untrunc -s healthy_reference.mp4 broken_video.mp4
   

   (Her, den -s flag instruerer untrunc at træde glat forbi eventuelle korrupte eller halvskrevne bytes i slutningen af mdat stream, hvor batteriet døde.)
4. Hvordan untrunc virker under hætten:
5. For det første untrunc analyserer healthy_reference.mp4 for at udtrække de nøjagtige codec initialiseringsordbøger (avcC / hvcC), lydrammestørrelser, spor-id'er og interleaving-rytme.
6. For det andet åbner den broken_video.mp4, hopper til starten af mdat atom, og går sekventielt gennem hver eneste video NAL enhed og lydpakke, der optager den nøjagtige byte-længde (stsz) og 64-bit byte offset (co64) af hver frame.
7. For det tredje syntetiserer den en helt ny moov atom, tilføjer det til strømmen, opdaterer mdat byte-længde header, og skriver en ny fil med navnet broken_video.mp4_fixed.mp4 (efterlader din original broken_video.mp4 uberørt).

Trin 3: Rens og genindekser den reparerede fil med FFmpeg Stream kopi (tabsfri)¶

En gang broken_video.mp4_fixed.mp4 er genereret, køre en tabsfri FFmpeg beholder remux med +faststart flag (som flytter den nyligt genopbyggede moov atom helt forrest i filen og renser enhver efterfølgende halv-frame tidsstempelfejl fra det øjeblik, batteriet døde):

ffmpeg -err_detect ignore_err -i broken_video.mp4_fixed.mp4 -c copy -movflags +faststart final_rescued_video.mp4

Trin-for-trin Teknisk Playbook 2: Brug af recover_mp4 til komplekse Sony .RSV, Canon, DJI og ProRes-streams¶

Hvad nu hvis untrunc producerer en video, hvor lyden går ude af synkronisering eller fejler, fordi dit kamera bruger ukomprimeret 16-bit/24-bit lineær PCM-lyd (twos / sowt) sammen med Sony XAVC-S, Canon ALL-I eller DJI D-Log M med høj bithastighed?

Brug det andet industristandard retsmedicinske værktøj: recover_mp4 (oprindeligt udviklet af Dmitry Vasilyev / Restore.Media CLI). I modsætning til untrunc, recover_mp4 adskiller den rå elementære videostream (.h264 eller .hevc) og rå elementær lydstream (.aac eller .wav) i to separate filer, som du derefter muxer rent sammen igen med FFmpeg:

1. Trin 1 - Analyser den sunde referencefil for at udtrække codec-headere:

   recover_mp4.exe healthy_reference.mp4 --analyze
   

   Dette læser den sunde fil og udsender to bittesmå binære header blueprint-filer i din mappe: video.hdr (indeholder den nøjagtige SPS/PPS codec-tabeller) og audio.hdr (og udskriver de nøjagtige kommandoflag, der skal bruges til din specifikke kameramodel på skærmen).
2. Trin 2 - Udskær de elementære video- og lydstreams fra den beskadigede fil:

   # Use the camera-specific flag suggested by --analyze (e.g., --sony, --canon, --dji, --gopro, --panasonic):
   recover_mp4.exe broken_video.RSV recovered_video.h264 recovered_audio.wav --sony
   

3. Trin 3 - Kombiner de reddede video- og lydstreams til en rengøring .MP4 eller .MOV via FFmpeg:

   # Replace -r 29.97 (or 23.976 / 59.94 / 25 / 50) with your exact camera framerate:
   ffmpeg -r 29.97 -i recovered_video.h264 -i recovered_audio.wav -c:v copy -c:a copy -movflags +faststart final_sony_rescued.mp4
   

Trin-for-trin Teknisk Playbook 3: Redning a 0 KB eller "Forsvundet" videofil (GoPro / Sony Fragmented Allocation Trap)¶

Hvad hvis din beskadigede videofil viser 0 KB, eller vises slet ikke i mappen, efter at batteriet døde, selvom Properties på SD-kortet viser 45 GB plads er stadig optaget?

Hvorfor standardfilgendannelsessoftware mislykkes på GoPro-, DJI- og Sony-kort¶

Når en normal computer skriver en fil til en exFAT kort, skriver den filen i en sammenhængende blok af sektorer. Hvis denne fil slettes, kan enhver grundlæggende filudskærer (f.eks PhotoRec) kan scanne fra begyndelsen af ftyp header indtil slutningen af filen og gendan den.

Moderne 4K/5K/8K-kameraer skriver IKKE sammenhængende filer. - Mens du optager en 4K 60fps video (GX010055.MP4), et GoPro, DJI drone eller Sony Alpha kamera skriver samtidigt to eller tre streams til SD-kortet på nøjagtig samme tid: 1. Den vigtigste høj opløsning .MP4 video stream; 2. En proxy-videostream i lav opløsning (.LRV på GoPro, .LRF på DJI, eller sub-klip proxy på Sony) for live smartphone app forhåndsvisning; og 3. A .THM thumbnail eller telemetrilog. - Fordi kameraet skiftevis skriver et par megabyte af hovedet .MP4 efterfulgt af et par hundrede kilobytes af .LRV proxy på tværs af kortets exFAT klynger, de vigtigste .MP4 video er opdelt i hundredvis af ikke-sammenhængende fragmenter sammenflettet med .LRV bidder. - Hvis batteriet dør før exFAT bibliotekstabel registrerer klyngekæden (0 KB filstørrelse), at køre en standard sammenhængende filudskærer vil øse op .LRV proxy bidder lige i midten af 4K .MP4 stream og skaber en beskadiget mosaik hvert 3. sekund.

Sådan redder du en 0 KB Fragmenteret kamerastream:¶

1. Opret et fuld bit-for-bit rå-billede (.img eller .bin) på hukommelseskortet Først:
2. Brug DMDE (DM Disk Editor og Data Recovery), R-Studio eller Linux/macOS ddrescue (ddrescue -d /dev/diskX sdcard_raw.img sdcard.log) for at klone hver sektor af 64 GB / 128 GB / 256 GB-kortet til en enkelt .img fil på din SSD.
3. Inspicér exFAT Tildeling Bitmap i DMDE (Før berøring chkdsk):
4. Selv når indtastningen af filnavnet i CLIP siger biblioteket 0 Bytes, den exFAT Allokeringsbitmap viser ofte stadig de nøjagtige besatte klynger.
5. Brug fragment-bevidst videoudskæring (recover_mp4 på råbilledet eller Specialized Fragmented Carvers):
6. Punkt recover_mp4 direkte på rå .img diskbilledfil (ved hjælp af video.hdr uddraget fra et sundt klip, der er skudt på det samme kort), eller brug en kameratildelingsbevidst retsmedicinsk udskærer (såsom SanDisk RescuePRO Deluxe [som inkluderer en gratis 1-års licenskode i detailkassen til hvert ægte SanDisk Extreme Pro SD-kort], Klennet Carver eller **Disk Recueil 5+ Advanced Camera/DJI GoPro Mode) klynge-sammenflettede skridt af GoPro (MP4 + LRV), DJI (MP4 + LRF), og Sony (XAVC + Proxy) firmware.

Regionale alarmnumre og agenturprotokoller¶

Ofte stillede spørgsmål¶

Hvorfor kunne VLC Media Players indbyggede "Repair Video File" popup ikke rette min uafsluttede .MP4?¶

VLC Media Players automatiske "Beskadiget eller ufuldstændig AVI-fil - Byg indeks og afspil"-funktion er næsten udelukkende designet til ældre `.AVI` (`RIFF`) beholdere, IKKE til moderne ISO-basemedier `.MP4` eller `.MOV` kamerafiler. I en `.AVI` fil, har hver enkelt frame inde i datastrømmen et tydeligt 4-byte ASCII-tag (`00dc` til video, `01wb` for lyd), så VLC blindt kan scanne en `.AVI` uden at kende kameraindstillingerne. I en `.MP4` eller `.MOV` fil, den rå `mdat` nyttelast indeholder nul containermarkører og codec initialiseringsparametre (`SPS` og `PPS` borde indenfor `avcC`/`hvcC`) lever kun inde i de savnede `moov` atom i slutningen af filen. Derfor kan VLC ikke afspille en uafsluttet `.MP4`, og hvorfor du skal bruge `untrunc` eller `recover_mp4` med en sund referencevideo fra det samme kamera til at forsyne de manglende `SPS/PPS` blueprint.

Hvad hvis jeg ikke har en anden video fra præcis det samme optagelser til at bruge som "Healthy Reference File"?¶

Du behøver IKKE en video fra samme dag eller samme sted. Du kan tage præcis det samme kamera, drone eller GoPro lige nu (selv uger senere), sætte et andet, tomt SD-kort i, kontrollere at kameramenuen er indstillet til nøjagtig samme opløsning, framerate, codec (`H.264` vs `H.265`), Bitdybde (`8-bit` vs `10-bit`), og lydformat, som du brugte, da styrtet skete, og optag en 10-sekunders video af dit skrivebord. Det splinternye 10-sekunders klip vil have nøjagtig det samme `stsd` (`avcC`/`hvcC`) codec header ordbog påkrævet af `untrunc` og `recover_mp4` for at låse din ødelagte fil op.

Hvordan ved jeg, om et "gratis online MP4-reparationswebsted" (restore.media, fix.video, cleverfiles) er sikker, eller hvis de forsøger at snyde mig?¶

De fleste kommercielle online videoreparationswebsteder kører automatiske cloud-indpakninger omkring den samme open source `untrunc` og `recover_mp4` / `FFmpeg` algoritmer, der er beskrevet i denne vejledning, lader dig uploade din ødelagte fil og en referencefil, vise dig 4 vandmærkede miniaturebilleder i lav opløsning, der beviser, at din video kan gendannes, og derefter kræve $49 til $149 pr. fil for at downloade den reparerede `.MP4`. Før du betaler en online portal, skal du køre den gratis open source `anthwlock/untrunc` eller `recover_mp4` CLI dig selv på din egen computer; ikke alene er det 100 procent gratis, du undgår også at uploade 30 gigabyte private bryllups-, klient- eller juridiske optagelser til en tredjeparts cloud-server.

Min reparerede video afspiller fint, men de sidste 1,5 sekund lige da dronen ramte træet mangler. Kan de sidste 45 billeder gendannes?¶

Normalt nej, og her er hardwarefysikkens grund til hvorfor: Moderne kameraer og droner bruger højhastigheds SDRAM-ringbuffere mellem billedprocessoren (`ISP / Encoder`) og SD-kortbussen. Når kameraet koder video til en gruppe billeder (`GOP`, typisk 15 til 60 billeder lang), holder den den aktuelle 1-til-2-sekunds buffer i flygtig RAM, før den skylles ud i multi-megabyte bursts til SD-kortets NAND-flash. Den øjeblikkelige batterispænding falder til nul under et hårdt nedbrud, uanset hvilke rammer der sad i flygtigt SDRAM (typisk de sidste 0,5 til 2,0 sekunder af optagelser) forsvinder, før de nogensinde krydser SD-kortstifterne. Alt er allerede skyllet til `mdat` atom på kortet er det, der bliver reddet.

Hvordan kan jeg forhindre uafsluttet .MP4 katastrofer på kritiske bryllups-, dokumentar- eller biografoptagelser i fremtiden?¶

Professionelle filmfotografer og lydmixere bruger tre hardwaresikringer mod at gå glip af `moov` atomer: (1) Brug dobbelt-slot samtidig relæ/backup-optagelse (`Slot 1 + Slot 2 Simultaneous`): hvis et overophedet eller aldrende SD-kort falder offline midt i optagelsen, fortsætter det andet kort med at optage og afslutter rent. (2) Optag i fragmenteret MP4 (`fMP4`), `.MXF`, eller rammeuafhængige formater (`Blackmagic RAW .BRAW` eller `ProRes RAW`) hvor tilgængeligt: i modsætning til standard `.MP4`/`.MOV` som venter til slutningen af en 60-minutters tage med at skrive en enkelt monolitik `moov` atom, Fragmenteret MP4 (`fMP4`, brugt af OBS Studios Hybrid MP4-tilstand og udsendelse `.MXF` wrappers) skriver en mini-header (`moof` - Movie Fragment atom) hvert 2. sekund i hele filen, så hvis strømmen afbrydes under en 2-timers optagelse i `fMP4` eller `.MKV`, 100 procent af videoen afspilles med det samme uden reparationsværktøjer. (3) Brug altid kabelbinde-attrap-batterier og eksterne USB-C PD- eller V-mount-kabler, så en kardan eller stativ ikke kan trække strømmen midt på vej.

Relaterede guider¶

• SD-kortkorruption, kamerahukommelseskortfejl og redning af bryllupsfotos
• Utilsigtet sletning af filer, formaterede drev og fotogendannelse
• USB-flashdrev ødelagt stik, ukendt beskrivelse og monolitgendannelse
• Harddiskfejl og datagendannelse

Kilder og officiel vejledning¶

• International Organisation for Standardization (ISO): ISO/IEC 14496-12 (Informationsteknologi - Kodning af audiovisuelle objekter - Del 12: ISO-basemediefilformat: ftyp, mdat, moov, og stbl Eksempeltabelspecifikationer) og Apple Inc. QuickTime-filformatspecifikation.
• Scientific Working Group on Digital Evidence (SWGDE, USA): SWGDE Best Practices for Recovery of Damaged Digital Video and Forensic Reconstruction of Unfinalized ISO Base Media Containers.
• FFmpeg Project & Open-Source Video Forensics Dokumentation: FFmpeg / Libavformat MOV/MP4 Demuxer Architecture, anthwlock/untrunc Sporrekonstruktionsmotor, og recover_mp4 Elementære strømudskæringsprotokoller.
• Sony Corporation & DJI officielle tekniske supportbulletiner: Sony Memory Card File Rescue for afbrudt XAVC .RSV Clips og DJI Aircraft Firmware Auto-Finalization Procedures.
• National Institute of Standards and Technology (NIST): Standarder for digital dataindsamling og filudskæring.