Beiträge von TomW

Nachtrag:

Ich habe nun mal "richtiges" 4K Material besorgt (gloriouspurpose), welches HVEC kodiert ist

Läuft: ohne Ruckler oder Aussetzer bei 4% CPU Last.

TV läuft bei 1080 auch ohne Ruckler oder Glitches.

Perfekt.

Aehm - vielen Dank.

Also: ich habe noch nichtmal einen 4K TV.

Das Abspielen des 4K Materials wurde allein zum Testen gemacht, um zu sehen wie der PI5 unter schwerer Last abschneidet.

Dabei gibt es viel Licht und wenig Schatten.

Alle _normalen_ UseCases laufen völlig problemlos. TV und Glotzen in HD ist kein Problem. Wenn ich die Temperaturen so ansehe, dann wird auch die passive Kühlung kein Problem sein.

Die HW Decodierung des NUC ist der SW Dekodierung des PI überlegen: das kann sich aber wieder ändern. Ich erinnere mich gut daran, dass Intel lange Zeit die OpenSource Treiber ignoriert hatte.

Trotzdem kann der PI5 momentan nicht den NUC verdrängen: meiner Tochter gefällt einfach die One-for-All FB viiel besser als die vom NoName TV.....

Zitat von HypsterX

Auch wenn du es anscheinend nicht hören magst, aber der PI5 ist nun mal als Mediaplayer denkbar schlecht geeignet.

Ja, da werde ich wohl doch lieber in einen alten NUC investieren.

Der widerrrum hat einige Vorteile des PI am TV nicht: man muss immer mit vielen FB hantieren. Ne, DingensHarmony ist mir viel zu teuer,

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".

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

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 Nico81

Wisst ihr, was ich tun muss, damit das Aufnehmen mit jedem beliebigen Nutzer geht?

Dem Nutzer unter "config / users / access entries" "Video Recorder" die notwendigen Rechte erteilen.

Ich finde ja immer den "View all" wichtig.

Zitat von Nico81

Möglichkeit 1 über "PVR IPTV Simple Client" und Möglichkeit 2 über "TvHeadend".

Ich habe 1 versucht - war nicht so toll. Seitdem über 2.

tvh ist der Single-POC und dahinter hängt z.B. DVB-C und/oder eine IPTV Octopus. Das hat den Vorteil, dass man dem Service verschiedene Quellen zuordnen kann (z.B. HD / IPTV HD / SD / IPTV SD ) , und dann mit den Prios das Verhalten steuert.

Hier wird dann auch deutlich, warum der tvhclient auf dem Kodi so geil ist. Der kann nämlich: Predictive tuning": während du durchzappst, wird vom tvh schon der nächste Kanal aktviert - der ist dann schon da, wenn du reintunst. (Boah - was für ein Denglischquark:)

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

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 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

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 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

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

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 joschi77

TomW vielleicht schaust du dir mal an, welche Codecs die einzelnen Files haben, denn der RPi 5 kann ja auch nur begrenzt 4K abspielen:

https://libreelec.tv/2023/09/28/rpi5-support/ -> "Media Decoding"

Dort steht :

"It no longer supports H264 in hardware. This might sound odd but it removes the RPi4’s 1080p restriction on H264 decoding and the 4K H264 test media we have has played."

Die files haben einen h264 codec bei einer 4K Resolution mit unterschiedlichen Bitraten.

Genau dieser UseCase sollte also völlig problemlos laufen - oder ?

Zitat von Raspi4Fan

Warum wieder nen Raspi? Weil mein Raspi4 seit über 3 Jahren mit Libreelec und aktuellen Kodi super läuft.

Bei uns läuft auch ein LE auf Raspi3 im lüfterlosem Geekdings seit Jahren völlig problemlos.

Um Missverständnissen vorzubeugen:

Auch der PI5 läuft mit LE (11 oder nightly) schon völlig problemlos.

Das Thema oben kommt aus einer Beobachtung beim Versuch, den PI5 an die Grenzen zu treiben......

Zitat von DaVu

Wenn sie von einem Samba-Share kommen, dann sind die Filme nicht "lokal". "Lokal" würde bedeuten, dass die Dateien auf dem Gerät liegen auf dem Kodi installiert ist.

Wenn du das MOV in ein anderes Format wandelst, geht es dann?

Thx für die Nachfrage.

Naja - lokal im eigenen Netz im Gegensazt zu "direkt aus dem Internet".

Das smb share liefert mit riesigem Mem über einen 1GB link aus und wird nur zu 20% ausgelastet.

Das kleine File mit 8GB ruckelt nicht. Allerdings sehe ich da deutlich geringere Datenraten als beim 20G .mov file (o-Taste zeigt : 40000 zu 103000 kb/s)

Bis jetzt sehe ich beim "grossen" File immer dann Aussetzer, wenn SW decoded wird:

Kodi auf Windows 7: HW - keine Aussetzer

LE auf Windows in VM: SW - Aussetzer

LE auf NUC: HW - keine Aussetzer

LE auf altem Laptop: SW - Aussetzer

LE auf PI5: SW - Aussetzer

Wenn ich jetzt mit Datenstrom an der Grenze des LANS oder der Platten wäre - OK.

Aber bei 10MB/s hätte ich keine Aussetzer erwartet.

(Ich wollte auch mal das 200G File testen - allerdings wird das nur mit 2,5 MB/s im DL angeboten.

Zitat von noob_at_pc

ja und wie spielst du das vid ab - runtergeladen? Welches format usw

Daher ein [definition='1','1']debuglog[/definition] erstellen (auf den Link klicken) und dann sieht man was wie wo warum passiert. Weniger raten

Also ich speichere die Files lokal ab - das sind mp4 und mov. Das kleine mp4 ist 8 G gross und das grosse .mov etwa 22G.

Nur das .mov ruckelt und auch nur auf dem pi5 und nicht beim alten NUC.

Ich habe alle files auf einem samba liegen und starte (von remote) mit

sshpass -p libreelec ssh root@$HOST 'kodi-send --action="PlayMedia(smb://192.168.1.7/Cams/SDO.mov,noresume)" ' > /dev/null

[definition='1','3']Debug[/definition]:

hastebin

mit der freundlichen Meldung, dass der cache completely reset wurde.

Zitat von noob_at_pc

was wie wo ist das Video File denn?

Ein [definition='1','4']Debuglog[/definition] täte auch helfen. Ggf. ist eine Einstellung die angepasst werden muss/kann.

THERMONUCLEAR ART – https://svs.gsfc.nasa.gov/12034/

Ich wollte nicht direkt mit Bug anfangen. Ich versuche immer, keine grossen Änderungen an den Systemen vorzunehmen, maximal "Passthrough". (Mache ich aber gerne - weiss auch wie).

Zitat von SkyBird1980

Wie ist dein Pi gekühlt?

Ertappt: ich habe ein script geschrieben, um Temperaturen unter Last einzusammeln. Das läuft auf jedem libreelec.

Dieser Pi wird aktiv gekühlt - ich sehe bei diesem 4K Video folgende Temperaturen

(in der 47-55ten Minute)

47 57850

48 58400

49 57850

50 57300

51 56750

52 56750

53 57850

54 58950

55 59500

Er throttled auch nicht: throttled=0x0

(Ohne Kühlung laufe ich schon bei HD TV gegen die 80 Grad und werde gebremst

Was ich sehe:

Ein 4Gen NUC (i3-4010U) spielt das 4K Video ohne Ruckeln oder Gemecker ab. Der Pi5 ruckelt und zeigt das gleiche Verhalten wie eine 15 Jahre alte DualCore CPU (T4500).

Beide RuckelKisten dekodieren in SW - der NUC in HW.