Kein sauberer Datenaustausch beim HLS Stream

[WonG.]

Hi allerseits,

vorneweg: Tolles Produkt, wirklich ein super Job, den ihr da macht!

Wenn ich einen FFmpeg kodierten Stream dauerhaft starte (mit IP:Port/api/starthls.html?preset=0&ffpreset=slow&chid=XXX&streamid=XXX), also so, dass er unabhängig von den verbundenen Klienten konstant bestehen bleibt, dann findet der Datenaustausch leider nur stoßweise statt. Das hat den Nachteil, dass eine wesentlich höhere Bandbreite für einen unterbrechungsfreien Stream benötigt wird, als rechnerisch notwendig. Dass er so wesentlich störanfälliger ist, muss ich wahrscheinlich nicht erwähnen. Das Ganze sieht dann in etwa wie folgt aus:

 

 

Wünschenswert wäre ein schön gleichmäßiger Datenverkehr, vergleichbar mit dem, der erzielt wird, wenn ich einen temporären Stream via IP:Port/flashstream/stream.ts?preset=ts%20HD%203600%20kbit&ffpreset=slow&chid=XXX starte:

 

 

Gibt es eine Möglichkeit, den Datenstrom zu regulieren? Und ist diese beständige Streamfunktion auch für die anderen Varianten vorgesehen (WebM, Flash, TS) oder wäre das technisch zu umständlich?

 

 

Vielen Dank und mit freundlichen Grüßen

WonG.

[Griga]

Wenn ich einen FFmpeg kodierten Stream dauerhaft starte (...) dann findet der Datenaustausch leider nur stoßweise statt.

 

Das liegt bei HLS in der Natur der Sache. Es handelt sich um einen segmentierten Transportstream, der abschnittweise heruntergeladen wird, nicht kontinuierlich. Wenn der Client sich verbindet, liegen beim Server bereits Segmente abholbereit vor (in deinem Fall 3 Segmente á 2 Sekunden, Default). Und wenn sich dein Gierschlund von Client so schnell wie möglich alles auf einmal reinzieht, was willst du machen? Es liegt auch in der Natur von Streaming Clients, im voraus zu lesen und zu puffern, falls möglich, um eventuellen Drop Outs aufgrund verzögerter Datenlieferungen vorzubeugen.

 

Dass er so wesentlich störanfälliger ist, muss ich wahrscheinlich nicht erwähnen.

 

Nein, musst du nicht, weil es IMO nicht stimmt. Solange sich die mittlere (!) Datenrate nicht der maximal im Netzwerk möglichen Datenrate nähert, sehe ich da kein Problem. Schließlich handelt es sich um eine robuste TCP Verbindung, und das ganze ist für Internet-Verhältnisse konzipiert, also wesentlich schwierigere als in einem Heimnetzwerk. Wenn das Netzwerk die durch das Zugriffsverhalten des Clients erzeugten Spitzen nicht hergibt, wird dieser halt zeitweise etwas ausgebremst. Die Sache regelt sich von selbst.

 

Gibt es eine Möglichkeit, den Datenstrom zu regulieren?

 

Du kannst bei HLS an der Anzahl und Dauer der bereitgehaltenen Segmente drehen (siehe hier angehängte Textdatei), aber ich sehe darin keinen Sinn. Wenn du sie reduzierst, erhöhst du eher die Störanfälligkeit als dass du sie verbesserst.

 

Und ist diese beständige Streamfunktion auch für die anderen Varianten vorgesehen (WebM, Flash, TS) oder wäre das technisch zu umständlich?

 

Es ist eher eine Frage, ob das Format es hergibt und einem Client "random access" ermöglicht, also sich an beliebiger Stelle bzw. zu einem beliebigen Zeitpunkt im Stream einzuklinken. Typische Dateiformate müssen von Anfang an gelesen werden, weil relevante Header nur einmal enthalten sind.

 

In Flash wird hier mit Sicherheit nicht mehr investiert - kannst du also vergessen. WebM ist ein Matroska-Ableger (.mkv), da wäre ich misstrauisch, ob das geht - müsste man recherchieren. TS ist für random access ausgelegt, da wäre es möglich. Aber warum sollte man?

 

Das Problem bei HLS "on demand" ist, dass der Server erst eine bestimmte Menge Daten auf Vorrat produzieren muss, bevor der Client etwas bekommt - das Protokoll sieht es so vor (Beschwerden bitte an Apple...). Wenn ein Client einen HLS Live Stream anfordert, muss er beim RS mit der Standard-Einstellung mindestens 3 Segmente x 2 Sekunden = 6 Sekunden warten, bis Daten kommen. Diese Wartezeit vermeidet ein permanent "auf Verdacht" bereitgehaltener Stream. Die im Internet von zahlreichen Fernsehsendern für iPhone & Co angebotenen HLS Live Streams sind alle permanente Streams.

 

Bei einem mehr oder weniger kontinuierlichen (unsegmentierten) TS gibt es diese Verzögerung nicht, oder zumindest nicht in diesem Ausmaß. Also warum sollte man ihn permanent im Netzwerk bereitstellen? Das verschwendet nur Ressourcen.

[WonG.]

Alles klar, vielen Dank für diese Ausführliche Antwort. Das bedeutet dann wohl, dass das HLS Preset ein wenig mehr Bandbreite benötigt, als das Äquivalent der anderen Varianten. Jedenfalls stoße ich leichter an die Kapazitätsgrenze und rutsche in den problematischen Bereich. Ich experimentiere aktuell auch mit den QVS Presets, leider verschlimmert sich dort besagter Effekt. Mit welcher Einstellung lässt sich bei gleichbleibender Auflösung die benötigte Bandbreite, bzw. das entstandene Datenvolumen bei geringstem Qualitätsverlust verringern? Ich werde mal diesen Wert schrittweise erhöhen: "-q 24", liege ich damit richtig?

Edited April 6, 2016 by WonG.

[WonG.]

Okay, mit "-q 26" bin ich in einem Bereich, der für mich funktionieren könnte. Besteht noch eine Möglichkeit, die Bewegungen etwas weicher zu bekommen? Ich weiß, dass eine Framerateerhöhung zu 99% nichts bringen würde. Auf einen Versuch wollte ich es dennoch ankommen lassen. -framerate 30 hatte leider keine Auswirkung, ist der Parameter falsch oder ist die Framerate einfach auf 25 festgelegt?

Edited April 6, 2016 by WonG.

[Tjod]

Das bedeutet dann wohl, dass das HLS Preset ein wenig mehr Bandbreite benötigt, als das Äquivalent der anderen Varianten.

Wieso? Wenn du an die Bandbreitengrenze kommst, hast du die Spitzen nicht mehr, da der Client nicht alles auf einmal herunterladen kann und es so über mehr Zeit verteilt.

 

Wirkliche Bandbreiten Tests kannst du eigentlich nur durchführen, indem du die Bandbreite effektiv limitierst. Also Clients die Daten nicht schneller abrufen können.

[WonG.]

Na ja, wenn ich den Stream temporär z.B. mit einem TS Preset starte, dann läuft er reibungsfrei, über HLS kommt es immer wieder zu Aussetzern. Ich habe das Bandbreitenmittel auch nicht explizit gemessen, aber an Hand der Kegel lässt sich abschätzen, dass es insgesamt ein etwas größeres Datenvolumen pro Zeiteinheit verursacht.