Two .mp4 files, one processes fine and the other throws "unsupported" the moment it's imported. First time it looks like a tool bug; it's actually treating "container" and "codec" as the same thing. They're separate layers, and the extension only names the outer one.
.mp4, .mov, .webm, .mkv name the container — the box holding the audio and video tracks. What codec the actual picture data inside is compressed with is a different matter. The same MP4 box can hold H.264, or H.265, or AV1; a WebM can hold VP9 or AV1. The suffix tells you the box shape, not whether what's inside is something the current environment can open.
| Container (suffix) | Possible video codecs inside |
|---|---|
| .mp4 / .mov | H.264, H.265 (HEVC), AV1… |
| .webm | VP8, VP9, AV1 |
| .mkv | almost any combination |
So "can it be processed" was never a question about the suffix — it's about the real codec of the track inside, and whether the current browser can decode that codec and encode the one you want out. Browsers decoding H.264 is common; H.265, not necessarily; encoding H.264, but maybe not AV1. These are independent, and if any one fails, that ".mp4" simply can't be processed on that device.
ImgIng's approach in video compression is to not trust the suffix: on import it checks the real audio/video track codec inside the container. It says so directly — MP4, MOV, WebM, MKV are just containers, the inside may be a codec the current browser doesn't support. That step isn't excess caution, it avoids "the UI says imported, then it fails halfway through encoding". Find out what's inside and whether the device can take it, then decide whether to let you process it.
AV1 is the textbook case. High compression, but heavy to encode and narrowly supported, so ImgIng only opens it after a runtime capability check passes — not guessing "this browser probably supports it" from the UA, but actually probing whether the current environment can encode AV1, and only then offering it. That's a different world from "the browser claims to support a format and then can't produce it": one is a UI promise that fails at execution, the other confirms before executing.
My boundary here: the video codec itself goes through the browser's WebCodecs, not an engine I built; my layer handles the import-time track check and capability-probe scheduling. From there the judgement is: when "same MP4, one works one doesn't" happens, don't suspect the tool — go look at the real video codec in the two files. Usually one is H.264 and the other H.265 or something else, and the device only decodes the former.
So, one line: the suffix is the box, the codec is the contents, and processability is decided by contents and device together. To tell whether a video can be processed by some tool, don't look at whether it's called .mp4 or .webm, look at the real track codec inside, then whether this device can decode and encode it. One more hard condition: WebCodecs local transcoding needs an HTTPS or localhost secure context — without it, none of the above even applies. Tool is ImgIng (imging.ai).
Top comments (0)