[rkp]

Der Sender wird nicht angezeigt, obwohl er doch tagsüber frei anzuschauen ist.

Kann es sein, dass ich etwas falsch eingestellt habe?

Code: [Select]

Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] pes: Init: invalid video packet: 65529 232294 | 40
Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] pes: Init: invalid video packet: 6949 232294 | 40
Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] device: first valid video packet arrives 632ms after channel switch was triggered
Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] device: first valid audio packet arrives 1070ms after channel switch was triggered
Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] device: PlayAudio: new channel id 0xBD
Sep 19 17:05:33 MLD vdr[19872]: [19897] [softhddevice] videocodec: main: HEVC (High Efficiency Video Coding) (hevc) for codec "hevc" opened, using hardware decoding with 1 threads 🤩
Sep 19 17:05:33 MLD kernel: rpivid 1000800000.codec: rpivid_h265_start: (3840x2160)
Sep 19 17:05:33 MLD vdr[19872]: [19971] skindesigner: w 3840 h 2160 mode changed to 0
Sep 19 17:05:33 MLD kernel: rpivid 1000800000.codec: SPS changed
Sep 19 17:05:33 MLD kernel: rpivid 1000800000.codec: PPS changed
Sep 19 17:05:33 MLD kernel: rpivid 1000800000.codec: Missing DPB ent 0, timestamp=0
Sep 19 17:05:34 MLD kernel: rpivid 1000800000.codec: PPS changed
Sep 19 17:05:34 MLD vdr[19872]: [19897] [softhddevice] Add display mode change event to follow video mode 3840x2160@50,00
Sep 19 17:05:34 MLD vdr[19872]: [19878] [softhddevice] device: STATE MACHINE received DisplayChangeEvent
Sep 19 17:05:34 MLD vdr[19872]: [19878] [softhddevice] Set display mode: 3840x2160@50,00
Sep 19 17:05:34 MLD vdr[19872]: [19878] [softhddevice] ReInit requested display mode: 3840x2160@50,00
Sep 19 17:05:34 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:34 MLD vdr[19872]: [19878] [softhddevice] device: STATE MACHINE state change done in 107 ms
Sep 19 17:05:34 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:35 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:36 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:37 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:38 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:38 MLD vdr[19872]: [21626] animator thread thread ended (pid=19872, tid=21626)
Sep 19 17:05:38 MLD vdr[19872]: [19872] skindesigner: Osd deleted.
Sep 19 17:05:39 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:40 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:41 MLD vdr[19872]: [21625] [softhddevice] device: Clear:
Sep 19 17:05:41 MLD vdr[19872]: [21625] [softhddevice] videostream main: ClearVdrCoreToDecoderQueue: packets 0
Sep 19 17:05:41 MLD vdr[19872]: [21625] [softhddevice] device: FlushAudio:
Sep 19 17:05:41 MLD vdr[19872]: [21625] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Sep 19 17:05:41 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
root@MLD:~#


[franky]

Du könntest auch noch einen Astra SES UHD Testkanal ausprobieren, der auf jeden Fall nicht verschlüsselt ist.

Ich verwende meinen RPI5 nur gelegentlich zum Testen und habe da auch schon festgestellt, dass UHD-Decoding nicht funktioniert.
Ich bin mir aber nicht sicher, ob das UHD-Decoding mit softhddevice-drm-gles beim RPI5 jemals schon funktioniert hatte.
Dazu habe ich den RPI5 zu selten und dann nur für kurze Tests in Betrieb.

Produktiv verwende ich Systeme mit Intel-GPU bei denen ab der HD600 das UHD-Decoding einwandfrei funktioniert.
Bevorzugt verwende ich die stromsparenden GeminiLake Systeme (z.B. J4005, J4025 oder J5040) mit UHD600 bzw. UHD605 GPU.
Mein NUC7CJYHN2 mit J4005 verbraucht beim UHD-Decoding mit dem neuen vaapivideo Frontend nur ein paar Watt mehr als ein RPI5.
Und mein UHD-TV meldet dann sogar beim Decoding von UHD-Videos mit HDR dass er UHD mit HDR empfängt.
Dabei funktioniert sowohl die Anzeige-Einstellung FullHD 50Hz (also Downscaling) als auch UHD 50HZ (also Decoding und Ausgabe an HDMI in UHD) mit HDR.
Aktuell funktioniert HDR nur mit vaapivideo und auch nur mit einigen Intel GPUs ab UHD6xx.

Aber wie schon gesagt, ich kann mich nicht erinnern, das bei meinen RPI5 Tests schon mal UHD-Decoding funktioniert hatte.
Ich habe das aber nicht weiter hinterfragt, da ich ja mit den Intel-Systemen eine funktionierende Lösung habe, bei denen auch schon mit softhddevice das UHD-Decoding (halt noch ohne HDR) funktioniert hatte.

[rkp]

Ich habe auf einer SD-Karte VDR*ELEC installiert. Damit geht UHD1 by Astra problemlos.

Da ist irgendwas falsch konfiguriert in MLD.

[rfehr]

Hi rkp,

du könntest in der config.txt den folgenden Wert
dtoverlay=vc4-kms-v3d,cma-128
mal so ändern
dtoverlay=vc4-kms-v3d,cma-512

Gruß,
  Roland

[franky]

Hi Roland,

nachdem mein Test-RPI5 sowieso gerade gelaufen ist, habe ich das mit cma-512 gleich getestet.
Damit laufen bei meinem RPI5 UHD-Kanäle (Live-TV und Aufnahmen) wieder absolut flüssig.

Du lagst also richtig. Super!!

[rkp]

Vielen Dank, wieder ein Problem gelöst. Ergibt ein tolles Bild.

Allerdings frage ich mich, ob es mal einen Kanal geben wird, wo man das verwenden kann 🤔.

[neumann2k]

Hi rkp,

du könntest in der config.txt den folgenden Wert
dtoverlay=vc4-kms-v3d,cma-128
mal so ändern
dtoverlay=vc4-kms-v3d,cma-512

Gruß,
  Roland

Hatte ich bereits vor Monaten angeregt.

[clausmuus]

Ne, wenn ich mich richtig erinnere, ging es da noch um FHD Probleme mit cma-64. Da hatten wir den Wert von cma-64 auf cma-128 erhöht.
Unsere aktuellen Tests haben auch ergeben, dass cma-512 nicht für jede Hardware funktioniert, und auf manchen Systemen zu groß ist. Deshalb haben wir uns jetzt fürs erste auf den Defaultwert cma-320 geeinigt. Sollte sich herausstellen, dass auch dieser zu klein sein kann, werden wir den weiter anheben.

[neumann2k]

https://github.com/rellla/vdr-plugin-softhddevice-drm-gles

Code: [Select]

Hints for Raspberry Pi 4/5

It is highly recommended to use the kms driver with Raspberry Pi 4/5 and not the outdated fkms driver. Be sure you have the following dtoverlay activated in your /boot/config.txt:

dtoverlay=vc4-kms-v3d,cma-512
vc4-kms-v3d enables the new kms driver, cma-512 sets a custom cma size of 512MB. This is the recommended size. Only change it when you exactly know what you are doing.

[rfehr]

https://github.com/rellla/vdr-plugin-softhddevice-drm-gles

Code: [Select]

Hints for Raspberry Pi 4/5

It is highly recommended to use the kms driver with Raspberry Pi 4/5 and not the outdated fkms driver. Be sure you have the following dtoverlay activated in your /boot/config.txt:

dtoverlay=vc4-kms-v3d,cma-512
vc4-kms-v3d enables the new kms driver, cma-512 sets a custom cma size of 512MB. This is the recommended size. Only change it when you exactly know what you are doing.

Hi,

beim rpi4 geht das aber nicht immer, denn es gibt auf Modelle die weniger spreicher haben.
Wir haben jetzt bei

RPI5 cma-512 u.
RPI4 cma-320.

bei beiden ist getestet worden, das UHD funktioniert.

Gruß,
  Roland

[gustavgans]

https://github.com/rellla/vdr-plugin-softhddevice-drm-gles

Code: [Select]

Hints for Raspberry Pi 4/5

It is highly recommended to use the kms driver with Raspberry Pi 4/5 and not the outdated fkms driver. Be sure you have the following dtoverlay activated in your /boot/config.txt:

dtoverlay=vc4-kms-v3d,cma-512
vc4-kms-v3d enables the new kms driver, cma-512 sets a custom cma size of 512MB. This is the recommended size. Only change it when you exactly know what you are doing.

Hi,

beim rpi4 geht das aber nicht immer, denn es gibt auf Modelle die weniger spreicher haben.
Wir haben jetzt bei

RPI5 cma-512 u.
RPI4 cma-320.

bei beiden ist getestet worden, das UHD funktioniert.

Gruß,
  Roland

Hallo zusammen, drei Rückfragen:

1. 'Wir haben jetzt...' gilt doch bestimmt nur bei Neuinstallation, ich sollte also in 'meiner' config.txt die (in der noch cma-128 steht) cma-512 jetzt selber eintragen. Korrekt?
2. Es gibt ja RPi5's mit verschiedener RAM-Bestückung. Bei mir sind es 2GB und mit cma-128 und laufendem VDR nennt mir das WebIF bei 'System/Informationen' rund 650MB belegten Hauptspeicher. Somit sollte man erwarten, dass ein RPi5 mit nur 1GB RAM bei cma-512 Probleme bekommen dürfte. Korrekt? Dann wäre ein Hinweis zur Auswahl richtiger Raspis im Download-Bereich vielleicht angebracht.
3. Der RPi5 verwendet ja, soweit ich weiß, seine ARMe CPU als Softwaredekoder. Hat Jemand schon Erfahrungswerte, wie hoch die CPU-Last bei UHD-Inhalten ist? Bei mir meldet das WebIF als aktuelle Auslastung der vier Kerne mit HD-Auflösung 25..35%.

In diesem Zusammenhang noch eine OffTopic-Frage: Im WebIF wird ja neben der aktuellen CPU-Last auch die CPU-Last der letzten 1/5/15 Minuten angezeigt, da stehen hier Zahlen um 3,5 (%?). Das scheint auf den ersten Blick nicht recht zusammen zu passen. Wie entstehen denn diese diversen Werte?

[clausmuus]

1) Da es sich noch um eine frühe Testversion handelt, fügen wir kein automatisches Update der Einstellung hinzu. DU musst das also selber ändern
2) Ich hatte gar nicht mitbekommen, dass inzwischen auch der RPI5 als 1GB Version zu bekommen ist. Wir werden also besprechen, ob wir auch beim RPI5 den Vorgabewert auf cma-320 einstellen.

4) Was dort angezeigt wird ist der Load Average, also die durchschnittliche Auslastung des Systems über die letzten 1, 5 und 15 Minuten. Dies beinhaltet nicht nur die CPU Auslastung, sondern auch Festplatten Zugriffe, Netzwerk,...
Sofern nicht auf Festplatte, Netzwerk,... gewartet werden muss, sind bei einer 4 Kern CPU bei einem Load von 4 alle CPU Kerne voll ausgelastet, es muss aber noch nicht auf freie CPU Zeit gewartet werden.

[gustavgans]

1) Danke, somit weiß ich bescheid.
2) Als das RAM teuer wurde hat man den RPi5 auch als 1GB-Variante rausgebracht. Ich fände es gescheiter, die cma-512 zum Standard zu erklären, denn die MLD ist ja insgesamt UHD-ready, und dafür halt als Hardwareanforderung "ab 2GB" zu nennen. Mördermäßig wäre es, anhand der RAM-Bestückung (die ist ja der MLD bekannt) wahlweise mit cma-320 oder cma-512 an den Start zu gehen, wenn der Installer sowas kann. Ich könnte mir vorstellen, dass das nicht nur bei Raspis Sinn haben würde - so mancher lässt ja mit Absicht seine MLD auf Uralt-Hardware laufen.
3) Also die AvgLoad ist nicht in Prozent sondern ist eine absolute Zahl, die ich als "Anzahl voll beschäftigter CPUs (mit Rechnen oder Warten...)" verstehen kann. Könntest du im WebIF die BubbleHelp vielleicht dahingehend präzisieren?