HLS Stream Abbruch - IOS

[janee]

Hallo,

ich habe ein Problem mit dem HLS Streaming auf IOS Geräte.

Der DMS ist übers Internet zu erreichen und mit einem Passwort geschützt.

Variante 1: Mobilfunk (LTE) - Stream läuft

Variante 2: WLAN (nicht am selben Anschluss des DMS) bzw. Mobiler Hotspot und VPN (FritzBox) - Stream läuft

Variante 3: WLAN (nicht am selben Anschluss des DMS) bzw. Mobiler Hotspot- Stream beendet nach kurzer Zeit (~ 1 min)

Ich habe das selbe Verhalten bei einem IPhone und IPad.

Anbei der Auszug aus dem Debug Log.

Der Erste HLS Stream entspricht Variante 3.

Der Zweite - Variante 1.

 

MfG Christian

 

Debug.txt

[Griga]

20 hours ago, janee said:

Variante 3: WLAN (nicht am selben Anschluss des DMS) bzw. Mobiler Hotspot- Stream beendet nach kurzer Zeit (~ 1 min)

 

Laut Log hat der Client zu lange nichts von sich hören lassen. Um 20:30:57.433 erfolgte der letzte Zugriff, um 20:31:02.272 (also knapp 5 Sekunden später) hat der DMS den Stream wegen Timeout abgeräumt.

 

Hintergrund: Bei HLS werden viele einzelne Dateien (Playlisten und Segmente) ausgeliefert. Manche Clients bauen für jede Datei eine neue Verbindung auf und beenden sie nach dem Download wieder. Dadurch entstehen Perioden, in denen der DMS keine Verbindung zum Client hat, also nicht weiß, ob der noch mal was von sich hören lässt oder sich vom Acker gemacht hat. Andererseits gibt es Clients, die die Verbindung permanent aufrecht erhalten ("connection: keep-alive"), sogar dann, wenn sie keine Daten mehr brauchen (insbesondere Browser).

 

Deshalb schaltet der DMS den Stream ab, wenn eine gewisse Zeit keine Zugriffe erfolgt sind, um nicht unnötig einen Tuner zu belegen und mit FFmpeg CPU-Last zu produzieren.

 

Fragt sich, ob das Timeout bei dir zu knapp bemessen ist. Da es nicht konfigurierbar ist, müsste man es mit einem permanenten HLS Stream testen, der unabhängig von Client-Zugriffen läuft. Er lässt sich über das API konfigurieren. Siehe hier "Ergänzt: Transkodiertes HLS Streaming: Erzeugung von permanenten HLS Streams...". Im einfachsten Fall sieht das so aus:

 

Stream starten (erster Sender aus der Senderliste mit Index 0, alle anderen Parameter Default, ein paar Sekunden warten bis zum ersten Client-Zugriff):

http://[Webserver-IP]:[Webserver-Port]/api/starthls.html?streamid=test&chid=0

 

Stream stoppen:

http://[Webserver-IP]:[Webserver-Port]/api/stophls.html?streamid=test

 

URL für Client:

http://[Webserver-IP]:[Webserver-Port]/upnp/master.m3u8?streamid=test

 

Schau mal, wie das ausgeht.

 

[janee]

vor 8 Stunden schrieb Griga:

Stream starten (erster Sender aus der Senderliste mit Index 0, alle anderen Parameter Default, ein paar Sekunden warten bis zum ersten Client-Zugriff):

http://[Webserver-IP]:[Webserver-Port]/api/starthls.html?streamid=test&chid=0

 

Stream stoppen:

http://[Webserver-IP]:[Webserver-Port]/api/stophls.html?streamid=test

 

URL für Client:

http://[Webserver-IP]:[Webserver-Port]/upnp/master.m3u8?streamid=test

 

Schau mal, wie das ausgeht.

 

Hallo Griga,

mit der Methode funktioniert es wie vorgesehen. Stream läuft!

Die Frage, die sich mir stellt ist ja, ob dieses Verhalten wie im ersten Post beschrieben, bei anderen reproduzierbar ist.

Danke für deine Hilfe

Christian

[Griga]

Immerhin ein Work-Around, aber das Handling mit permanenten Streams ist doch auf Dauer etwas mühsam. Insbesondere, wenn man Zappen will.

 

Ich denke, ein Tweak wäre nicht schlecht, mit dem man das Timeout beeinflussen kann. Mal schauen, wie das realisierbar ist. Eventuell wirst du es über Ostern testen müssen, also schön online bleiben

 

[janee]

vor 3 Minuten schrieb Griga:

Immerhin ein Work-Around, aber das Handling mit permanenten Streams ist doch auf Dauer etwas mühsam. Insbesondere, wenn man Zappen will.

 

Ich denke, ein Tweak wäre nicht schlecht, mit dem man das Timeout beeinflussen kann. Mal schauen, wie das realisierbar ist. Eventuell wirst du es über Ostern testen müssen, also schön online bleiben

 

sollten wir hinbekommen

[Griga]

War einfach. Du hast schon eine PM.

[janee]

Hallo Griga,

das Gute zuerst. Der Tweak tut was er soll.

Leider wird mein Problem dadurch nicht gelöst.

In der angehängten Log Datei habe ich um 18:57:00 den Stream vom IPhone angefordert. ca. 10 sec später läuft der Stream auf dem IPhone. Genau eine Minute später (18:58:10) läd das IPhone keine Daten mehr nach. Das Bild bleibt stehen. Ich habe das verlängerte Timeout für HLS Streams auf 15 sec eingestellt. Der DMS produziert auch weiterhin Daten bis der Stream abgeräumt wird.

PS: Das ist alles Handgestoppt.

Danke

Christian

 

 

 

debug.txt

[Griga]

Tja, wieder das gleiche Phänomen, nur durch den Tweak länglicher.

 

Um 18:58:10.103 erfolgt der letzte Zugriff durch den Client. Danach produziert FFmpeg ins Leere. Knappe 20 Sekunden später um 18:58:29.853 räumt der DMS den Stream ab.

 

Die Frage ist, warum hört der Client einfach auf? Im Log ist keine Meldung zu sehen, dass der Client etwas nicht bekommen hätte, was er haben wollte. Und warum funktioniert es bei einem permanenten Stream?

 

 

 

[janee]

Frohe Ostern,

Ich habe folgendes gemacht, um den Fehler einzugrenzen. (Hätte ich schon mal früher machen sollen)

Anstatt des Mobile Webinterface, habe ich das normale genommen und den stream gestartet. Und siehe da es läuft...

Somit würde ich den Fehler im Mobile Webinterface vermuten.

Ich hoffe diese Erkenntnis hilft, um das Problem einzugrenzen.

[janee]

So,

ich habe das Problem weiter eingegrenzt. In meinem Fall liegt ein Pufferproblem vor. D.h. ich habe im Mobile Webinterface den Puffer immer auf Mittel gelassen. Das scheint zu Problemen zu führen. Nun habe ich den Puffer auf hoch und siehe da, der Stream läuft durch. Warum? Keine Ahnung. Vielleicht habt ihr ja noch eine Erklärung für mich.

Schönen Ostersonntag

Christian

[Griga]

Benutzt du die iOS App von Markus oder einfach nur die URL des mobilen Webinterface direkt in Safari?

 

11 hours ago, janee said:

Vielleicht habt ihr ja noch eine Erklärung für mich.

 

Nö. Keine Ahnung, was sich Apple beim Timing der HLS-Wiedergabe gedacht hat und wie dein Netzwerk das beeinflusst. Die Firma hat ja HLS erfunden. Nichtsdestotrotz ist Safari bzw. die Mac/iOS-Wiedergabe-Engine ein schwieriger Client. Im DMS gibt es eine Sonderbehandlung, an der ich schon ohne Ende herumgebastelt habe. Ist halt Apple. Ziemlich etepetete. Wenn irgendwas nicht genau so ist, wie Apple es haben will, funktioniert es nicht.
 

17 hours ago, janee said:

Anstatt des Mobile Webinterface, habe ich das normale genommen und den stream gestartet. Und siehe da es läuft...

 

11 hours ago, janee said:

ich habe im Mobile Webinterface den Puffer immer auf Mittel gelassen. Das scheint zu Problemen zu führen. Nun habe ich den Puffer auf hoch und siehe da, der Stream läuft durch.

 

Die beiden Maßnahmen laufen ungefähr auf's gleiche hinaus. HLS ist ein segmentierter Stream. "Puffer" bestimmt, wie viele Segmente mit welcher Dauer der DMS vorab produziert, bevor der Client was bekommt. Das sieht konkret so aus:

 

Mobiles WIF Low: 2 Segmente mit 1 Sekunde Dauer = 2 Sekunden

Mobiles WIF Mid: 2 Segmente mit 2 Sekunden Dauer = 4 Sekunden

Mobiles WIF High: 3 Segmente mit 3 Sekunden Dauer = 9 Sekunden

Desktop WIF Default: 3 Segmente mit 2 Sekunden Dauer = 6 Sekunden

 

Das hat natürlich Einfluss auf die Wartezeit bis zum Wiedergabestart. Beim Desktop WIF ist das in den Experten-Einstellungen der Stream-Konfiguration beeinflussbar (Parameter seg und segdur). Beim mobilen WIF müsstest du im HTML- und Javascript-Code eingreifen, um das für deine Zwecke zu optimieren.

 

[janee]

Hallo Griga,

vielen Dank für die Erklärungen. 

 

vor 7 Stunden schrieb Griga:

Benutzt du die iOS App von Markus oder einfach nur die URL des mobilen Webinterface direkt in Safari?

Ich nutze die IOS App von Markus.

 

 

Gruss Christian