- Nationwide Digital Forensic & Cyber Investigation Services
Movie header dates, QuickTime text keys, encoder strings, and geographic coordinates describe different parts of a recording's history. Their storage paths and time conventions determine what each value can support.
Home › Digital Evidence Authentication › Video Evidence Authentication › Video Metadata Analysis: Dates, Devices and GPS
Quick Answer. Video metadata analysis reads internal fields to assess recording dates, device claims, software history, and location. Examiners distinguish numeric movie header times from textual QuickTime creation dates, retain explicit timezone offsets, and compare device and encoder values with source records. Metadata can be copied, rewritten, or removed, so its agreement with independent evidence matters more than a plausible displayed date.
Within Video Evidence Authentication, this guide addresses the meaning of stored metadata rather than visual appearance. Read it alongside MP4 and MOV structure and social media and screen recorded video to distinguish capture fields from information introduced during conversion or delivery.
| Question | Short answer |
|---|---|
| What does video metadata analysis examine? | It examines container dates, track dates, textual metadata, device identifiers, encoder information, and location records. The examiner records each field's actual storage path, raw value, conversion rules, and relationship to the submitted source. |
| What epoch does MP4 mvhd creation_time use? | The specified epoch is 1 January 1904 at 00:00:00 UTC. Version 0 stores creation and modification times in 32 bit fields; version 1 uses 64 bit fields. Actual writers sometimes depart from the specified clock convention. |
| Which QuickTime key stores a textual creation date? | com.apple.quicktime.creationdate can store a textual date with a timezone offset. It is distinct from the numeric creation_time in mvhd and must be extracted and interpreted separately. |
| Can video make and model metadata prove device origin? | No. Make and model are writable claims. Consistency with a source device, native file patterns, track configuration, and collection records makes attribution stronger than the strings alone. |
| Where can ISO6709 location appear in video metadata? | QuickTime metadata can use com.apple.quicktime.location.ISO6709. Legacy location atoms such as the copyright xyz field can also occur. Preserve the exact key and original coordinate string. |
| Does a video encoder tag prove a clip was manipulated? | An encoder tag identifies a declared software or encoding component. It can result from initial capture, export, or conversion. Test the surrounding structure and acquisition history before describing the significance of that software. |
Movie header creation value expressed as seconds relative to the specified 1904 epoch.
Media header dates associated with an individual track's media rather than the movie as a whole.
A metadata key namespace used with indexed keys and corresponding item values.
A textual QuickTime date key whose value can include an explicit civil time offset.
A textual manufacturer claim in QuickTime metadata.
A textual device model claim separate from the codec sample entry.
A signed geographic position representation containing latitude and longitude, optionally altitude.
Text in supplemental enhancement information within a coded stream, distinct from container metadata.
Read the movie header version before decoding its date fields. After the size and type, mvhd begins with a version byte and three flag bytes. In version 0, creation_time and modification_time occupy four bytes each. In version 1, each occupies eight bytes. Values use big endian byte ordering. A field shifted by an incorrect version assumption can produce a plausible but false date.
| Stored observation | Interpretation | Reporting action |
|---|---|---|
| Version 0 creation value 7C 25 B0 80 | Decimal 2082844800, corresponding to 1 January 1970 UTC under the specified epoch | Show the integer and the conversion basis |
| Version 1 date | Eight byte unsigned seconds value | Do not read only its first four bytes |
| Zero creation value | Mathematical epoch date, often an unset placeholder in practice | Do not present 1904 as an actual recording date without context |
| Movie and track dates differ | Different objects or writing stages may be represented | List mvhd, tkhd, and mdhd values separately |
| timescale 1000, duration 12345 | Movie duration is 12.345 seconds | Do not interpret duration as a calendar timestamp |
For modern values within an ordinary conversion range, subtracting 2082844800 converts the 1904 based seconds to seconds since 1 January 1970 UTC. Preserve the original integer even when the report uses an ISO style date. This makes an epoch mistake visible and permits another examiner to reproduce the interpretation without relying on a parser's display settings.
The type bytes for mvhd are 6D 76 68 64. The corresponding tkhd and mdhd types are 74 6B 68 64 and 6D 64 68 64. Read each within its proper parent hierarchy. A text search for those letters is not a substitute for parsing boxes, because the same sequence can occur in unrelated payload data.
The format convention specifies UTC, but some devices or software write local clock values into numeric fields. Record the literal stored interpretation first. Evaluate any proposed local clock correction using known device behavior and independent anchors. Do not silently change the date to make it match the incident narrative.
Supply the native recording if available, the received copy, and the claimed capture place and time. We can map each date to its actual field, identify conversions, and compare device and location claims with independent records.
Request Confidential Consultation Call (833) 292 3733QuickTime metadata may appear through a meta structure containing keys and ilst records, often associated with moov. In an indexed metadata arrangement, entries in keys identify names and namespace values; corresponding ilst items refer to those key indexes. Other files use udta atoms or legacy item types. Record the actual path instead of flattening every value into a generic camera field.
| QuickTime key or field | Example value | Evidence question |
|---|---|---|
| com.apple.quicktime.creationdate | 2025 June 15, 14:30:00 with offset UTC plus 02:00 | Does its explicit civil time agree with numeric header dates? |
| com.apple.quicktime.make | Apple | Is the manufacturer claim supported by native acquisition? |
| com.apple.quicktime.model | iPhone 15 | Do dimensions, stream parameters, and source records fit? |
| com.apple.quicktime.software | Operating system or application version string | Does it describe capture, processing, or export? |
| com.apple.quicktime.location.ISO6709 | +37.3317+122.0301/ | Are the signs, precision, and claimed location consistent? |
A numeric item identifier does not carry an inherent meaning independent of the keys table. If two files assign the creation date to different key indexes, their semantic values may still match. Conversely, the same numeric item index in two files can refer to different keys. Preserve the key table and value mapping when preparing comparison evidence.
Make and model are not hardware attestation. They can survive a remux, be copied into an edited export, or be added manually. Stronger attribution combines a native source acquisition with matching file organization, capture settings, track behavior, and device records. A claimed model with impossible supported features deserves investigation; a compatible model string alone remains a weak identifier.
Action cameras, drones, and dashcams may store timed position and sensor records in dedicated tracks. Preserve those tracks and their sample timing alongside static metadata.
Read latitude and longitude as separate signed quantities and preserve the exact string. In a decimal degree example, +37.3317+122.0301/ means north latitude and east longitude. Changing the second sign changes the hemisphere. The terminal slash is part of the common representation, not an extra coordinate. Optional altitude and additional conventions require format aware parsing.
Four decimal places describe numerical resolution, not proof of a measurement accurate to that resolution. Coordinates may come from device location services, a manually supplied value, or a prior asset whose metadata was retained. A location written once for a movie need not describe every frame of a moving recording. Compare it with visible geography and any timed telemetry.
A textual creation date carrying UTC plus 02:00 at 14:30 corresponds to 12:30 UTC on that same date. The offset is essential evidence. Preserve the displayed civil time, offset, and normalized UTC value as separate report columns. Do not append a UTC designation to an unzoned value merely because analysis software uses UTC internally.
A numeric offset is not a complete named timezone. Several regions can share it, and seasonal clock rules can vary historically. Determine the claimed jurisdiction and incident date before applying daylight saving rules. At an autumn clock change, a local time without an offset can refer to two different instants; at a spring transition, some local times do not occur.
If mvhd reads 14:30 UTC and a text key reads 14:30 with UTC plus 02:00, the two values describe instants two hours apart under their literal conventions. Possible explanations include a local clock written into the numeric field, rewriting during export, or an inaccurate device clock. Test these alternatives against source recordings and known events rather than selecting whichever date looks convenient.
An encoder string can identify a component used during capture or later processing. Its evidentiary value depends on where it is stored. A container software field, a stream codec identifier, and an x264 settings string carried in SEI are different observations. List their paths and relationships rather than reporting that one application created the entire recording.
A remux changes the container arrangement while potentially preserving compressed sample bytes. Encoding again creates new compressed pictures and can rewrite codec parameters, timing, and metadata. A new movie date and unchanged stream do not mean the same thing as a new encoder configuration and altered sample data. Compare actual streams when originals and derivatives are both available.
A defensible report identifies an inconsistency precisely: the QuickTime text creation value differs from the specified interpretation of mvhd by two hours, or the derivative contains a software field absent from the source. It then states the corroboration needed to resolve the difference. Metadata alone cannot establish who edited the clip, what was changed, or whether depicted conduct occurred.
Build a comparison record that another examiner can recalculate. The procedure keeps stored values, parser presentation, and interpretation distinct.
We prepare field mapped video metadata findings that retain raw values, explain date conversions, and separate device claims from corroborated source attribution. Our analysis compares native and delivered assets where available and identifies the records needed to resolve conflicting clocks or location claims. Our team is made up of subject matter experts in video metadata analysis who reconcile creation dates, device tags, and GPS values with phone and cloud records.
Elite Digital Forensics is an independent digital forensics practice serving attorneys, paralegals, in house counsel, insurers, lenders, businesses, and individuals nationwide. Our team includes former law enforcement forensic examiners and court qualified expert witnesses in computer, cell phone, cloud, document, and multimedia forensics. Every engagement begins with a scoped plan, hash verified evidence handling, and a clear explanation of what the examination can answer.
Yes. Container metadata can be rewritten while compressed pictures remain unchanged. Compare media samples as well as file hashes when the distinction matters.
A zero or unset numeric field can render as the epoch. Inspect the stored integer and writer behavior before treating that display as an actual capture date.
No. The key is a writable metadata claim and can persist through processing. Direct source attribution requires acquisition context and corroborating device or file evidence.
Sometimes external evidence supports a timezone interpretation, such as source settings and known events. An unzoned date alone does not uniquely identify an instant. Report the assumption and alternatives.
No. Permissions, settings, capture applications, exports, and delivery routes affect location retention. Absence does not establish where a clip was recorded or whether location data was deliberately removed.
Not automatically. File system dates can describe copying or export. Compare them with internal fields and acquisition records, and label each date according to the event it actually supports.
Describe the disputed date, device, or location claim and identify every available version of the recording. Preserve native assets and transfer records so we can test the relationship between capture fields, processing history, and delivered copies. As court qualified experts in video metadata, we can explain a date or location conflict in plain language.
Request Confidential Consultation Call (833) 292 3733This content is for educational and informational purposes only and does not constitute legal advice. Elite Digital Forensics provides independent digital forensic services and expert witness testimony; we do not provide legal representation. Every case is fact specific; outcomes depend on the evidence, jurisdiction, and counsel. Retain qualified legal counsel for advice about your matter.
Elite Digital Forensics Assistant
By submitting this form, you consent to be contacted by email, text, or phone. Your information is kept secure and confidential. Reply Stop to opt out at anytime.
IMPORTANT: Please remember to check your spam or junk folder