HTML5: das HTML5 Video Tag, Browser Support, das Konvertieren von Videos in ein HTML5-gängiges Format.
HTML5 versus Flash
War bis vor kurzem Flash das bestimmende Format für Videos im Internet, so drängt sich nun HTML5, das als Initiative der Browserhersteller Mozilla (Firefox) und Opera begann, in den Vordergrund. Gemeinsam gründeten die Mozilla Foundation, Opera und Apple Safari am 4.Juni 2004 die WHATWG (Web Hypertext Applications Technology Working Group), die von nun an mit der Ausarbeitung des neuen HTML 5 Standards betraut war. Etwas später stieß auch Google hinzu und steuerte den neuen patentfreien Video Codec VP8 bei. So ist es mittlerweile selbstverständlich, daß auch Google Chrome und der neue Internet Explorer 10 HTML5 Video makellos unterstützen. HTML5 Video ist also das Format der Zukunft. Nicht nur, daß die Videoplattform Youtube unlängst auf HTML5-Video umgestellt hat, nein sondern auch, daß HTML5-Video das einzige Format ist, das von mobilen Endgeräten und Smartphones unterstützt wird.
Adobe Flash wird ab 2020 nicht mehr unterstützt
Apple läßt Adobe Flash auf iOS-Geräten nicht mehr zu.
neuere Android Versionen untertstützen Adobe Falsh Video nicht mehr offiziell.
seit Version 11.2 ist die Unterstützung des Flash Players für Linux, das sich neuerdings auch als Spielplattform beliebt macht, eingestellt worden.
auf alternativen Betriebssystemen wie FreeBSD, der eComstation (OS/2), Solaris, Syllable, QNX und Haiku OS hat man überhaupt keine Chance Flash-Videos zum Laufen zu bringen, weil das proprietäre Flash-Format entweder nie auf diese Systeme portiert worden ist oder es von Seiten von Adobe schon lange keine funktionierenden Upgrades mehr gibt.
Die HTML5 - Technologie kommt aus dem Open Source Bereich und bringt dabei gleich mehrere Vorteile mit:
HTML5 ist in den Browser integriert und muß nicht erst eigenhändig vom Benutzer nachinstalliert werden.
das propietäre Adobe Flash muß aus Sicherheitsgründen auf vielen Browsern ausgeschalten bleiben.
für Entwickler gestaltet sich die Kommunikation zwischen Plugins wie Flash und dem Browser leider oft schwierig.
das Closed-Source Flash Plugin macht die Fehlersuche bei Abstürzen schwer oder gar unmöglich.
Flash ist nicht gleich Flash: die vielen unterschiedlichen in Umlauf befindlichen Flash Versionen machen den Benutzern das Leben schwer, zumal neu konvertierte Videos auf älteren Flash Versionen überhaupt nicht laufen. Oft ist zwar Flash installiert, was den Webadmin in trügerischer Sicherheit wiegt, das gewünschte Video kann aber erst nicht abgespielt werden.
Daß Adobe Flash Videos noch immer so weit verbreitet sind liegt letztlich auch an der Trägheit vieler Webseitenbetreiber, die schon in Flash investiert haben, und einen Umstieg auf HTML5 scheuen. Daß der Internet Explorer 8 auf einigen Rechnern immer noch im Einsatz ist und manchmal als Grund für die Beibehaltung von Adobe Flash angeführt wird stimmt zwar, doch ist ein Upgrade des Internet Explorers auf die Version 10 kaum schwerer durchzuführen als das regelmäßige Upgraden des Adobe Flash Players. Letztlich werde ich noch zwei Workarounds bereitstellen, mit denen auf einfache Weise die Funktionsfähigkeit unter zwei der Technologien HTML5 und Flash bzw. Java auf dem veralteten IE8 sichergestellt werden kann.
In Wirklichkeit geht es nun bei der Ablöse von Adobe Flash durch HTML5 nicht nur um Videos sondern um eine ganze Reihe anderer Technologien:
Zugriff auf Webcam und Mikrofone: auch hier liegt die Zukunft bei WebRTC und HTML5 Javascript APIs (MediaStream aka getUserMedia)
Datenbankzugriff: Indexed DB: Verbesserung gegnüber Flash (nicht auf allen Browsern verfügbar)
viele weitere interessante Features, die mit HTML5 kommen: Web Workers (Threads), Canvas (Vektor Graphik), Geolocation, Microdata, Websockets und bessere, intelligentere Formulare.
Inzwischen gibt es mit WebRTC alles was man zur Echtzeitkommunikation braucht: MediaStream (Webcam und Mikrofonzugriff), RTCPeerConnection (Audio und Videoströme kommunizieren; mit Möglichkeit zu Verschlüsselung und Bandbreitenkontrolle), RTCDataChannel (Peer-to-peer Kommunikation mit generischen Daten). Damit lassen sich nun auch Dinge wie IP-Telefonie oder Videokonferenzen mittels Javascript und dem Browser implementieren.
von HTML5 untertstützte Videoformate
Bevor wir in medias res gehen können noch einen kleinen Überblick über die unter HTML5 üblichen Kodierungsverfahren und Containerformate. Damit Audio- und Videodaten gemeinsam als vertonte Filmsequenz gespeichert werden können braucht es ein Containerformat. Das ist wünschenswert, soll es doch zumindest Audiospuren in mehreren Sprachen geben können (abgesehen von Untertexten (Übersetzung) und Einzelbildern in mp4, das als Container für ganze application/mp4-s dienen kann.). Der Codec der Audio und Videodaten bestimmt hingegen das Kodierungsverfahren, dessen Parameterisierung und damit die Effizienz der Datenspeicherung.
Der unter MPEG-4 gewöhnlich eingesetzte Video Codec H.264 beispielsweise ist bis ins jahr 2028 patentgeschützt und hängt wie ein Damoklesschwert über den Open Source Entwicklern, können sie doch jederzeit dazu aufgefordert werden Patentabgaben zu entrichten, was sich bei gratis Software wohl nur mit einer Verbannung von H.264 lösen ließe (sofern es für diese keine Ausnahmeregelung oder die Möglichkeit einer prozentuellen Abgabe geben würde).
So gesehen wäre dem freien VP8 Video Codec, der zusammen mit dem Vorbis Audio Codec im Matroska Containerformat als video/webm eingesetzt wird, der Vorzug zu geben. Durch den Erwerb von On2 Technologies, das zuvor mit der Xiph.Org Foundation das Containerformat ogg entwickelt hatte, hat Google diese Codecs frei zur Verfügung gestellt. Wäre da nicht der Safari Browser der bis jetzt nur MPEG-4 unterstützt und die vielen mobilen Endgeräte von Apple wie iPod, iPhone und iPad, die für MP4 eine Hardwarebeschleunigung eingebaut haben. Ich werde später zeigen wie man Videos in beiden Formaten bereitstellt und sich der Browser dann das jeweils passende aussucht.
Fassen wir also zusammen: Auch wenn sich Codecs und Containerformate quasi beliebig kombinieren ließen sind unter HTML5 folgende drei Kombinationen gebräuchlich:
Als Dateiendungen kommen hier .webm (video/webm), .mp4, .m4a, .m4r, .m4b (video/mp4, audio/mp4, application/mp4; MPEG-4: von Apple auch für Audio und Klingeltöne:ring und Hörbücher verwendet), .ogg, .oga und .ogv für Audio respektive Video (video/ogg, audio/ogg) zum Einsatz. Während sich das video/webm-Format durchaus mit video/mp4 messen kann ist der VP3.2 Codec leider veraltet und kann daher bei selber Bitrate nicht die gleiche Qualität bieten.
Browserunterstützung: Safari: nur MPEG-4, Firefox erst ab Version 20 auch H.264, IE9: VP8 ist nachinstallierbar, H2.64: O.K., Opera: WebM, Konqueror: MPEG-4
Datenraten für Videos im Web
Letztendlich, nachdem wir die Frage nach dem Format geklärt haben, bleibt noch die Frage nach den zu offerierenden Bitraten. Schauen wir uns also die Geschwindigkeiten verschiedener Internetverbindungen an:
Modem: 54 - 64 kbps
ISDN: 128 kbps
UMTS: ~200, bis zu 384 kbps
DSL, einfach: 200 kbps - 600 kbps
superschnelles DSL: 8 Mbit - 20 Mbit (bisher nur in einigen Städten)
Video-DVD: 6 Mbit
Während man mit 32 kbps bis 64 kbps gerade mal einen Audio-Mono Strom enkodieren kann sind mit 150 kbps - 600 kbps schon sinnvolle Videoübertragungen möglich. DVD-Qualität gibt es mit 700 kbit/s zu haben (2 Stunden Video auf 4,5GB). HDTV braucht umgefähr 7 Mbit.
Sägezahnmuster das durch die TCP-Überlastkontrolle zustandekommt.
Zu beachten ist auch, daß aufgrund der TCP-Überlastkontrolle maximal die Hälfte der von der jeweiligen Internetverbindung zur Verfügung gestellten Bandbreite genutzt werden kann. Das Additive-Increase-Multiplicative-Decrease (additive Erhöhung, multiplikative Rücknahme) erzeugt ein sogenanntes Sägezahnmuster (siehe Abbildung). Jedes mal wenn Pakete verloren gehen, muß nämlich die Netzlast reduziert werden um einen Stau zu vermeiden. Schaut man sich die Kurve an, so sieht man, daß sich nur etwa die Hälfte des Platzes unter dem Bereich der Kurve befindet.
Durch die Nutzung von HTTP ist man bei HTML5-Video auf TCP angewiesen (HTTP ist ein TCP-basiertes Protokoll). Grundsätzlich wäre für die multimediale Datenübertragung UDP zu bevorzugen. Mit UDP werden verlorene Pakete nicht automatisch erneut übertragen, sodaß zu spät gekommene Pakete, welche erst nach dem Wiedergabezeitpunkt ankommen, nicht erneut übertragen werden müssen und so den nachkommenden Verkehr nicht mehr aufhalten. Mit TCP kann es hingegen passieren, daß die Wiedergabe abreißt. Richtig wäre wenn in einem solchen Fall der Empfangspuffer erweitert würde und das Abspielen dort wieder anfangt, wo es vorher aufgehört hat, doch leider implementieren dies die meisten bekannten Browser nicht. So geht die Zeit, in der der Empfang abreißt wie bei UDP für das Video verloren. Die Round-Trip-Time (Zeit für das Hin- und Zurückschicken eines Paketes) kann bei GPRS bis zu einer Sekunde dauern, sodaß ein Vorladen des Videos von mehreren Sekunden bei TCP notwendig ist.
Die Nutzung von HTTP/TCP hat aber auch Vorteile. So geht der HTTP-Verkehr von TCP auf Port 80 durch jede Firewall und bestehende Web-Proxies können das Video cachen. Außerdem braucht man keinen dedizierten Medienserver; der Standard-Webserver stellt das Video zur Verfügung.
Wie hoch die Datenrate bei einer gewissen Auflösung und Framerate ist, hängt in der Praxis natürlich davon ab wie gut sich das Video komprimieren läßt, was bei langsamen Bewegungen eher der Fall ist, weil immer nur der Unterschied zum vorhergehenden Frame enkodiert werden muß (P-Frames). Legt man später bei der Kompression eine fixe Datenrate wie durch die Internetverbindung vorgegeben fest, wird eine schnellere Bewegung durch eine höhere Quantisierung, d.h. durch einen Verlust an Bildqualität ausgeglichen.
216x234
145 kbit/s
640x360
365 kbit/s
768x432
730 kbit/s - 1100 kbit/s
960x540
2000 kbit/s
1280x720
3000 kbit/s - 4500 kbit/s
1920x1080
6000 kbit/s - 7800 kbit/s
Es ist gut sich nach einer Tabelle wie der obigen für H.264 unter einer Aspect Ration von 16:9 zu richten, denn gibt man dem Enkodierer ffmpeg oder einem seiner Frontends (VLC, Firefogg) eine zu hohe Auflösung für die gewünschte Datenrate vor, so kann die Bitrate durch Quantisierung alleine nicht mehr ausreichend gesenkt werden und die tatsächlich angezeigte und ausgegebene Datenrate übersteigt die Vorgaben.
Für die Auflösung eines Videos nimmt man am besten durch 2, 4, 8, 16 oder 32 teilbare Dimensionierungen, da diese sich am Verlustfreisten skalieren lassen. Die vom menschlichen Auge maximal wahrnehmbare Framerate für flüssige Bewegungen sind 25fps; auch hier ist z.B. eine durch fünf teilbare Framerate wie 30fps vorteilhaft für die Konvertierung in 25fps. Eine höhere Framerate für Web-Videos ist schlichtweg eine Bandbreitenverschwendung.
auf gehts: Videos mit ffmpeg für HTML5 enkodieren
ffmpeg versteht fast alle gängigen Video und Audioformate und dessen Bibliothek libavcodec wird von vielen Frontends und Playern wie VLC, MPlayer, Xine und Firefogg genutzt. Auch der VP8 Codec wurde von ffmpeg neu implementiert anstatt Googles allfällig langsamere libvpx zu verwenden.
Vergewissern wir uns zuerst ob ffmpeg, die von uns gewünschten Audio und Video Codecs tatsächlich unterstützt (grep ist dabei ein Befehl für die Linux-Kommandozeile wohingegen ffmpeg auch unter Windows laufen sollte):
> ffmpeg -codecs | egrep "flac|vorbis|aac|h264|vp8|vp3"
DEA D aac Advanced Audio Coding
D A D aac_latm AAC LATM (Advanced Audio Codec LATM syntax)
DEA D flac FLAC (Free Lossless Audio Codec)
D V D h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
EA libfaac libfaac AAC (Advanced Audio Codec)
DEA D vorbis Vorbis
D VSD vp3 On2 VP3
D V D vp8 On2 VP8
> ffmpeg -formats | egrep "webm|mp4|ogg"
E mp4 MP4 format
DE ogg Ogg
E webm WebM file format
Das scheint zu passen.
Holen wir uns nun unser Quellvideo von unserer Kamera und inspizieren wir dessen Kodierung:
ffmpeg erkennt das Eingabeformat und wählt die von uns gewünschten Codecs je nach Ausgabedateiformat (Dateieendung). Das funktioniert bei der hier verwendeten ffmpeg Version 0.11.1 (ffmpeg -version: Sie können eine neuere selbst von git:// compilieren) für mp4 und ogg prima; bei webm scheint hingegen das Weglassen der Tonspur mit (-an: audio no) die einzige Ausflucht zu sein; doch weit gefehlt: mit den Parametern -strict -2 und -ac 2 für stereo Audio kann man diese Videos genauso konvertieren. Wenn man zum Flug des Reihers die Wellen noch gegen das Ufer schlagen hört gewinnt das ganze doch um einiges. Wie unschwer aus obigem Beispiel zu erkennen ist haben wir die Audiobitrate mit -ab und die Videobitrate mittels -vb für das auszugebende Video sowie die Framerate mit -r 25 Frames pro Sekunde angegeben. Man könnte auch alle drei Befehlszeilen in einen einzigen einzeiligen Aufruf kombinieren, wobei man dann ffmpeg -i Reiher.MOV nur ein mal ganz am Anfang angeben muß.
Wollen wir hingegen auf 200 kbit/s runterkommen müssen wir nun auch die Auflösung reduzieren, was mit dem -s 424x240 Parameter wie folgt gelingt:
Wenn man das Video schließlich noch mit der vollen Bitrate von 12720 kbit/s unter Beibehaltung der Originalqualität konvertiert, gibt es noch einmal einen nicht zu verachtenden Qualitätssprung der immer noch größer ausfällt wie der zwischen 200 kbit/s und 600 kbit/s; der Wegfall von Quantisierungsfehlern ergibt hier ein schärferes Bild, die Auflösung bleibt aber die gleiche.
Was kann man sonst noch alles mit ffmpeg machen? Man kann z.B. mit -nv nur die Audiospur extrahieren, obwohl entsprechende Youtube Videos meist nur von geringer Audioqualität sind.
Viel wichtiger ist für uns hier die Möglichkeit Einzelbilder zu extrahieren. Während das Video geladen wird oder falls der Browser das Video überhaupt nicht anzeigen kann soll zumindest ein Standbild her. Außerdem können auch gekonnt gewählte Einzelbilder Eindruck machen, sofern deren Qualität gut genug ist.
-ss gibt den Startpunkt -t 17s die Dauer des Videoframes an, aus dem Standbilder zu extrahieren sind (Die selben Parameter können übrigens auch für den Videoschnitt verwendet werden.). Mit -r 15 bekommen wir bei 30fps immerhin jedes zweite Frame als Bild; das mit %3d als 3 stellige Ziffernangabe (damit der Browser die Bilder richtig ordnet sollen sie mit führenden Nullen ausgegeben werden; sonst einfach %d verwenden). Jetzt können Einzelbilder je nach Gusto mit dem Browser der Wahl, unter KDE beispielsweise mit Dolphin angezeigt und frameweise "abgespielt" werden.
Zum Schluß noch ein wichtiger Hinweis für alle die ffmpeg in einem Batch-File oder einem Shell-Script einsetzen wollen: ffmpeg liest von stdin. Das kann zu Problemen führen wenn man ffmpeg in einer Schleife verwendet, die ebenfalls von stdin liest wie im folgenden Codebeispiel:
{ cat movies | while read num movie; do
…
{
echo;echo "*************** movie: $bild -> #$no .mp4 ***************" >&2;
ffmpeg -i "$movie" -vb 836k -ab 64k -r 25 -s 960x540 "$filename$no$vidspec.mp4"
} 0<&9
done
} 9<&0;
Hier wurde stdin, also fd#0 einfach temporär auf fd#9 (FileDescriptor/DateiDeskriptor) umgelegt, weil auch das 'read num movie' von stdin liest, damit jetzt ffmpeg nicht versehentlich Daten liest die für 'read num movie' bestimmt wären. Und zwar liest ffmpeg von stdin sobald dort Zeichen verfügbar sind, auch wenn es sie nicht als Benutzereingabe braucht.
Selbst wenn dieser "Fehler" von ffmpeg irgendwann behoben sein sollte, kann ffmpeg jederzeit den Benutzer aus irgendeinem Grund rückfragen wollen. Wer dies nicht will gibt ffmpeg einfach >/dev/null oder >NUL als Standardeingabe. Wie dem auch sei; eine saubere Skriptprogrammierung stellt immer sicher, daß stdin vor dem Aufruf komplizierterer Tools wie ffmpeg einen validen Dateideskriptor enthält.
komfortable Konvertierung mittels GUI
Für all jene, die sich die Arbeit mit der Kommandozeile nicht antun wollen gibt es auch komfortable GUI-Frontends zu ffmpeg und eigene Programme mit interessanten zusätzlichen Möglichkeiten.
Wer rundum sorglos kurze Videos für das Web konvertieren will, der ist bei dem Onlinekonverter von html5backgroundvideos genau richtig. Noch nie war es einfacher kurze Videos ins .ogg, .webm und .mp4 Format zu bringen. Die Konvertierung von Videos bis zu zwei Minuten ist gratis; die Tonspur kann auf Klick hin entfernt werden.
Der auf viele Plattformen konvertierte Player-Klasssiker VLC nutzt die libavcodec des ffmpeg-Projektes, bietet vordefinierte Profile zur Umwandlung und erlaubt sogar das Erstellen von Screencasts; das sind Aufzeichnungen der aktuellen Arbeit am Schirm.
Die Firefox-Erweiterung Firefogg ermöglicht neben dem lokalen Konvertieren auf dem Rechner Video-Uploads für Benutzer mittels Javascript Bibliothek, ein Konzept auf das Wikipedia setzt. Titel, Autor und Aufnahmedatum können eingestellt werden.
Schließlich gibt es noch das minimalistische Miro Video Converter Frontend für ffmpeg, das auch gleich die ffmpeg Kommandozeilen mitanzeigt.
Hintergrund: Videokompression, Aufbereitung zum Schneiden
Will man ein Video nach der Konvertierung etwa mit Kino oder einem der vielen anderen oss und non-oss Schnittprogrammen schneiden, so empfiehlt es sich bei der Konvertierung nur I-Frames auszugeben, da nur diese als Schnittpunkt taugen.
Was sind nun I-,P- und B-Frames? I-Frames kodieren immer ein ganzes Bild, P-Frames den Unterschied zum vorhergehenden und B-Frames sind gar Interpolationen zwischen einem vorhergehenden und einem nachfolgenden Frame. Übertragen werden diese nicht in der Präsentationsreihenfolge IbbbPbbbPbbbIbbbPbbb… sondern in der Dekodierungsreihenfolge IPPbbbbbbbbbIPPbbb…. Schnittpunkte können nur an I-Frames gesetzt werden.
MPEG Videos werden nach dem JPEG Verfahren komprimiert, wobei sich das Bild in kleine Quadrate einteilt, die gemäß grober und feiner Cosinusschwingungen enkodiert werden. Die Bilddetails und letztlich das Hintergrundrauschen werden durch die feineren Schwingungen enkodiert, welche für das Gesamtbild nicht so wichtig sind und daher durch das Quantisierungsverfahren; d.h. eine höhere bzw. gröbere Quantisierung herausgefiltert werden.
Schließen wir mit zwei neuen Kommandozeilenparametern für ffmpeg ab: -g 18 würde eine Group Of Pictures (ein I-Frame + zugehörige P&B-Frames) Größe von 18 erzeugen, was evtl. besser komprimiert als nur eine GOP-Größe von 12 (Standard). Für den Sonderfall, daß nur I-Frames erzeugt werden sollen (Videoschnitt) gibt es einen spezillen Parameter nämlich -intra.
na endlich: das HTML5 Video Tag
Hat man die Konvertierung seiner Videos in ein standardkonformes Format geschafft, ist das Einbinden mittels HTTML5-Tag kinderleicht.
<video controls preload=metadata width=848 height=480 poster='data/frame049.jpg'>
<source src='data/Reiher-424x240-200kb.mp4' type='video/mp4'>
<source src='data/Reiher-424x240-200kb.webm' type='video/webm'>
<source src='data/Reiher-424x240-200kb.ogg' type='video/ogg'>
<img src='...'> - Bitte Updaten sie ihren Browser; dieser ist zu alt um HTML5-Videos abspielen zu können.
</video>
Hier ist das video-Tag ganz so zu sehen wie wir es weiter unten unter Genuß des Ergebnisses eingebunden haben. With, Height und Poster Parameter kann man dabei je nach Wunsch auch weglassen. Width und Height haben wir nur dazu verwendet um im zweiten Beispiel die Größe des Videos automatisch zu skalieren. Poster dient zur Anzeige eines beliebigen Standbildes während das Video geladen wird und bis der Benutzer den Abspielknopf drückt. Ansonsten wird einfach das erste Frame im Video angezeigt. Controls schließlich ist dazu notwendig Steuerelemente wie Play/Pause, Lautstärke, Vollbild und zum Vor/Zurückspulen anzuzeigen.
In folgender Tabelle sind weitere Attributwerte des video-Tags zusammengefaßt:
preload=none
gar nichts vorladen
preload=metadata
Metadaten zum Video wie Dauer, Autor und Copyright laden. Spart Bandbreite aber lädt alles was so zu einem Impressum gehört (poster frame).
preload=auto
mit der vollständigen Übertragung des Videos beim Seitenaufruf beginnen. Üblicherweise nützlich wenn nur ein einziges Video auf der Seite zu sehen ist.
autoplay
Gleich mit dem Abspielen beginnen, sobald genügend Daten vorhanden sind. Sparsam einsetzen; kann sehr nervig sein wenn der Benutzer gleich mehrere Tabs zu Suchergebnissen öffnet, da dann auf jedem Tab gleich ein Video lostönt und -spielt, ohne daß es der Benutzer noch zu Gesicht bekommt.
loop
in einer Schleife dauernd wiederholen; gern in Kombination mit autoplay genutzt
Media Queries mit CSS3
Mit HTML5 ist es möglich dasselbe Video in mehreren Auflösungen anzubieten und dabei den Browser mittels CSS3 media query gleich die richtige Auflösung wählen zu lassen. Das ist insbesondere bei Videos für mobile Endgeräte interessant, da man hier Übertragungsbandbreite sparen und gleichzeitig Support für exotische Auflösungen wie 800x480 (Galaxy Spica II), 640x320, 640x200, 416x352, 208x176 bieten kann.
<video controls>
<source src='data/Reiher-848x480-600kb.webm' type='video/webm' media='screen and (min-width: 848px)'>
<source src='data/Reiher-424x240-200kb.webm' type='video/webm' media='screen'>
kein HTML5 support.
</video>
Leider gibt es keine CSS3-Media Query Selektoren für die Übertragungsbandbreite. Durch geschickte Wahl der Auflösungen kann man aber hier wieder Boden gutmachen; im Beispiel oben bieten wir absichtlich kein Video mit 600kb für 800x480 an, da dies die mobile Übertragungsbandbreite unserer Smartphones überstrapazieren könnte (da das Video nur kurz ist wäre eine 800x480 Auflösung trotzdem denkbar.
Vergleichen Sie selbst welche Konvertierungsbitrate bei ihrer Internetanbindung das beste Ergebnis liefert. Auf Erweiterungen wie CSS3-Mediaqueries oder Support für ältere nicht HTML5-taugliche Browser haben wir dabei bewußt verzichtet.
