MP4 Autoplay und Loop im HTML5-Video: Was wirklich funktioniert

Die Frage „warum spielt mein Video nicht von selbst?“ gehört zu den nervigsten Web-Dev-Themen der letzten zehn Jahre. Browser-Hersteller haben in mehreren Wellen das Autoplay-Verhalten verschärft, weil zu viele Werbevideos zu laut zu früh starteten. Heute gilt eine relativ klare Regel: stumme Videos dürfen, Videos mit Ton dürfen nur nach User-Interaktion. Plus ein paar plattform-spezifische Quirks.

Das funktionierende Vier-Attribute-Pattern

Das ist der HTML-Code, der ein GIF-ähnliches Loop-Verhalten in einem <video>-Tag erzeugt und in allen modernen Browsern startet:

Lässt man muted weg, blocken alle modernen Browser den Autoplay-Start (Chrome 66+, Firefox seit Quantum, Safari 11+). Lässt man playsinline weg, springt iOS Safari beim Play in den Vollbild-Modus, was im Feed-Layout unbrauchbar ist.

Browser-Support im Detail

Browser	autoplay+muted	playsinline nötig	MP4 (H.264)	WebM (VP9)
Chrome 66+	Ja	Nein	Ja	Ja
Firefox 78+	Ja	Nein	Ja	Ja
Safari 11+ (macOS)	Ja	Nein	Ja	Teilweise
Safari 12.2+ (iOS)	Ja	Ja, Pflicht	Ja	Nein (vor 14.1)
Edge (Chromium)	Ja	Nein	Ja	Ja
Samsung Internet	Ja	Ja, empfohlen	Ja	Ja

Apple hat 2017 mit iOS 10 die strikte Autoplay-Sperre gelockert, aber an die Bedingung muted + playsinline geknüpft. Ohne playsinline würde der Player auf iPhone und iPad sofort in den Vollbild-Modus springen, weil iOS Videos historisch im nativen Player abspielen wollte.

Die iOS-Quirks

iOS Safari hat über die Versionen mehrere stille Änderungen am Video-Verhalten vorgenommen, die immer mal wieder Bugs verursachen:

1. iOS 10 (2016): Erste Lockerung der Autoplay-Sperre für stumme Videos mit playsinline.
2. iOS 12 (2018): Low-Power-Modus erlaubt nur noch User-initiierte Wiedergabe, auch bei stummen Videos. Workaround: play()-Call im Click-Handler.
3. iOS 14.1 (2020): Endlich WebM mit VP9 unterstützt.
4. iOS 15 (2021): Datensparmodus blockt Auto-Preload, Videos starten erst beim Tippen.
5. iOS 17 (2023): WebM-VP9 vollständig stabil.

MP4 vs. WebM als Default

H.264 in MP4 läuft in jedem Browser seit 2010 und ist die sichere Wahl. WebM mit VP9 kommt von Google, ist royalty-frei (kein patent-related licensing) und liefert bei gleicher Qualität rund 30 Prozent kleinere Dateien als H.264. Der Haken: Safari hat WebM lange Zeit gar nicht unterstützt, erst seit iOS 14.1 / macOS Big Sur ist die Wiedergabe verlässlich.

Best Practice: beide ausliefern, der Browser pickt sich den ersten unterstützten Codec.

Browsers can prevent autoplay video from starting if it would play audio, or if the page is not visible. Always use the muted attribute for autoplay video, and use playsinline on iOS Safari.

Loop-Verhalten: GIF vs. MP4

GIF speichert die Loop-Information in einem Application Extension Block mit der Signatur „NETSCAPE2.0“. Default ist endlos, alternativ kann eine genaue Anzahl Loops angegeben werden. Diese Funktion stammt aus den 1990ern, als Netscape Navigator (RIP) sie eingeführt hat.

MP4 kennt nichts Vergleichbares im Container, der Loop wird vom Player über das HTML-loop-Attribut realisiert. Manche Mobile-Player (z.B. die WhatsApp-In-App-Wiedergabe oder Twitter-Mobile) loopen MP4s automatisch, andere zeigen am Ende einen Replay-Button.

Wer ein MP4 als „Endlos-Animation in einer Webseite“ einbettet, braucht das loop-Attribut. Wer ein MP4 als File-Download verteilt, hat keine Garantie, wie der jeweilige Player damit umgeht. Für maximale Plattform-Kontrolle (Webseite, App), MP4 mit <video loop>. Für Verbreitung auf Plattformen, die kein zuverlässiges Loop garantieren, das MP4 mit ffmpeg -stream_loop 4 -i in.mp4 direkt mehrfach hintereinander schreiben.

Fallback-Patterns

Wer GIF-Replacement baut, sollte für extreme Edge-Cases (sehr alte Android-WebViews, Datensparmodus) ein statisches Poster-Bild als Fallback ausliefern:

Praxis-Empfehlungen

1. Beim Konvertieren von GIF zu MP4 immer auch ein Poster-Bild aus dem ersten Frame ziehen (ffmpeg -i in.mp4 -vframes 1 frame.jpg).
2. Für Cinemagraphs und Hintergrund-Loops <video> statt <img> einsetzen, spart 80 bis 95 Prozent Bandbreite.
3. Wenn die Seite in iOS WebView (Apps mit eingebettetem Browser) läuft, das play()-Promise im Click-Handler abfangen, weil Autoplay dort regelmäßig gesperrt wird.
4. CDN-Header Cache-Control: public, max-age=31536000, immutable für statische MP4-Loops setzen, das spart Wiederholt-Loads.

Mit dem Vier-Attribute-Pattern und einem MP4 + WebM Fallback ist man für 99 Prozent der Browser-Situationen abgedeckt. Die restlichen Prozent sind Apple-spezifische Low-Power-Quirks, die mit einem Click-Handler abgefangen werden.