DigitalForensics

70 13 63 23

Videometadata: MP4/MOV‑strukturer og optagetid

Videometadata: MP4/MOV-strukturer og optagetid

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

En video fra en telefon eller et kamera bærer sin optagetid inde i selve containeren, ikke kun i filsystemet. I MP4 og MOV ligger tidsstemplerne i bestemte bokse i filens struktur, og de kan ofte sige mere om optagelsen end filens oprettelsesdato. Men feltet, der kaldes oprettelsestid, er ikke altid skrevet i UTC, som formatet foreskriver, og en video, der er sendt gennem en beskedtjeneste eller redigeret, har ofte fået helt nye værdier. Uden kendskab til, hvilket program der har skrevet filen, kan tidsstemplet ikke fortolkes sikkert.

Grundviden om video som bevis står på hubben i Fotos og video som bevis. Her går vi ned i filstrukturen.

Containeren: bokse i et træ

MP4 bygger på ISO Base Media File Format, som igen stammer fra Apples QuickTime-format (MOV). De to formater deler grundstrukturen: filen består af bokse (i QuickTime kaldet atomer), som hver har en længde, en type på fire tegn og et indhold, der kan rumme flere bokse.

  • ftyp · Filtype og kompatible varianter (brand), fx isom, mp42 eller qt
  • moov · Al beskrivelse af filen: varighed, spor, tidsstempler og metadata
  • mvhd · Filmens overordnede oprettelses- og ændringstid, tidsskala og varighed
  • trak, tkhd, mdhd · Pr. spor (video, lyd, metadata) egne tidsstempler og varighed
  • udta og meta · Brugerdata: producent, model, software, placering og nøgle-værdi-felter
  • mdat · Selve de komprimerede video- og lyddata

Selve billedet og lyden ligger i mdat. Alt det, der beskriver optagelsen, ligger i moov. Det betyder, at metadata kan ændres eller fjernes, uden at et eneste billede i videoen ændres, og omvendt.

Tidsstemplerne og deres epoke

I mvhd, tkhd og mdhd findes felterne creation_time og modification_time. Formatet angiver dem som sekunder siden 1. januar 1904 i UTC, i 32 eller 64 bit afhængigt af boksens version. En værdi på nul betyder, at feltet ikke er udfyldt, og vises i nogle værktøjer som 1904 eller 1970.

I praksis er billedet mere broget:

  • Nogle kameraer og programmer skriver lokal tid i felterne, selvom formatet foreskriver UTC. Et værktøj, der omregner til lokal tid, lægger så en eller to timer ekstra til.
  • Apple-enheder skriver typisk en separat optagedato som tekst i meta-boksen under nøglen com.apple.quicktime.creationdate. Apple dokumenterer værdien som en tekststreng, og i optagelser fra iPhone indeholder den normalt en tidszoneforskydning, fx +0200. Den er da ofte det mest præcise felt, fordi tidszonen fremgår direkte. Android-telefoner bruger ikke denne nøgle på en ensartet måde, så feltet skal aflæses i den konkrete fil.
  • Android-producenter varierer. Nogle skriver UTC i mvhd, andre lokal tid, og nogle tilføjer egne felter.
  • Placering kan ligge som en tekststreng i ISO 6709-format i udta eller meta, fx som koordinater med fortegn.

Feltnavnene i analyseværktøjer er ikke standardiserede. Det samme felt kan hedde CreateDate, MediaCreateDate eller TrackCreateDate i et værktøj og noget helt andet i et andet. Notér derfor både boks, rå værdi og værktøjets tolkning. Generelle tidsformater og epoker er samlet i Tidsstempelformater.

Genkodning og behandling

Når en video sendes gennem en beskedtjeneste, uploades til en platform eller redigeres, bliver den ofte genkodet. Det betyder typisk:

  • nye eller nulstillede tidsstempler i mvhd og tkhd, ofte lig med tidspunktet for genkodningen,
  • fjernede felter i udta og meta, herunder placering og model,
  • ny encoder-angivelse, fx et biblioteksnavn i stedet for kameraets firmware,
  • andre opløsninger, bitrater og codec-parametre end kameraet normalt skriver,
  • en anden rækkefølge af boksene, fx moov placeret før mdat for hurtig afspilning.

Hvordan de enkelte tjenester behandler metadata, er beskrevet i Metadata, der fjernes ved upload og deling. Pointen her er, at en video uden kameraets metadata ikke er mistænkelig i sig selv. Den har bare været igennem en kæde af programmer, og de oprindelige oplysninger findes i så fald kun på den enhed, der optog den, eller i en backup af den.

Strukturelle tegn på redigering

Ud over felterne siger selve strukturen noget om filens historie:

  • Rækkefølge og sæt af bokse. Kameraer fra samme producent skriver typisk de samme bokse i samme rækkefølge. Afvigelser fra en referencefil fra samme model og firmwareversion tyder på, at filen er behandlet af et andet program.
  • Encoder- og softwarefelter. Navnet på et redigeringsprogram eller et genkodningsbibliotek viser, at filen er skrevet af dette program.
  • Spor og varighed. Forskel på sporenes varighed, ekstra spor eller uventede redigeringslister (edts og elst) kan pege på klip eller sammensætning.
  • Frie områder. Bokse af typen free eller skip er normale, men kan indeholde rester af tidligere indhold, hvis et program har overskrevet metadata på stedet.

Tegnene viser behandling, ikke hensigt. Tekniske tegn på redigering af stillbilleder er beskrevet i Redigerede billeder, og meget af tankegangen gælder også for video.

Sikring

Hvilket eksemplar der undersøges, afgør, hvad der kan konkluderes:

  1. Bedst: filen fra den optagende enhed, sikret ved et udtræk med filsystemets tidsstempler og enhedens mediedatabase. På iPhone rummer mediebiblioteket egne felter om optagelse, import og redigering, se Photos.sqlite.
  2. Godt: filen fra en backup eller cloudtjeneste med originalkvalitet, eksporteret med versionsoplysninger.
  3. Svagt: en fil modtaget via beskedtjeneste, mail eller download fra en platform.

Beregn hashværdien med det samme, og arbejd kun på kopier. Åbn ikke videoen i et redigeringsprogram, der kan gemme ændringer, og undgå at “eksportere” den fra et galleri, fordi eksporten kan genkode filen. Hashværdien skal dække hele filen, ikke kun videostrømmen. Se Hashalgoritmer.

Typiske fejlkilder i fortolkningen

  • Dobbelt tidszonekonvertering. Lokal tid gemt som UTC og derefter konverteret til lokal tid giver en fejl på en eller to timer. Afprøv med en testoptagelse fra samme enhedsmodel og indstilling, og notér resultatet.
  • Sommertid. En optagelse fra vinterhalvåret, der vurderes i sommerhalvåret, kan få forkert forskydning, hvis værktøjet bruger dagens regel.
  • Enhedens ur. Står uret forkert, er alle felter forkerte. Sammenlign med andre kilder fra samme enhed og samme periode.
  • Varighed og starttid. Nogle enheder sætter oprettelsestiden ved optagelsens slutning, andre ved starten. Forskellen er videoens varighed.
  • Filsystemets tidsstempler. Kopiering og download giver nye datoer i filsystemet, mens containerens felter bevares. De to sæt må ikke blandes sammen.

Afvigelser forklares bedst ved at lave kontroloptagelser med samme model, version og indstillinger og sammenligne strukturen. Den måde at håndtere tidszoner på i rapporten er beskrevet i UTC og sommertid i rapporten.

Hvad videometadata kan og ikke kan bevise

Metadata kan understøtte, at en video er optaget med en bestemt type enhed på et bestemt tidspunkt, og at filen ikke er behandlet af andre programmer. Metadata kan ikke alene bevise, hvor eller hvornår noget skete, fordi felterne kan ændres og afhænger af enhedens ur og indstillinger. Fravær af metadata beviser intet om ægtheden. Den stærkeste konklusion opnås, når containerens felter, enhedens mediedatabase, filsystemet og uafhængige kilder som cloudlogs eller beskeder peger på det samme.

I rapporten

Angiv hashværdi, kilde og sikringsmetode for filen. Gengiv de relevante felter med boks, rå værdi og fortolket tid i UTC og lokal tid, og skriv, hvordan tidszonen er fastlagt. Beskriv referenceoptagelser, hvis de er brugt, og hold fund om behandling adskilt fra vurderingen af, hvad der er sket i den virkelige verden.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Metadata, der forsvinder ved upload og deling · Digitale signaturer i PDF: teknisk validering og tidsstempling

→ Teknisk undersøgelse af dokumenter og metadata · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik

John Nielsen, IT-sagkyndig

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.