Media File Info (duration, size, codec, bitrate)

Features

• Duration, file size and overall bitrate (bytes × 8 ÷ duration)
• Per-track codec: H.264 / H.265 / AV1 / VP9 / AAC / MP3 / Opus / FLAC …
• Stored size and display size listed separately, with the rotation angle
• Frame rate, sample rate, channel count and bit depth
• ⚠️ A 90° portrait video: the coded width and height are landscape, the player turns it
• ⚠️ An MP4 whose moov sits at the end of the file still reads fine
• ⚠️ Opus is always 48 kHz; the header input rate is not trusted
• Exports to JSON, ready for a script or a ticket
• Read-only: the file is not modified and nothing is uploaded

How to use

1. Drop a video or audio file onto the dashed box
2. The details appear below in monospace, copyable row by row
3. For a portrait video, check the Rotation and Display size rows
4. Switch the output to JSON and use Copy to feed a script

FAQ

Why do stored size and display size differ?

Because a portrait video is stored as a landscape frame. When you hold a phone upright, the sensor still records a landscape image, and the container adds a "rotate 90° clockwise" flag that a player reads to turn it the right way up. So the real pixels are 1920×1080 (stored size) while it is meant to be shown at 1080×1920 (display size). Many tools honour only the width and height and ignore the rotation flag, which is how footage ends up sideways or squashed in an editor or a converter — when these two numbers disagree, check whether the target tool understands rotation.

Why can this tool read an MP4 that another tool cannot?

Almost always the position of moov. An MP4 keeps its tracks and duration in the moov box, and that box may be placed at the start of the file (faststart, good for streaming) or at the end (write the data first, append the index — common in recording software). A tool that reads only the start of the file reports "no metadata" for the latter. This tool walks the entire file, so both layouts read correctly.

Why does Opus always show 48000 Hz?

Because the Opus format specifies a decode output of 48000 Hz. The header does carry an "input sample rate" field, but that only records the original recording rate for reference; it may be 0 or anything else, while the actual decode rate is always 48 kHz. Reporting the header value would throw off the duration as well.

How accurate is an "estimated" duration?

Right order of magnitude, but the exact figure varies. For a variable-bitrate MP3, a Xing / Info header records the total frame count and the duration is exact; without that header the tool can only estimate from "audio bytes × 8 ÷ average bitrate", and an average bitrate does not hold for music that swells and fades. So it says "estimated" in that case rather than passing a guess off as precise. For an exact figure, a decoder has to actually run through the file.