Media Inspector

Drop the file onto the page. The summary names the container and the codec of the picture and the sound — H.264, HEVC, VP9, AV1, AAC, Opus and so on — and the stream list adds the profile, the codec tag, and the bitrate for each track separately. Nothing is uploaded: FFmpeg reads the file inside the browser tab, which you can confirm from the network panel while it runs.

The overall bitrate appears in the summary, and each stream shows its own where the container recorded one. MP4 and MOV usually store per-track bitrates; MKV and WebM store none at all, so those tracks show nothing rather than a figure the tool made up. Pressing Count settles it exactly, by measuring how many bytes the picture and the sound really took.

No. The engine is FFmpeg compiled to WebAssembly and it runs inside your browser tab. The file is read from disk into the tab's memory and nothing about it crosses the network. That is the reason to use a local inspector for interview recordings, client footage, or anything captured from an internal system.

The container is the file format itself — MP4, MKV, WebM — and it holds the streams plus the timing and index information that keeps them playable. The codec is how the picture and sound inside are compressed, such as H.264 or AAC. A player can support a container and still fail on what is inside it, which is why an MP4 that refuses to open is a normal problem rather than a contradiction, and why this tool reports both separately.

Because the file is not stored the way it is meant to be shown. A phone records in the sensor's landscape orientation and writes a rotation tag alongside, so the correct picture is the stored frame turned by the amount that tag specifies. Software that honours the tag shows it upright, software that ignores it shows it on its side. The findings panel says whether a rotation tag is present and what the file should look like once it is applied.

An MP4 stores its sample table in a box called moov — the map a player needs before it can show a single frame. Encoders that write files sequentially put it after the video data, so a browser may need extra range requests before playback begins. If the server does not support byte-range requests, it can wait for most or all of the file, which looks like a long freeze. Moving that box to the front is what "faststart" means. This tool reads the box order out of the file directly, because no FFmpeg output reports it.

The average and base frame rates describe different timing values, so a difference is a useful warning to inspect rather than a verdict that the file is variable frame rate. Count adds the actual packet total and compares it with the header’s estimate. A mismatch can come from rounded duration or timing fields as well as unusual timestamps; confirming variable frame rate requires a per-frame timestamp analysis, which this inspector does not perform.

Because Matroska does not store one. Per-track bitrates are an MP4 and MOV convention; MKV and WebM record the streams and leave the arithmetic to whoever needs it. The tool leaves that gap empty rather than filling it with a guess, and pressing Count measures the real figure by totalling the bytes the picture actually occupies.

Yes. MP3, M4A, AAC, WAV, FLAC, OGG and Opus files are read the same way, and report their bitrate, sample rate, channel layout, duration and tags. Album artwork is identified as artwork rather than counted as a video track, which is the usual reason another tool insists an audio file contains video.

Length times the average frame rate is only an estimate, because duration and rate fields can be rounded. Pressing Count walks every packet without decoding any of them and returns the actual total. It also compares that total with the header’s estimate, which helps explain unusual timing information without pretending to diagnose it from one number.

Bit depth is how finely each colour value is recorded, and chroma subsampling is how much colour detail is kept next to the brightness. Ordinary video is 8-bit 4:2:0, which everything decodes. Professional cameras and editing formats produce 10-bit and 4:2:2, which carry more information and are also what browsers, phones, and older editing software are most likely to reject. Both are read from the pixel format and reported here.

The whole file is read into the tab's memory before it can be examined, and WebAssembly is 32-bit, so somewhere around a quarter of a gigabyte is the practical ceiling. Reading the header itself is quick at any size within that limit; the counting pass takes time proportional to the length of the file, since it walks every packet, though it decodes none of them.