Videoblog? Kein Problem!

Michael Sebel

Im Frühling 2017 erreichte uns eine Anfrage zur Entwicklung eines Videoblog. Das klang für uns im ersten Moment nicht schwierig. Wie so oft, vermuteten wir, dass es um einen Blog geht, in welchem sich einfach Youtube- oder Vimeo-Videos einbinden lassen. Mit WordPress ist das kein Problem. Doch so simpel wie erwartet, war es dann doch nicht: Die Website soll in erster Linie ein Video streamen und dabei je nach Szene und Zeitpunkt den passenden Blog-Beitrag als Overlay anzeigen. So kann man jeweils detailliertere Informationen zum Szenen-Inhalt nachlesen.

Ein Fall für HTML5 Video

Wenn es um Videostreaming geht, welches auf allen Geräten in annehmbarer Qualität und Abhängigkeit der Datenverbindung gut funktioniert, vertrauen wir Youtube oder Vimeo. Aufgrund der Zeitgesteuerten Overlays, welche in Youtube nicht im gewünschten Stil einbindbar waren, fiel diese Option erstmal weg. Rückwirkend betrachtet hätten wir sicher etwas mehr Zeit in Abklärungen zur Youtube API stecken müssen – Denn HTML5 Video ist dem Job in vielerlei Hinsicht nicht gewachsen. Wie sich leider erst deutlich später rausstellt.

In den Vorabklärungen haben wir nur die eingebetteten Youtube IFrames in Betracht gezogen, welche viele Limitationen haben. Gerade deshalb gingen wir sehr früh in Richtung <video> Tag, auch weil wir dachten, dass es sich dabei um ein mittlerweile gut unterstütztes und mächtiges Element handelt. Abgesehen von der Zeitsteuerung, welche auch beim vor-, rückspulen und einer Pause korrekt funktionieren muss, gab es weitere gute Gründe, die Youtube-Variante vorschnell zu verwerfen.

Herausforderungen mit HTML5 Video

Man kann sagen, dass wir einiges über HTML5 Video gelernt haben. Wir wissen nun, wozu es bestens geeignet ist und wozu nicht. Und wir wissen, dass leider viele Dinge schlecht bis gar nicht unterstützt werden, obwohl es gemäss Tutorials und Dokumentationen erstmal so aussieht. An vielen Tutorials steht am Ende: Sorry, das klingt alles gut, aber wurde dann nie richtig in allen Browsern implementiert. Oder schlimmer: Sorry, das wurde schon 2014 wieder aus der Spezifikation entfernt. Manchmal steht auch kein solcher Hinweis, obwohl eine der beiden Aussagen zutreffen würde.

Automatisches abspielen

Liest man einen Blog-Beitrag gibt es am Ende einen Link zurück zum Video. Dieses soll nicht von vorne, sondern am letzten Punkt weiter gehen. Dazu muss schon nur der „streamende“ Webserver gewisse Protokolle unterstützen, die nicht selbstverständlich sind. Weiterhin sollte das Video automatisch abspielen. Doch das geht auf jeglichen Mobile Devices nicht: Die Video-API hat dort die Einschränkung, dass das Video nur mit einer Nutzerinteraktion gestartet werden kann. Gleichzeitig kann die API nicht feststellen, dass das „autoplay“ nicht klappte – Dies muss man als Entwickler selbst rausfinden und ein entsprechendes Play-Overlay zeigen. So müssen Nutzer am Smartphone nach dem Rücksprung eben doch nochmal „play“ drücken. Ausnahme: Ist das Video stummgeschaltet, funktioniert das auch auf Mobilegeräten. Deshalb sind in einigen Video-Portalen alle automatisch abgespielten Videos erstmal stumm. Das war in unserer Anwendung jedoch keine Option.

Untertitel-Formate

Dass das Video Untertitel zeigen soll, war von Anfang an klar. Allerdings unterstützt HTML5 Video das bekannte .srt Format nicht (Obwohl auch das einige Quellen behaupten). Gut, gibt es einen Konverter in das weniger bekannte .vtt Format. So konnte die Video-Agentur dennoch die passenden Files liefern. Obacht: Gemäss vielen Dokumentationen kann man die Schrift und Farbe mittels CSS Anweisungen im .vtt File steuern. Kurz gesagt: Geht nicht. Nur ein Browser unterstützte dies – bei allen anderen crashte das gesamte Video. Doch dazu mehr im nächsten Punkt.

Schlimmer noch: Die Darstellung der Untertitel

Die Untertitel mittels CSS stylen? Auch da gibt es viele Ressourcen, welche zeigen wie es geht, jedoch dann auch schreiben „ja, äh, das geht dann nur in Webkit (Chrome, Safari), gäll“. Unschön ist auch, dass das standardmässige Styling zwar perfekt lesbar ist, aber für Anwender ungewohnt: Schwarze Balken mit weisser Schrift. Auch die Schriftart lässt sich nicht kontrollieren. Hierfür gibt es allerdings mächtige Frameworks, die den <video> Tag mittels Javascript erweitern und dann auch das Styling von Untertiteln ermöglichen.

Auflösung der Videodateien

Gemäss einigen Ressourcen gab es früher mal eine Art „Media-Query-Attribut“ für Video Sources, mit welchen man steuern sollte, dass ein kleiner Screen ein Video in geringerer Auslösung kriegt. Das wurde jedoch von der W3C verworfen. Auch das haben wir in den Vorabklärungen nicht erkannt – Im Gegenteil: Viele Tutorials versprechen den Himmel auf Erden. Die Enttäuschung war gross. Tatsächlich müsste man für so einen Fall mehrere <video> Tags ins Dokument nehmen und diese mittels herkömmlichen CSS Media-Queries steuern. Das geht auch, bringt aber neue Probleme mit sich – Da die Videos unabhängig voneinander laufen, müsste man beim drehen des Screens auf ein anderes Video wechseln, dieses zum gleichen Punkt vorspulen, die Zeitsteuerung informieren und das Video automatisch weiter- bzw. abspielen. Doch siehe Punkt 1: Automatisches Abspielen funktioniert ja nicht. Egal wie man’s probiert, da kommt man auf keinen grünen Zweig.

Erkennen einer schlechten Verbindung

Verwendet man klassische Video Dateien wie mp4 und webm, redet man eigentlich nicht von Streaming sondern von einem simplen „progressiven Download“ der Video-Datei. Nur mit echtem Streaming, etwa mit HTTP-Live-Streaming (HLS) ist es möglich, einer schlechten Verbindung auch runtergerechneten Content zu liefern, damit das Video weniger schnell ins stocken kommt. Dieser Gedanke kam ebenfalls zu spät – Wir hatten bereits alles auf mp4 und webm optimiert und keine Infrastruktur mit der wir HLS Streams abspielen bzw. generieren können. So mussten wir einen Mittelwert an Auflösung, Bildern pro Sekunde und Dateigrösse finden der für möglichste viele Anwendungsfälle funktioniert: Gute Qualität, aber möglichst wenig ruckeln.

Apropos mp4 und webm

Unterstützt man im <video> Tag diese beiden Formate kann man sogut wie jedes moderne Gerät abdecken. Weitere Formate machen wenig Sinn, ausser man muss bewusst sehr alte (mobile) Browser unterstützen. Doch Vorsicht: Aus einem vollaufgelösten mp4 „ein paar Test-Versionen“ eines webm zu rendern nimmt auf einem durchschnitts Laptop 48-72h in Anspruch. Da war ich froh, aus einem früheren Projekt den „Amazon Elastic Transcoder“ zu kennen. Dieser Dienst erlaubt es, genau dieses Rendering durch die Cloud in wenigen Minuten zu erledigen. Da wir die Video-Dateien am Ende auch via Amazons CloudFront eingebunden haben, bot sich das doppelt an – Die gerenderten Videos mussten wir so nicht mehr irgendwohin verschieben, da die Amazon Dienste alle gut miteinander verzahnt sind.

Last but not least

Ein letzter Punkt ist das „poster“ Attribut. Solange ein Video nicht läuft kann man mittels dem Attribut „poster“ ein Standbild angeben, damit nicht nur eine schwarze Fläche erscheint. Das hat den Nachteil, dass es immer exakt gleich gross wie das Video Objekt ist. Die Anforderung besagt allerdings, dass das Video auf grossen Bildschirmen nicht über die volle Breite geht, während das Standbild dies tun muss. So muss man sich mit einem separaten Bild, welches über das Video gelegt wird behelfen und beim Klick- oder Tap-Event auf das Bild reagieren und per Video-API das Video starten. Auch wenn „Pause“ gedrückt wird, sollte das Video nicht einfach anhalten, sondern wieder das Standbild erscheinen mit einem Hinweis, dass man durch erneute Berührung weiterschauen kann. Letzteres Konzept wurde aber kurz vor Projektabschluss wieder verworfen, war aber technisch machbar und umgesetzt.

Was haben wir gelernt?

In erster Linie ist es wichtig, bei Vorabklärungen genau hinzuschauen – Das tun wir immer. Doch als es erstmals um ein Video-Projekt ging, waren wir übermotiviert. Und der <video> Tag existiert seit einigen Jahren. Wir haben gar nie den Gedanken gefasst, dass der „so wenig kann“. Auf die ersten Google-Searches sah auch alles sehr positiv aus. HTML5 Video scheint mächtig zu sein. Doch vieles, was man an Dokumentationen findet wurde verworfen oder in den Browsern gar nie implementiert.

Ganz klar werden wir beim nächsten Projekt ein Framework wie video.js anwenden. Dieses erweitert den HTML5 <video> Tag um sehr viele wichtige Funktionen von denen wir erwartet hätten, dass sie bereits im HTML5 Standard implementiert sind.

Ausserdem hätten wir aufgrund der verschiedenen Anforderungen Youtube oder Vimeo nicht kategorisch ausschliessen müssen, da beide Portale auch eine Javascript API für native Videoeinbindung zur Verfügung stellen. Rückwirkend betrachtet wäre die Umsetzung damit teilweise möglich gewesen und viele Probleme, vor allem mit Videoformaten und Streaming hätten wir so an die Profis von Youtube auslagern können.

Beim nächsten derartigen Projekt werden wir ausserdem HLS Streaming in betracht ziehen, da es als Quelle eines Video-Tag vorallem in Mobile Browsern, wo das Problem mit der Verbindungsqualität am akutesten ist, unterstützt wird. Desktop-Browser unterstützen das Format noch nicht innerhalb des <video> Tag, dort kann man aber als Fallback mit mp4 und webm arbeiten. Hier fehlte es uns vorallem an der Erfahrung, wie solche Streaming Daten bereitgestellt werden müssen – und nicht zuletzt war der Termindruck, das Projekt fertigzustellen sehr hoch. Auch der Produzent der Videos konnte uns in diesem „Neuland“ auf die Schnelle nicht weiterhelfen, weswegen wir bei den klassischen Formaten mp4 und webm geblieben sind.

Wozu kann man HTML5 Video denn brauchen?

Für komplexe Videoanwendungen ist reines HTML5 Video nicht geeignet. Mit einem Framework wie video.js kann man aber viele Einschränkungen umgehen und mächtige, interaktive Anwendungen umsetzen. Eine andere Möglichkeit sind die APIs der grösseren Videoportale.

Sehr oft wird HTML5 Video als Alternative zum klassischen „Header Bild“ verwendet. In einer Endlosschlaufe und ohne Ton spielt es auf jedem Gerät wahlweise automatisch ab. So können lebendige Startseiten wie die der NZZ Mediengruppe ohne weiteres umgesetzt werden. Da die Videos in mp4/webm hier auch deutlich kürzer sind und nicht in hochauflösender Qualität abgespielt werden müssen, ergibt sich eine Dateigrösse die auch für jedes Gerät ruckelfrei funktioniert.

Das Resultat unserer Umsetzung lässt sich sehen.