Wiedergabe von CIFS- / SMB-Freigaben mit geringer Bandbreite stabil halten bzw. cachen

Was Netflix vor allem bei geringer Bandbreite macht ist die Bitrate runter drehen. Also die Qualität verringern. In den Puffer laden sie alle. Nur gibt es immer noch Anschlüsse wo der Puffer schneller leer läuft als er gefüllt werden kann. Dann geht's nur noch über die Qualität.

Das was du also möchtest ist "Transcoding on the fly". Soweit ich weiß ist das mit Plex möglich. Das würde aber auch vom Server entsprechende Hardware voraussetzen. Man muss sich halt vorstellen, dass mehrere User gleichzeitig auf den Server zugreifen. Dann muss der Server auch noch wissen welchen Stream er trannscodieren muss und wenn es mehrere sind, dann geht das nur über Rechenleistung. Das heißt...das Ding braucht Dampf.

Kodi selbst kann das nicht und mir ist auch kein Addon bekannt welches das kann. Für Kodi gibt es auch ein Plex-Addon. Das wiederum würde aber einen Plex-Server voraussetzen.

Aber vielleicht hat noch jemand eine andere Idee

Alternativ kannst du dir auch einen Cloud-Storage kaufen. Kostet bei Herzberg nicht so viel. Die Daten kannst du dann verschlüsselt ablegen und jeder der drauf zugreift kann die Daten halt entschlüsseln.
Dafür gibt es verschiedenste Mechanismen.

Vorteil ist, dass du dich nicht mehr ums VPN und/oder die Bandbreite kümmern müsstest.

Die Leitung wird zwar auch begrenzt sein, aber ich könnte mir vorstellen, dass der Hetzner Upload vielleicht höher ist als der bei dem das NAS steht

Was Du suchst, ist bitraten-adaptives Streaming. Das funktioniert bei den gängigen Streamingformaten wie HLS, HDS und MPEG-DASH. Dazu werden mehrere Streams (oft mit unterschiedlicher Bitrate und/oder Bildgröße) parallel bereitgestellt und in sogenannte Chunks (Teilstücke) von ca. 3-7 Sek. "zerhackt" und per Webserver ausgeliefert. Je nach Netzwerkbandbreite wird immer der Chunk mit der besten Qualität ausgeliefert. Ist die Auslastung zu hoch, wird auf eine niedrigere Bandbreite geschalten und umgedreht.

Kommerzielle Server sind Wowza und Adobe Media Server, open Source ist z.B. der Nginx mit RTMP-Modul. Letzteren verwenden wir an der Uni zum adaptiven Streaming unserer TV-Kanäle.

https://www.wowza.com/wp-content/upl…g-Graphic-1.png
Den Beitrag dazu: https://www.wowza.com/blog/adaptive-bitrate-streaming

Leider keine Erfahrung mit dem Transcoding in e.g. Plex, ist aber sicherlich mal zumindestens eine sehr interessante Spielerei. Und koennte auch funkionieren

Wegen der Performance der CPU musst du natuerlich gucken, wie gut das geht. Wieviel DSL Bandbreite hast Du ueberhaupt ? Upstream ist da ja nie soo hoch, odr ?

Wegen mehrer Benutzer gleichzeitig wuerde ich mir beim Transcoding keine Sorgen machen. Sagen wir Du hast 10 Mbps upstream. Ob da jetzt ein Stream auf 10 Mbps transcodiert wird, oder 3 streams auf je 3.3 Mbps, das sollte ungefaehr auf denselben CPU Bedarf gehen. Aber das ist mal grob geschaetzt und schliesst ein, das das decodieren relativ gesehen nix kostet - was aber nur dann wahr ist, wenn das auch mit HW-beschleunigt wird. Was Plex wohl kann.

Das "pre-staging", also Kodi sagen, das er was vom Fileserver vorher runterladen sollte waere wirklich ein klasse plugin. Ich mach das halt wenn ich im Urlaub/Hotel bin immer haendisch uebre CLI, e.g.: rsync der dateien vom Server auf die lokale Platte. Unkomfortabel, aber tut.

@PvD "bitraten-adaptives Streaming" ...so heißt das also. Wieder was gelernt.

Oder halt Streaming mit adaptiver Bitrate . Was bei einem Livestream noch geht (Echtzeit-Transkodierung pro Kanal von einem HD-Stream mit 1,5Gbit/s (SDI SMPTE 292M) nach 1080p@9Mbit, 720p@4Mbit und 480p@1Mbit), braucht bei Video on Demand (VOD) richtig Rechenpower, da ja jeder Client mit einem eigenen adaptiven Bitstream versorgt werden muss. Das sind Rechnerfarmen, die zu einem CDN zusammengeschlossen werden (müssen).

Wir senden auf 3 Kanälen, jeder Kanal hat seinen eigenen Software-Transcoder (i7/ffmpeg) als dediziertes Gerät. Die sind mit jeweils 3 Streams/Kanal (die besagten 1080/720/480) gut ausgelastet (ca 50%-70% CPU). Der Webserver hat dagegen recht wenig zu tun, da er ja nur die transkodierten Streams entgegen nimmt, diese chunkt und je nach Bandbreite an die Clients verteilt.

Also mein Ansatz wäre hier auch Emby gewesen und dann das Hardwaretranscoding zu nutzen.
Mach wir hier so in der Familie und funktioniert ganz gut. Vodafone Kabel gibt einem ja auch nur 50MBit im Upload.

Ich denke die Antworten sind alle gut und erklären es auch.

Nur ein Punkt zu Netflix: Die machen es schon gut, nicht nur die adaptive Bandbreite, auch das Puffern - und ohne, gigantische Mengen RAM zu nutzen oder dass man was konfigurieren müsste und die Streams laufen auch immer schnell an (ohne zu Warten auf Puffer-Füllen(. Kürzlich habe ich beobachtet, dass Netflix keine Unterbrechung hatte, als ich den Router durchgestartet hatte (unser alter Router startete in so 60 s durch).

Bewog mich, das auch mal mit Kodi zu probieren.

Versteht ihr das Kodi-Puffer-Konzept? Die Erläuterungen im Wiki sind nicht ganz leicht technisch vollständig zu verstehen. Kodi läuft auch direkt an (bei mir) und Puffer füllt sich offenbar am Anfang der Wiedergabe.

Habe mal ein Video genommen, das (in meiner Sammlung von Fernseh-Aufnahmen) relativ hohe Bitrate hat - durchschnittlich 13,8 Mbit/s. Den Wert sehe ich auch im OS-Monitoring, wenn mal steady-State erreicht ist. Nun kann man mal raten, wie lange der Film in Kodi noch laufen sollte, wenn ich das LAN-Kabel ziehe bei testweise memorysize 600 MByte. Laut Wiki: "Note: For the memory size set here, Kodi will require 3x the amount of RAM to be free." sollte damit 1,8 GByte an Speicher verbraucht werden (Quelle: HOW-TO:Modify the video cache - Official Kodi Wiki)

Bei 1,8 GB Puffer sollte der Puffer theoretisch für gut 17 Minuten reichen. (Abzüglich von mir aus eine kleine Menge zur Verwaltung des Puffers). Rechnet man die 600 MByte, dann für 6 Minuten. Rausgekommen ist 4:30. Erst mal noch plausibel, zu den 600 MByte. Aber warum einen Netzwerkpuffer mit Faktor 3 versehen? Und jetzt kommts: laut OS-Monitoring wurde der gar nicht gebraucht. Memory-Footprint von Kodi wuchs auf gut 1 GByte an, während der Wiedergabe (nach erreichen des Steady-State der genutzten Netz-Bandbreite blieb das auch erwartungsgemäß stabil). 1 GByte passt zum Footprint ohne [definition='2','1']advancedsettings[/definition] plus gut 600 MByte. Also Fehler in der Wiki-Doku? Warum sollte auch jemand einen Ender-User-konfigurierbaren Wert erfinden namens "memorysize", den der Enduser dann erst mal für sich mit 3 multiplizieren muss? Wenn da wirklich programmintern das in 3 Bereiche aufgeteilt wird, würde man doch im Code durch 3 teilen? Ist viel schneller gecodet, als die Faktor-3 Doku im Wiki geschrieben oder mein Beitrag hier

Mein kleines Experiment war unter Windows 10, Kodi 19.3. Schaue mir bei Laune auch noch Mal die Situation an unter Android mit adb shell. Geroutetes Device habe ich nicht. Dann prüfe ich auch noch Mal genauen Memory-Footprint von Netflix.

Ohne Cache-Konfig in [definition='2','1']advancedsettings[/definition] überdauerte der Stream übrigens 19 s in Kodi, entspricht ziemlich genau 32 MiB Puffer. Passt eigentlich auch nicht wirklich gut zu den im Wiki genannten 20 MiB bzw. mit Faktor 3 dann 60 MiB. Ist aber in den meisten Fällen sicherlich genug, um sehr viele typische kurzzeitige Netzwerk-Bandbreiten-Fluktuationen auszugleichen.

Und bitte nicht missverstehen oder mit "PR welcome" antworten. Geht mir nicht ums Kritisieren, sondern ums Verstehen.

Vielleicht kämpfe ich mich auch Mal durch den Quelltext, um zu sehen, was da wirklich dahinter steckt.

EDIT: Zusatzfrage: Wie verhält es sich bei Live-Streaming? Offenbar wird es da nicht sinnvoll möglich sein, einen 600 MB Puffer zu füllen. Wird da konstanter kleiner Puffer verwendet? Der mit memorysize angegebene Puffer wird da vollkommen ignoriert? (Habe hier ja auch schon bei Livestreaming-Ruckeln die Empfehlung gesehen, memorysize zu vergrößern ... Wenn ich 20:00 das Erste anknipse, will ich doch nicht um 20:05 die Tagesschau sehen, oder schlimmer noch, die Nachbarn haben schon vor 5 Minuten über das Tor gejubelt)

@buers

Interessantes Thema. Kann ich auch vielleicht das ein oder andere zu sagen.

Meinst du aber nicht, dass das vielleicht seinen eigenen Thread wert ist? Das Thema wird sehr komplex werden und geht dann vielleicht zu sehr an diesem Thema vorbei.

Klar, gerne auch in einem neuen Thread. Wer will oder kann, darf meine Beitrag gerne verschieben. Ich kann sonst auch gerne per Copy+Paste das nochmals neu aufmachen.

Zitat von WatchDog

Was passiert denn, wenn man Kodi 600MB puffert und während er aus dem Puffer abspielt ein Netzlaufwerk oder USB-Laufwerk weg bricht, dann aber wieder online ist, bevor der Puffer leer gelaufen ist?
Ich würde vermuten, dass der Kodi dann trotzdem am Ende des Puffers erstmal stehen bleibt und nicht während des Playbacks schon weiter puffert, sobald die Quelle wieder da ist.

Gute Frage, gestern bei meinem Test lief Kodi weiter. Ich hätte vermutet, der füllt halt entsprechend vorhandener Bandbreite den Puffer wieder auf, User merkt nix. Heute bei meinem Test spielte Kodi den Puffer einfach nur leer, Abspielen beendete sich, ich landete wieder im Hauptmenu. Da kann man dann sofort wieder weitermachen. Das will man eigentlich nicht erwarten. Möglicherweise abhängig von Länge der Unterbrechung. Nachdem LAN wieder da war, hat Kodi keine Daten mehr übertragen (andere Anwendungen, wie gleichzeitig geöffnetes Outlook aber schon).

Lokale(-USB-)Platte wird übrigens nur mit buffermode 1 gepuffert. Nicht dass ich dächte, man bräuchte das ...