Streaming auf iOS/macOS oder anderes -> HLS Stream mit ffmpeg/avconf

H,
warum nimmst du nicht h. 265?
MfG Stefan

Hi,
mit i*** bin ich überfragt. Nutze sowas nicht.

h.265 ist zumindest extrem bandbreiteneffizient. HD Filme auf eine CD zu tun, ist doch ganz ok

MfG,
Stefan

Abend,

mir war auch noch nicht bewusst, dass ffmpeg ein Segmenter integriert hat und außerdem die passende m3u8 erstellen kann,


Ich habe mal mit folgenden FFMpeg Command einen Stream erstellt und mit Apache ausliefern lassen.

ffmpeg -analyzeduration 1M -i "http://127.0.0.1:3000/1.ts" -vcodec libx264 -bufsize 2000k -maxrate 1200k -crf 22 -g 50 -map 0:v -map a:0 -vf "yadif=0:-1:1, scale=640:360" -preset medium -tune film -vprofile main -level 30 -acodec aac -strict -2 -ab 64k -ar 44100 -ac 2 -async 1 -f hls -hls_time 9 -hls_list_size 10 -hls_wrap 10 stream.m3u8

Und zusammen mit Hannemann's Lösung funktioniert der Stream tadellos unter Chrome (Android/Linux/Windows), Firefox (getestet unter Windows) und dem Microsoft Edge. Der IE11 streikt und ist somit raus

Da ich mich schon eine Weile mit HLS beschäftigt habe, musste ich aber feststellen das HLS leider nicht wirklich für OnDemand-Live-Streaming geeignet ist. D.h. es muss ja erst der Sender getuned werden, dann muss ffmpeg mit dem Umwandeln beginnen und bis dann die ersten Segmente und die M3U8 eintrudeln ist schon eine gewisse Zeit vergangen und da steigen die meisten Clients schon aus. Wenn dieser ganze Vorgang schon läuft und man erst dann auf den Stream zugreift gibt es natürlich keine Probleme.

Das nächste Problem ist, dass wenn der Client die Verbindung schließt, z.B. wenn der Browser geschlossen wird, dann läuft ffmpeg munter weiter und blockiert weiter den Tuner (und lastet die CPU nicht unerheblich aus). Man könnte natürlich manuell vom Client aus irgend ein Befehl senden, der FFMpeg abschießt, aber das ist unschön. Denn wenn mal die WLAN-Verbindung vom Client zusammenbricht kommt so ein Befehl nicht an und FFMpeg läuft weiter.

Wenn das ganze dann noch Multi-User tauglich werden soll, wird es noch problematischer. Es muss ja für jeden unterschiedlichen Kanal ein eigener FFMpeg Prozess gestartet werden, d.h. wenn die Segmente und die M3U8 über Standard-Webserver (z.B. Apache) ausgeliefert werden, müssten die alle unterschiedliche Namen bekommen.

Man braucht also für die Auslieferung der Dateien und der FFMpeg-Überwachung ein speziell für diese Fälle angepassten Webserver .

Mein XMLAPI Plugin kann das zwar alles, aber zufrieden bin ich da noch lange nicht. Den Segmenter den ich da integriert habe, hab ich nicht selbst entwickelt und ist schon recht alt. Keine Ahnung ob die Segmentierung und die Index-Datei Erstellung 100% Standard-konform ist. Ich denke die FFMpeg Entwickler haben da 1000x mehr Ahnung von, als ich.

Ich hatte HLS auch nur in das Plugin integriert, weil sich Android weigerte einen Standard-HTTP-TS-Stream (wie ihn z.B. Streamdev liefert) abzuspielen. Da ich dafür aber inzwischen eine Lösung gefunden habe, und ich somit nicht mehr auf das eher ungeeignete HLS-Protokoll angewiesen bin, fliegt zumindest die jetzige Implementierung wieder raus.

Aber da ich das Thema sehr spannend finde und inzwischen sehr viele Player und Browser (wenn auch teilweise nur mit Hannemanns entdeckter HLS-Javascript-Lösung) mit HLS umgehen können, bin ich gerne dazu bereit etwas zu einer vernünftigen Lösung beizutragen. Frickel-Lösungen gibt es ja schon einige

Mit Apple Hardware kann ich aber nicht dienen

VG
Karl

Quote

Frage - wenn ein http server in dem VDR Plugin wäre, dann könnte man doch checken ob die Segmente noch abgeholt werden... und wenn nicht, dann automatisch den ffmpeg thread beenden und aufräumen.

Ja so ähnlich mache ich das ja in dem Plugin. Ich prüfe allerdings nicht ob noch auf Segmente zugegriffen wird, sondern ob die M3U8 noch abgeholt wird. Auf die wird ja sekündlich oder noch öfter zugegriffen.

Ich versuche mal die Tage im XMLApi-Plugin ffmpeg die Erzeugung der Index-Datei und der Segmente zu überlassen, statt es selbst zu machen. Vielleicht löst es ja das eine oder andere Problem, dass es da noch gibt.