Aus bestimmten Gründen musste ich in den vergangenen Tagen HLS Push für die Auslieferung bei Akamai implementieren und ich bin so genervt, dass ich darüber bloggen muss.

Was ist dieses HLS-Zeug?

Für die, die nicht wissen, was HLS ist: Dieses Format ist im Web inzwischen der de-facto Standard für Video bzw. für Livestreams. Es besteht meist aus mehreren Media-Playlists (wie damals im Winamp), für jede Video-Auflösung eine. Und es gibt die sogenannte Master-Playlist, die die anderen Playlists verlinkt. Die Master-Playlist wird vom Video-Player nur einmal gelesen.

Die Media-Playlist für die aktuell benutzte Auflösung wird bei Livestreams regelmäßig im Abstand mehrerer Sekunden abgerufen, um zu sehen, ob neue Media-Segmente – das sind gewissermaßen Bild und Ton in kurzen Videos von 1 bis 60 Sekunden Länge – hinzugekommen sind. Soweit erst einmal zur Theorie.

Wie funktioniert der Abruf im Normalfall?

Stell dir vor, du hast einen Server, der diesen Livestream produziert. Das klappt so weit einigermaßen gut, aber du willst nicht, dass alle deine Zuschauer über HTTPS auf diesen Server zugreifen. Er hat schließlich andere Sachen zu tun, als Daten ins Internet auszuliefern. Also könnte man ein CDN davorschalten.

Dies ruft dann die Playlisten und Video-Segmente von deinem Server ab und verteilt diese an die Browser da draußen und entlastet deinen Server. Dies ist das übliche HLS Pull und eigentlich machen alle CDNs genau dies.

Aber dann kam Akamai und dachte sich: Hold my beer, das bekommen wir bestimmt kaputt gespielt!

Was macht Akamai da jetzt anders?

Akamai meinte wohl: Warum lassen wir uns die Daten nicht einfach direkt in unser System pushen? Dann ist es schon da, sobald die Requests der User reinschallern und wir müssen das nicht erst „irgendwo“ abrufen.

Okay, soweit ist die Theorie sicherlich gut und halbwegs durchdacht. Aber eben nur die Theorie, denn nur weil die Segmente im System sind, heißt es nicht, dass Akamai sie auch ausliefert.

Die Anforderung war: sende einen Audio-Stream mit 2 verschiedenen Bitraten im HLS-Format zu Akamai. Will heißen, dass wir hier von 3 Playlisten, also 1x Master + 2x Media für die unterschiedlichen Bitraten.

Sobald also neue Segmente produziert werden, werden diese hochgeladen und danach die Media-Playlisten aktualisiert und hochgeladen. Auch soweit easy. Schade nur, dass beim Abspielen dieser Streams der Player immer wieder aufgibt, weil die Segmente beim Abruf einen Error 404 Not Found liefern.

Der erste Gedanke: Vielleicht ist es intern noch nicht verteilt. Kann passieren. Also baue ich einen Delay ein, bevor ich das Segment zur Playlist hinzufüge. Damit geb’ ich Akamai ein bisschen Zeit, intern zu verteilen. Die Versuche scheitern natürlich. Selbst nach 5 Sekunden Verzögerung für ein 2-Sekunden-Segment, also ein paar kB an Daten, gibt es immer wieder einen 404 Not Found.

Die Alternative zum Delay

Scheiße ey, geben wir ihm nicht eine festgelegte Zeit, sondern machen einfach einen HEAD-Request auf die Segment-URL. Wir rufen also das Segment nicht vollständig ab, sondern nur den HTTP-Header, der uns schon sagt, ob die Datei verfügbar ist.
Und jetzt ratet!

Richtig! Das funktioniert! Zumindest für wenige Sekunden. Denn nur weil dein Server, der die Segmente pusht, den Status 200 OK bekommt, heißt das natürlich nicht, dass die anderen CDN-Übergabepunkte (PoPs) weltweit dieses Segment auch ausliefern. Aber statt sich intern ein bisschen Zeit zu nehmen, um das Segment aus den eigenen Caches zu ziehen, liefern diese Fotzköppe von Akamai einen Status 404 Not Found an den User Client.

Rufst du es eine Sekunde später wieder ab, wird es auch wunderbar geliefert, aber leider habe ich in diesem Fall keinen Einfluss auf die Player-Konfigurationen, um den Retry entsprechend zu konfigurieren.

Also jetzt mal ehrlich: wie konnte dieser Haufen Vollidioten zu einem der größten CDNs mutieren? Ich frage mich, ob die ihr eigenes Zeug jemals selbst nutzen.