Videos ruckeln bei Bitrate > 60Mbps

Zitat von te36

Naja, der Satz von Pytagoras gilt doch au ch noch immer

Ich finde halt mit google nix neueres, was mir sagt ob Kodi jetzt unter windows samba integriert oder nicht. Klar, koennte man auf forum.kodi.tv mal nachfragen. Oder halt den quellcode analysieren. Alles noch mehr Analysearbeit.

Ja, ich kann es dir leider auch nicht beantworten. Verschiedene Dateien im Kodi Core Code lassen zumindest darauf schließen, dass es da auf jeden Fall irgendwas gibt.

Code-Analyse muss man da gar nicht machen. Man kann einfach über die Powershell SMB komplett deaktivieren. Also alle Protokolle und dann schauen ob Kodi noch was einbinden kann

Meiner Meinung nach sind wir keine Feinde.

Wir haben Meinungsverschiedenheiten und das ist gut so. Wenn wir alle der gleichen Meinung wären gäbe es nie neue Erkenntnisse

Wenn es darum geht Samba unter Android ohne Kodi einzubinden.

Dann mal folgendes Testen.

Home · wa2c/cifs-documents-provider Wiki · GitHub

DaVu

Ich verstehe auch das er sein Netzwerk nicht einfach so ändern kann, aber ich bin mir absolut sicher das es mit den richtigen Einstellungen auch mit Kodi und seinen Netzwerk funktioniert.

Vllt. Ist VLC Player da einfacher in der Handhabung, das will ich nicht Mal abstreiten, aber das es nicht mit Kodi funktioniert glaub ich nicht. Daher die Bitte einfach auch Mal das Addon nutzen was ich oben geschrieben habe.

DaVu, sehr faire Antwort! Nur eins dazu

Zitat von DaVu

Weiter würde ich ein kleines Vermögen darauf wetten, dass ein WLAN welches keine Abhängigkeit zu DLAN hat, aber die gleichen Durchsatz aufweist auch besser funktioniert und nicht zu einem derartigen Verhalten führt.

Diese Wette würde ich dir nicht empfehlen! Siehe meine Messdaten - die sind noch schlechter vom Durchsatz bei Kodi SMB. Ich bin mir auch sehr sicher, dass da alles Rumdoktern am Cache nix hilft - da fehlt Durchsatz. Cache kann den Durchsatz nicht erhöhen, nur Schwankungen ausgleichen.

Zitat von te36

Ansonsten sind mir auch die Ergebnisse mit Windows merkwuerdig:

Wieso? Meine Ergebnisse stützen was du schriebst. Ich sagte doch, dass ich unter Windows keinen (signifikanten) Unterschied feststellen kann, ob ich auf das in Windows gemountete Verzeichnis zugreife oder ob ich in Kodi direkt smb:// nutze.

Zitat von HypsterX

Ich werfe mal wieder WebDAV in den Raum

Habe zwar grade kein WebDAV laufen, brachte mich dennoch auf die Idee zum Test mal ftp zu nutzen. Der Copy-Test im Kodi-Dateimanager brachte 25 MByte/s (vergleiche 5 MByte/s mit smb).

Und was soll ich sagen - alle Testvideos die ich probierte bis 200 MBit/s liefen ohne Ruckeln! 250 MBit/s ruckelte.

Vielleicht prüfe ich Mal die Abhängigkeit von smb-Version. smbv1 hatte ich allerdings schon seit vielen Jahren nicht verwendet. smb3 sollte keine schlechtere Performance als smb2 haben, eher im Ggt. (obwohl man da sicher nicht viel rausholen kann. Bei großen Dateien wie Video zeigten meine Tests seit langem, dass erwartungsgemäß alles gleich schnell ist, smb, ftp, nfs - man kriegt halt die typischen 110 MByte/s über Gbit LAN verlässlich hin).

Ich hatte vor Jahren schon mal versucht den Kodi Cache Code und Übertragungs-Code zu verstehen - mehr oder weniger erfolglos Mache mich vielleicht noch mal dran. Wenn ich mich nicht ganz täusche, kam ich damals zum Schluss, dass der smb-Code *nicht* von Kodi selbst entwickelt wurde, sondern dass da Original-Quellen von Samba/smbclient genutzt wurden. Ähnlich wie es bei ffmpeg ist. Kann das jemand bestätigen? Ich denke, der Original-Code ist schon ok und performant - aber wie Messwerte hier zeigen ist es unter Kodi langsam. Vielleicht nur ein klitze-kleiner Fehler bei der Integration des Codes, irgendwas schlecht/falsch konfiguriert/parameterisiert, Debug-Optionen in prod, was auch immer ...

Ich denke gerade in Bezug auf Android Boxen spielt auch immer die Hardware eine Rolle auf der das ganze läuft.

Mit meiner Shield TV Pro hatte ich mit Samba unter Kodi niemals Probleme, mit dem Fire TV Cube 3 und ansonsten gleichen Netzwerk Aufbau war unter Samba nicht viel zu holen an Performance.

Hier brauchte wirklich nur WebDAV und (S)FTP (welches aber nicht so wirklich für die Media Zwecke geeignet ist) die Lösung.

Habe nochmals verschiedene Konstellationen vermessen, mit ganz interessanten Ergebnissen.

Das Positive: Mit Gbit/s LAN alles super. Meine Filmaufnahmen (mit typischerweise ~10 Mbit/s Bandbreite) machen auch im WLAN in keiner Konstellation Probleme.

Mein Fire TV Stick kann von lokalem Speicher das 400 Mbit/s Testvideo ruckelfrei abspielen. (Nicht dass das Ruckeln gar nicht am Netz läge).

Unabhängig vom OS (Windows 11 Pro, Fire-TV, Android TV 10 und Android) zeigt Kodi - abhängig vom Übertragungsprotokoll, eher sehr enttäuschende Übertragungsraten im WLAN beim Kopier-Test im Kodi-Dateimanager. Ganz besonders langsam im WLAN ist smb, nfs viel schneller, ftp am schnellsten - nicht weit weg von der Rate die ein Datei-Manager außerhalb Kodis schafft.

Entsprechend fangen Testvideos auch schon früher an zu ruckeln oder nachzupuffern als man das erwarten würde, tlws. viel früher. (Beispiel FireTV - wo X-Plore 30 MByte/s =240 Mbit/s Übertragungsrate mit smb schafft, aber in Kodi bereits 60 Mbit/s ruckeln). te36, smb-Version, wo getestet, hatte praktisch keinen Einfluss auf die Ergebnisse.

Der Kodi Datei-Manager ist nur extrem mühselig zu bedienen auf Tablet mit Estouchy Skin. Fast unzumutbar. Gibt auch lustige Situationen, wo man aus dem Kodi-Datei-Manager nicht mehr leicht rauskommt. Will man nach oben über ".." kommt mal "keine Verbindung zum Netzwerkserver" (osä). Kann man nur mit ok quittieren. Ich fand keine Möglichkeit mehr, aus dem Verzeichnis rauszukommen. (Passierte, wenn offenbar der ftp-Server die Session rauswarf wegen timeouts)

Ohne das Vorgehen ganz genau zu dokumentieren, kurzes Testsetup.

Geräte: Fire TV 4k Max 2nd Gen; Samsung Galaxy Book3 360, Windows 11 Pro; Magenta TV Stick, Android TV 10; Lenovo Tablet TV-X606X (eher Low-End), Android 10, WLAN alles im 5 GHz Band getestet, Speedport Smart 4. Habe gewisse Vorsicht walten lassen, dass beispielsweise bei einer Wiederholung von einer Aktion keine Cache Effekte auftreten. Dafür habe ich auf dem NAS (OMV 6 auf HP Microserver) identische Dateien unter mehreren Namen dupliziert und immer neue Datei genommen. [definition='2','1']advancedsettings[/definition].xml hatte keine Settings zu Cache, jeweils nur Setting zum Umleiten der Thumbnails auf NAS (sollte keinen Einfluss auf den Test haben). Neben Stoppuhr und Geschwindigkeits-Anzeige auch die Geschwindigkeiten gegengecheckt auf NAS mit iftop und mit OMV Oberfläche, auf Windows mit resmon/perfmon/taskmgr.

WLAN-Messwerte sind naturgemäß in einem Mehrfamilienhaus nicht so ganz exakt zu reproduzieren. Aber die Daten liegen so weit auseinander, dass sich dennoch ein eindeutiges Bild ergibt.

Die Messwerte:

Ich frage mich, sieht es bei euch besser aus? Insbesondere smb-Zugriff im WLAN, in allen Konstellationen hier, ist unter Kodi weitab von dem, was ich erwartet hätte.

Mit ein fire TV 4k 1gen ruckelt bei mir nichts mit angepassten Cache. Ohne Anpassung wird bei bestimmten scenen nachgebuffert.

DayOne, ich hatte das vorher schon gesagt - ist für mich nicht plausibel, dass da Cache helfen kann. (Auf verschiedenen Gründen, aber da wird es schnell kompliziert in der Argumentation).

Dennoch, einen Fall nachgetestet. Cache verfünffacht von Default. Siehe das Ergebnis:

Schlechter als vorher. Aber, ich sag mal, kann auch Zufalls-Schwankung sein. Nur, ich hatte auch schon vor Jahren solche Tests gemacht - nicht ein Mal Verbesserung durch "Cache-Optimierung" objektiv bestätigen können. Wenn es mein technisches Verständnis sagt, die Messungen sagen es, dann wird schon was dran sein (Habe durchaus Jahrzehnte professionelle Erfahrung im Programmieren und Durchführen von Lasttests und Performance-Analysen).

Aber klar, mag sein, dass ich mich da wo täusche. Ernsthaft - mache doch eine ähnliche Messreihe (z.B. mit den Jellyfin Tesfiles, oder halt mit welchen, mit denen auch andere die Situation nachstellen können). Wenn du andere Ergebnisse erhältst kann man das im Detail vergleichen. Da wird man schon einen Schluss draus ziehen können.

Das waren übrigens die Zeilen, die ich in [definition='2','1']advancedsettings[/definition] hinzugefügt habe (und ich hatte früher schon viele andere Kombinationen getestet):

<cache>
    <memorysize>104857600</memorysize>
    <buffermode>4</buffermode>
    <readfactor>10</readfactor>
  </cache>

Bei dem 30 Mbit/s Testfile, das unter diesen Bedingungen geruckelt hat bedeuten die 100 MiByte Cache übrigens, dass das ganze Test-Video-File in den Cache passt. Da kommt wohl noch hinzu, dass Kodi den Cache da nicht optimal einsetzt.

Doch der Cache hilft.

Hier an meinen Fire TV Cube 3 via WLAN @ WebDAV wird mit 64MB Cache alles bis 150 Mbit/s ohne Probleme abgespielt.

Darüber macht es meiner Meinung nach sowieso keinen Sinn zu testen, weil es keinen UHD Film gibt der auch nur annährend an die 150 Mbit/s heran kommt.

buers

Ich habe solche Tests auch gemacht. Also reiner Kopiervorgang mit unterschiedlichen Settings für den Cache und keine eklatanten Unterschiede feststellen können (alles NFS).

Meine Vermutung:

Der Cache hat keine Auswirkung auf Dateioperationen oder anders ausgedrückt...der Cache findet nur beim Playback Anwendung.

HypsterX

Ich stimme dir bedingt zu.

Aber jetzt nimm mal folgendes an:

Du sagst "bis 150Mbit/s ist alls im Lot". Und du hast damit auch Recht, dass kein UHD Film da ran kommen wird.

Nehmen wir aber jetzt mal den Fall an, dass es doch mal sein muss und dein Netzwerk gibt nicht mehr her...Und dann stellst du fest, dass ein anderer Player keine Probleme hat 200 oder sogar 250Mbit/s abzuspielen. Kodi bekommt das aber nicht hin. Warum auch immer.

Würde dich das nicht wundern? Wenn es deine Software wäre...hättest du da nicht die Motivation es auch so gut zu machen wie andere?

In der Software-Programmierung neigt man schnell dazu zu sagen "wenns nicht läuft brauchen wir mehr Ressourcen". Also mehr RAM, mehr CPU, mehr Speicherplatz. Es wird leider oftmals nicht daran gearbeitet die Software zu optimieren und effizienter zu machen.

Nicht falsch verstehen...ich finde 22MBit/s immer noch eklatant schlecht und ich würde, wenn es mein Netzwerk wäre, daran arbeiten, da einfach alle Geräte davon profitieren würden. Denn auch das wäre nur effizient wenn Geräte in meinem Netzwerk für Dateioperationen weniger Strom verbrauchen würden. Aber das ist ein anderes Thema.

Der Fakt, dass Kodi Probleme hat, VLC aber nicht und das bei gleichem Durchsatz ist nicht von der Hand zu weisen.

Ich stimme zu das "Fix dein Netzwerk" gleichbedeutend ist mit "wir brauchen mehr Ressourcen". Auch da habe ich nicht an "Optimierung" oder "Effizienz" gedacht. Die Backpfeife habe ich mir zu Recht eingefangen.

Wenn man jetzt das 80-20 Prinzip heran zieht (mit 20% Aufwand habe ich ein zu 80% "perfektes" Produkt. Um die letzten 20% zur absoluten Perfektion zu bekommen brauche ich 80% mehr Aufwand) und wir von OpenSource sprechen, ist es fraglich ob da noch jemand 80% Aufwand rein stecken möchte um die letzten 20% zu erreichen.

Da bei Kodi niemand Geld verdient muss es halt intrinsisch motiviert sein. Hat da keiner Bock drauf, dann wird sich auch nichts ändern.

Grundlegend spielen wir hier nur noch rum um Erkenntnisse zu liefern und dann vielleicht den Core-Entwicklern einen Hinweis zu geben. Das jetzt in ein Ticket zu gießen würde nur "hinten runter" fallen. Wenn man mit konkreten Erkenntnissen kommt weckt man vielleicht mehr Interesse.

Zitat von buers

ich hatte das vorher schon gesagt - ist für mich nicht plausibel, dass da Cache helfen kann.

Womit erklärst du es denn dann?

Ohne Anpassung ständiges buffern mit kein zwischen buffern oder ruckeln.

Ich hatte zwar kein jellyfin aber emby also wovon jellyfin kopiert wurde. Nutze auch direkt Pfad und smb Freigabe.

Ich habe das o.g. Addon genutzt was es alles einstellt keine Ahnung daher Versuch es doch auch Mal damit.

Weil wir dann mit Jellyfin noch eine weitere Komplexität mit ins Spiel bringen würden. Ich weiß nicht, wie hilfreich das ist, wenn sich Dinge bei Kodi ändern sollen. Wenn Jellyfin mit im Spiel ist, dann wird als erstes kommen "Bitte ohne testen". Denn das ist das worüber wir uns hier unterhalten. Es geht um den Unterschied von einem System-Mount im Vergleich zur SMB Implementierung von Kodi, Wenn wir ja jetzt noch Emby mit ins Spiel bringen, dann wird es nur noch unnötig komplexer.

Zitat von DayOne

Ich hatte zwar kein jellyfin aber emby also wovon jellyfin kopiert wurde

Und hier noch eine kleine Korrektur...Emby ist das original. Jellyfin ist die "Kopie"

About Jellyfin | Jellyfin

Jellyfin is a Free Software Media System that puts you in control of managing and streaming your media. It is an alternative to the proprietary Emby and Plex,…

jellyfin.org

Zitat von DaVu

Du sagst "bis 150Mbit/s ist alls im Lot". Und du hast damit auch Recht, dass kein UHD Film da ran kommen wird.

Nehmen wir aber jetzt mal den Fall an, dass es doch mal sein muss und dein Netzwerk gibt nicht mehr her...Und dann stellst du fest, dass ein anderer Player keine Probleme hat 200 oder sogar 250Mbit/s abzuspielen. Kodi bekommt das aber nicht hin. Warum auch immer.

Kodi nimmt das was es braucht, wie bereits geschrieben. Nicht jede Scene Brauch gleich viel Volumen, was auch klar ist. Wenn also so gut wie nichts im Cache landet und die ganze Zeit 8mb/s benötigt werden dann aber plötzlich 55mb/s benötigt werden und das Netzwerk nur 45mb/s schaft ruckelt es.

Und weiter?

Was hat das mit der Thematik zu tun? Das was du ansprichst ist VBR (Variable Bitrate). Unterschiedliche Szenen haben unterschiedliche Bitrate. Bei Kodi ruckelt es. Bei VLC nicht.

Und jetzt?

Zitat von DaVu

Und hier noch eine kleine Korrektur...Emby ist das original. Jellyfin ist die "Kopie"

Unnötige da ich es genau so geschriebene habe.

Zitat von DayOne

Ich hatte zwar kein jellyfin aber emby also wovon jellyfin kopiert wurde.

Zitat von DaVu

Bei Kodi ruckelt es. Bei VLC nicht.

weil der VLC Cache völlig anders funktioniert.

VLC versucht immer eine gewisse Zeit zu buffern, Kodi richtet sich aber nach Datenmenge.

Mein Senf:

(-: Vlt !?

liegts auch an der Verarbeitung des Codecs. (über Netzwerk)

Stimmt...da habe ich mich verlesen ;). Sorry

Zitat von DayOne

weil der VLC Cache völlig anders funktioniert.

VLC versucht immer eine gewisse Zeit zu buffern, Kodi richtet sich aber nach Datenmenge.

Korrekt. Hate ich ja auch schon geschrieben. Das ändert aber immer noch lange nichts am Fakt, dass bei gleichem Netzwerk und gleicher Verbindung offensichtlich das Handling des Caches bei Kodi schlechter zu funktionieren scheint. Denn das gleiche Video läuft unter VLC aber nicht unter Kodi.

Wobei man auch sagen muss, dass 1 Sekunde Puffer eher sehr relativ zur verwendeten Datenmenge steht. Wie gesagt, ist 1 Sekunde bei einer 50GB Datei mit 2 Stunden Laufzeit mehr Datenvolumen als bei einer 5GB Datei mit 2 Stunden Laufzeit.

Wenn also VLC es schafft die Datei ruckelfrei abzuspielen, obwohl VLC mit dem gleichen Netzwerk, der gleichen Art VBR und der gleichen Datei zu kämpfen hat wie Kodi auch...Warum ruckelt es dann bei Kodi? Das gilt es hier zu klären.

Nehmen wir mal das 50GB und 2 Stunden Laufzeit als Rechenbeispiel:

Um auf Megabyte zu kommen, rechne ich 50 * 1024 (51200). Um dann auf MB/s zu kommen rechne ich 51200 / 7200 Sekunden (7,11). Wir haben also durchschnittlich 7,11 MB, die pro Sekunde übertragen werden müssen, damit das Video sauber läuft.

Wenn der Durchsatz, bedingt durch die SMB Implementierung von Kodi, nur 7,5MB/s beträgt wird es bei Videos mit größerer Datenmenge und gleicher Laufzeit (also anderer und höherer Bitrate) schwer bis unmöglich....Zumindest für Kodi aber anscheinend nicht für VLC.

Und ein größerer Cache würde nichts bringen. Es würde nur bewirken, dass das Ruckeln später anfängt. Nämlich dann wenn der Cache leer gelaufen ist und nicht schnell genug gefüllt wurde.

Ich kann auch anders fragen warum bei VLC der Cache schneller gefüllt wird als bei Kodi obwohl das Netzwerk das gleiche ist

Du nimmst ein bsp. Was nicht auftreten kann. Der Film Brauch nunmal nicht permanent die gleiche Datenmenge sondern Mal mehr und Mal weniger. Da wo es dann weniger ist kann er sehr wohl problemlos schon Mal für später was Puffern.

Der maximale daten durchsatz wird bei VLC und Kodi der gleiche sein. VLC puffert nur mehr und hat dadurch ein höheren durchnit. Ob der VLC Puffer besser gelöst ist mit einer gewissen Zeit als Kodi mit einen gewissen Datenvolumen muss jeder für sich entscheiden. Aber was bei VLC flüssig läuft wird auch mit Kodi funktionieren.

Am optimalsten wäre für mich sowieso das, das Puffern erst nach den Start beginnt. Da wird aber wieder eine gewisse Netzwerkgeschwindigkeit vorausgesetzt. Ewig warten weil er erst (etwas Überspitzt) 2 Minuten bzw. 500mb speichern möchte, will ich ungerne.

Aber das war es auch zum Thema, wer meint Kodi kann das Video nicht flüssig abspielen was aber VLC kann so soll er ruhig der Meinung bleiben.