Raspi 5 mit Kodi auf libreelec: ruckelt bei 4K

Zitat von te36

Mal geschaut, ob die Ruckler reproduzierbar auftreten ? Das würde dann darauf hindeuten, das das temporaere Überlastung im SW dekodieren ist, z.b. wenn da ein IDR FRame dekodiert wird.

Ansonsten auf jeden Fall Test wiederholden mit Abspielen von lokaler Platte. Kann einfach sein, das da irgendwelche Bufer fuers Netzwerk/SMB falsch dimensioniert sind.

Ja - ich sehe den Fehler reproduzierbar.

"lokale Platte" ist beim PI immer etwas schwierig.

Beim PI habe ich eine SD Karte und keine Ahnung, was die wirklich kann. Ich bin aber andererseits sicher, dass das SMB das file schnell genug ausliefert, denn die Büchse daneben (am gleichen GB Switch) ruckelt nicht. Wenn ich mit iptraf den Durchsatz auf dem Server ansehe, dann sehe ich, dass ich im Bereich von 20% Auslastung des GBit Interfaces bin. (Und der Server liest das file nichtmal mehr von Platte, sondern scheint aus dem Mem zu antworten

Eine "temporäre Überlastung im SW"- könnte sein. Denn der Ruckler tritt sicher auf , wenn das gesamte Bild wechselt.

Zitat von te36

Auf jeden Fall erst mal im Kodi 'O' drücken um dann zu sehen, wie hoch die CPU ist. Wenn da mal Last ueber 70% angezeigt wird, dann ist der RPI zu schwach. Selbst wenn die Last nie ueber 70% geht aber knapp darunter ist zu befuerchten, das es da mal kurze Last bursts gibt, zb. bei IDR dekodierungen. Wenn die Last noch geringer ist kann es evtl, wie oben gesagt, am schlechten Buffer management liegen, was man evtl. fixen kann.

Das ist ein interessanter Punkt !

Beispiel: FullHD (h264) vom tvh - gleicher Sender mit den Infos aus o:

Alter NUC mit HW Decode: System rendering Speed 60 fps - etwa 10% CPU auf allen Kernen

PI5 mit SW decode: System rendering Speed 15 fps - etwa 30% CPU auf allen Kernen

PI3 mit HW decoder: da habe ich ein anderes o menu - ich sehe bei den CPUs unter 10 %

hmmm.

Wenn ich das 4K / 20G File abspiele, dann sehe ich

- auf dem Pi5 bei top eine load > 4 und eine Auslastung einzelner CPUs im Bereich von 80% - stark schwankend bei 60 Grad. (Nicht gut ge-threaded)

- beim alten NUC (lüfterlos) eine load von 1 und 10% auf allen Cores (und 43 Grad).

Beide stehen bei 19Grad Raumtemp 40 cm entfernt.

Hmm - also trotz des grossen Entwicklungsaufwandes der neuen GPU scheint das HW decoding noch besser zu sein.

Zitat von te36

Für "lokale Platte" am RPI am besten den schnellsten USB Stick den Du hast in den RPI reinstecken, die sollte am besten mit ext4 formattiert sein (keine Ahnung ob LE da ein tool hat, ansonsten halt an einem anderen Linux Rechner),

mkfs.ext4 ist mein Freund...

(Das dauert aber noch: die server haben zwar GBIT Netz aber nur 2.0 usb....)

Zitat von te36

Wenn das video 60 fps hat und der PI5 da nur 15 fps rendert, dann solltest Du das aber auch kontinuierlich als nicht fluessige Bewegung wahrnehmen. Ansonsten konnte evtl. auch die 15 fps Anzeige nicht zuverlaessig sein.

Schalt auf jeden Fall mal in den settings die synchronisation mit dem display aus, so das das rendering nicht irgendwann aufs display wartet. und auch nicht aufs audio.

Momentchen - das finde ich unter Settings/Player/Videos bei Playback ?

Steht auf:

- Adjust display refresh rate: off

- Sync playback to display : ausgegraut

Zitat von buers

TomW, vielleicht willst du mal die Jellyfin Test Videos probieren. https://fra1.mirror.jellyfin.org/jellyfish/

In diesem ellenlangen Thread Videos ruckeln bei Bitrate > 60Mbps hatte ich Mal paar Messungen gemacht, und festgestellt, dass Kodi unter manchen Umständen einfach bei Weitem nicht die zur Verfügung stehende Bandbreite ausnutzen kann. Lag dort nicht an der CPU.

Den Thread hatte ich mir sogar angesehen, bevor ich gepostet habe.

Die Fischlein liegen schon auf Platte. Das HVEC (1,4GB) läuft auf dem PI5 flüssig , das h264 mit 800 MB nicht.

Allerdings muss ich einräumen, das sind wenige Minuten mit einem __für__mich__ schwierigem Inhalt: wenn

das Tintenfischlein zuckt, dann weiss ich nicht woher der Ruckler kommt....

Wenn ich einen Sonnenflare sehe, dann weiss ich wie der aussehen muss.

VLC: spielt mir von genau diesem share die h264 völlig problemlos alles ab (mit bitraten bis 112000kb/s). Dafür zickt das HVEC.

Zitat von te36

Alles Pfusch. Ich glaube ich pack die NASA, oder zumindestens die Jungs und Maedels die das 2015 gemacht haben in denselben Topf wie den WDR, der verhunzt immer Tatorte in der Mediathek.

....

Aber: ruckelt in beiden Faellen an reproduzierbaren Stellen, z.b.: bei ca. 16:26

Mal mit mediainfo geschaut, und da fiel mir das hier auf:

Frame rate : 59.940 fps

Original frame rate : 25.000 fps

Aka: ich denke mal die Ruckler sind im Material, und irgendein Anfaenger bei der NASA hat da eine merkwuerdige Konvertierung gemacht. Ich werd mal die 200GByte datei runterladen, vielleicht ist die in 25fps. 25fps ist ja man schon sowieso merkwuerdig fuer eine amerikanische Produktion.

...

Nachtrag: ruckeln noch mal validiert mit VLC.

Alles anzeigen

Die Ruckler, die ich meine, sind mit einer Unterbrechung des Audiostream verbunden - da steht das Bild kurz , oben kommt kurz der Laufzeitbalken und nach einer 1/10 Sekunde geht es weiter. So "Ruckler" wie bei 16:26 stören ja nicht.

Und: warum juckt den alten NUC mit HW decoding das nicht ?

Zitat von DaVu

Kann ich bitte mal ein [definition='1','1']debuglog[/definition] sehen, wenn du das MOV File abspielst?

Ignore me. Steht schon auf der ersten Seite

Edit:

Das hier wird das Problem sein:

Code

Stream #0:1[0x2](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 3840x2160 [SAR 1:1 DAR 16:9]

Es ist ein h264 mit 4k Auflösung. Siehe:

https://forums.raspberrypi.com/viewtopic.php?t=244005

Code

The H264 decoder only supports resolutions up to 1920x1080.

Und diese Frage:

Hast du noch nicht beantwortet, aber dafür auf jeden Fall recht viel anderes geschrieben

Aus dem gleichen Thread oben hier noch ein Zitat:

Code

Try it as an mp4.
ffmpeg -i your.mov -c:v copy -c:a copy new.mp4

Alles anzeigen

Die Restriktion des PI4 bzgl. der 1080 sollte doch beim PI5 nicht mehr gelten.

Nach dem Neuverpacken in mp4 sehe ich immer noch die Ruckler mit einem drop des Audiostream, es kommt kurz der Laufzeitbalken und dann geht es weiter.

Allerdings sind nun andere Fehlermeldungen im Log:

Statt "cache completely reset for seek to" sehe ich nun ein "CVideoPlayerAudio::Process - stream stalled".

Was ich seltsam finde: warum sind eigentlich die "seek-to-" Calls out-of-order ?

Also ich sehe im [definition='1','1']debuglog[/definition] immer ein "cache completely reset for seek to XYZ" .

Das XYZ springt aber munter hin und her - warum steigt das nicht stetig ?

Zitat von te36

Für "lokale Platte" am RPI

O.K - beim Abspielen vom Stick sehe ich ein Identisches Fehlerbild : Ruckler alle paar Sekunden.

Fehlermeldung:

2024-02-06 14:24:10.572 T:1155 warning <general>: OutputPicture - timeout waiting for buffer

2024-02-06 14:24:39.224 T:1156 info <general>: ProcessDecoderOutput: Changed max allowed Out-Of-Sync value to 49 ms due self-learning

2024-02-06 14:24:55.168 T:1156 info <general>: CVideoPlayerAudio::Process - stream stalled

2024-02-06 14:25:23.260 T:1156 info <general>: CVideoPlayerAudio::Process - stream stalled

2024-02-06 14:25:56.669 T:1156 info <general>: CVideoPlayerAudio::Process - stream stalled

2024-02-06 14:26:51.798 T:1156 info <general>: CVideoPlayerAudio::Process - stream stalled

2024-02-06 14:27:25.155 T:1156 info <general>: CVideoPlayerAudio::Process - stream stalled

Hmm - kennt jemand ein anderes freies _langes_ 4K Video ? (Mindestens 20 Minuten)

Zitat von derMaik

Schau mal ob du hier etwas findest.

https://opencontent.netflix.com/

Gibt da verschiedene Sachen, aber meist ohne Ton.

Vielen Dank ! Das hatte ich noch nicht gesehen.

Einziger Wehrmutstropfen : die DL Speed ist auf 2MB/s begrenzt.doof.

Zitat von te36

Ich bleibe bis zum Beweis des Gegenteils mal bei meiner Theorie, das die Abspielprobleme bei DIr was damit zu tun haben koennen, das die NASA Dateien verpfuscht sind.

Andere Samples hier: https://kodi.wiki/view/Samples Viel spass beim Suchen, was da lang genug ist.

Treten da bei Dir die Ruckler eigentlich nur auf, wenn Du das 14 Minuten lang laufen laesst, oder auch wenn du da hinzappst ? Aka: Vom Anfang an, wann tritt da der erste Fehler auf ? Evtl. muss eine Vergleichsdatei ja gar nicht so lang sein, sondern halt bloss e.g.: 100Mbps H264 haben.

Die Samples beim KodiWiki hatte ich schon mal durchgesehen: allerdings sind die meist nur wenige Minuten lang. Und für einen Lasttest damit wenig geeignet.

Bei mir treten die Ruckler auch auf, nachdem ich zappte - also mit Taste rechts,rechts,rechts irgendwo reinspringe.Es dauert einige Sekunden, dann kommt ein Ruckler und ein BufferError.

Beweis des Gegenteils:

Auf einem alten NUC mit HW Decoding in der Intel CPU gibt es keine Probleme.

Kleiner Nebenspass: ich hatte jetzt auch mal auf dem TV direkt Kodi installiert - das klappt mit tvh ganz gut. Bei den grossen videos bleibt der Bildschirm dunkel - und bei kleineren Dateien kommt sofort "too slow".