viewhack

Video and audio files: what is inside, will it play, and where was it filmed

Drop a video or audio file to play it here if this browser can, or to see which track and codec stops it. One line says whether a phone video carries the place it was recorded, and a button saves the frame on screen as a PNG. Below that: every track's codec and settings, and MediaInfo's complete report.

The file is read by this tab on your own device, in small pieces, so a 2 GB video works as well as a 2 MB one. It is never uploaded, so checking a video for its location does not hand the location to anyone.

What you get

How "will it play" is decided

A container such as MP4 or MKV is only the box; what a browser has to decode is each track inside it. The page works out each track's codec string, the short code browsers are asked about, and asks this browser two questions: canPlayType() on a media element and, where it exists, MediaSource.isTypeSupported(). The answer shown is this browser's own, on this device, not a table of what browsers usually do. The codec strings are in the track tables. Examples:

avc1.64001F
H.264, High profile (0x64 = 100), level 3.1 (0x1F = 31). H.264 with AAC audio in MP4 plays in every current browser.
hvc1.1.6.L93.B0
HEVC (H.265), Main profile, level 3.1 (93 = 3.1 × 30). What iPhones record by default ("High Efficiency"). Safari plays it; Chrome and Edge play it only where the device has a hardware HEVC decoder and the operating system exposes it; Firefox mostly does not. That is exactly why the answer is measured.
vp09.00.31.08, av01.0.08M.08
VP9 profile 0, level 3.1, 8-bit, and AV1 Main profile, level 4.0, 8-bit: the codecs of most WebM files and of YouTube downloads.
mp4a.40.2, opus, mp3, flac
AAC-LC (HE-AAC is mp4a.40.5), Opus, MP3 and FLAC audio.

Two honest caveats. The H.264 and HEVC strings are rebuilt from the profile and level MediaInfo reports, so the constraint bits may differ from the bytes in the file; browsers decide on profile and level. And MOV and 3GP files are asked about as video/mp4, because they are the same box structure and browsers read them with their MP4 reader. AVI and FLV are asked about under their own types, and current browsers answer no for both.

Where a phone video keeps its location

Phones write the position into a video the same way they do into photos, unless the camera app has no location permission. It is not EXIF: it sits in the file's moov box, which is usually at the start or the very end of the file. This page reads that box directly, with small reads, and never the video data itself.

iPhone and iPad
A metadata key named com.apple.quicktime.location.ISO6709, for example +55.6761+012.5683+010.000/: latitude, longitude and altitude in metres, in the ISO 6709 format. Next to it: com.apple.quicktime.make, model and creationdate.
Android phones, GoPro-style cameras, ffmpeg
A ©xyz atom in moov/udta holding the same kind of string without the altitude, for example +55.6761+012.5683/. Some 3GP files use a loci box instead, whose fixed-point numbers keep about five decimals.
How precise
Four decimals of a degree (0.0001°) is about 11 metres north–south: one building. 55.6761, 12.5683, the example here, is the square in front of Copenhagen City Hall.

Whether the location survives sharing depends on how the file travels. Messaging apps that re-compress a video usually drop it; e-mail attachments, cloud-drive links, AirDrop, and a chat app's "send as file" or "document" option pass the original bytes on, location included. On an iPhone, the share sheet's Options › Location switch leaves it out.

What it cannot do

MediaInfo is MediaArea's open-source media analyser (BSD-2-Clause), run here as mediainfo.js 0.3.8, a 2.6 MB WebAssembly build fetched from this site the first time you open a media file.