Das Video wird dekodiert, in das gewählte Format neu kodiert und in den passenden Container geschrieben. MP4 mit H.264 spielt überall und ist die sichere Wahl für Uploads. WebM mit VP9 ist bei gleicher Qualität kleiner. Nichts wird hochgeladen — die Arbeit geschieht auf Ihrem eigenen Gerät, über denselben Hardware-Encoder, mit dem es aufnimmt.
Jedes Format wird an Ihrem Browser getestet, bevor es angeboten wird, und was er nicht schreiben kann, erscheint als nicht verfügbar, statt angeboten zu werden und am Ende einer langen Kodierung zu scheitern. Diese Prüfung zählt hier mehr als sonst irgendwo, denn Codec-Unterstützung hängt von Browser, Betriebssystem und mitunter den Grafiktreibern ab — eine feste Liste wäre für einen guten Teil der Besucher falsch.
Ein Format wählen
-
MP4 mit H.264 für alles, was Sie jemandem schicken:
Es spielt auf jedem Gerät, in jedem Browser und auf jeder Plattform, und Upload-Formulare erwarten es. Wenn es keinen bestimmten Grund für etwas anderes gibt, ist das die Antwort.
-
WebM mit VP9 fürs Web und für Ton unter Firefox oder Linux:
Es ist bei gleicher Qualität merklich kleiner. Es ist unter Firefox und Desktop-Linux außerdem der einzige Weg zu einer Datei mit Ton, denn dort lässt sich das von MP4 verlangte AAC nicht kodieren — WebM nutzt stattdessen Opus, was dort geht.
-
Umwandeln stellt keine Qualität wieder her:
Jeder Durchgang dekodiert das Vorhandene und kodiert es neu, Artefakte in der Datei bleiben also erhalten statt zu verschwinden. Wandeln Sie einmal um, vom besten Ausgangsmaterial, das Sie haben.
-
Manche Formate lassen sich gar nicht lesen:
MKV, AVI und ProRes öffnen sich nicht, weil Browser sie nicht dekodieren können. Das ist eine Grenze der Eingabe, nicht der Ausgabe, und sie gilt für jedes Videowerkzeug hier.
Why a format can appear greyed out
Rather than offering a fixed list of outputs, the [msm_tool slug="video-converter"] tests each format against the browser it is running in before offering it, because codec support depends on the browser, the operating system and sometimes the graphics drivers underneath both. A format the browser cannot actually write is shown as unavailable up front, rather than being offered and failing only after a long encode has already run.
MP4 or WebM, and when each is the right call
MP4 with H.264 is the format every device, browser and upload form expects, which makes it the default answer whenever there is no specific reason to choose otherwise. WebM with VP9 produces a meaningfully smaller file at the same visual quality, worth it for anything destined for a web page rather than an upload form. WebM carries a second advantage that has nothing to do with size: its audio codec is Opus rather than AAC, and Opus is the only route to a video with sound on Firefox or on desktop Linux, neither of which can encode AAC at all.
Converting cannot undo a previous encode
Every pass here decodes whatever is actually in the file and encodes it again from scratch, so any artefacts already baked into the source are preserved rather than cleaned up along the way. Converting is worth doing once, from the best copy available — running a file through repeated conversions adds a fresh generation of encoding loss each time rather than improving anything.
What it cannot even open
MKV, AVI and ProRes files will not load at all, and that has nothing to do with this particular tool: browsers cannot decode those containers, so nothing running in one can read them in the first place. Every video tool on the site shares that same limit on what can come in, regardless of what it is asked to do with the file afterwards.
Why the result can end up larger than the original
A file that was already efficiently encoded has little redundancy left to remove, and re-encoding it spends bits faithfully reproducing the artefacts of that earlier pass rather than shrinking anything. That shows up most with a source that has already been compressed for the web once — converting it again is not guaranteed to make it smaller, and sometimes does the opposite.
When converting is pure loss
If the file already plays where it is headed — the platform accepts the current format, the sound already works on the browser in question — converting it adds a generation of encoding loss for no benefit at all. The reason to convert is a real constraint: a format the destination refuses, or audio that will not encode in the format currently in hand. Absent one of those, the existing file is already the better one to send.