[softhddevice-drm-gles] Raspberry 4 und 5

Quote from rell

Kannst du mal schauen, ob es damit funktioniert?

ja super!

Quote from S:oren

Vermutlich einfach genau das, was da steht. Auf dem HDMI-Kabel kommt 24Bit-RGB an, was dann auch genau so dargestellt wird. Das Anzeigegeraet wandelt also das Bildformat nicht um, dass passiert schon in der HDMI-Quelle.

Das ist uebrigens auch genau das, was man haben will: Die Video-Plane (YUV) wird im Ausgabeprozessor (Hardware) in RGB gewandelt und dann dort mit dem RGB-OSD-Overlay zusammengemischt. So hat man keine Qualitaetsverluste, weil 24Bit-RGB das 'hoeherwertige' Bildformat ist im Verhaeltnis zu YUV mit 12Bit (4:2:0) oder 16Bit pro Pixel (4:2:2) - und YUV mit 4:4:4 entspricht (was niemand verwendet, weil der ganze Sinn von YUV ja eine relativ verlustarme Kompression ist). Ueber das HDMI-Kabel wuerde man YUV nur schicken, wenn man durch die geringere Anzahl von Bits/Pixel eine hoehere Aufloesung gerade noch so uebertragen kann und man zu Gunsten der hoeheren Aufloesung den Verlust an Farbqualitaet in Kauf nimmt.

In dieser Rechnung gehe ich von 8Bit pro Komponente aus ( R,G,B,Y,U,V), bei 10 oder 12 Bit pro Komponente sind es mehr Bits, das Verhaeltnis der Bits/Pixel bleibt aber gleich.

Gruss,
S:oren

Ich wollte das Thema Farbraum nochmnal hochholen. Mir ist aufgefallen, dass mein Receiver nur 4K an meinen TV überträgt, wenn ich per Tastenkombination den Receiver auf "HDMI enhanced" stelle. Nur dann kann der Receiver 4K in RGB weitergeben.

Das ist wohl auch das bandbreitenintesivste, was man so übertragen kann, da ja nicht komprimiert. Es wäre also eventuell eine Überlegung, die Übertragung in YUV 4:2:0 zu realisieren, da dann weder der Receiver noch das Kabel die höchste Bandbreite benötigen. Wenn man das überhaupt machen kann?!?

Das ist die Tabelle, die Onkyo dazu bereitstellt:

[Blocked Image: https://user-images.githubusercontent.com/222551/230801276-0920d324-8321-439d-9db1-9a9062d1c361.png]

Am besten wäre es natürlich, wenn man das im Setup konfigurierbar machen könnte:

Also Optionen für

- Auflösung / auto switch from source

- Refreshrate / auto switch from source

- Farbraum (RGB, YUV 4:2:2, YUV 4:2:0)

Ich weiß, ist mal schnell aufgeschrieben, umzusetzen ist das andere.

Das ist korrekt. Aber wie bereits angeboten, schicke ich Dir gerne einen von Amazon rüber:

https://amzn.eu/d/4gCpS05

Hallo,

ich habe heute das softhddevice aus dem git geladen und für meinen Raspberry Pi 2B gebaut, da ich dort auf Raspbian trixie umgestiegen bin.

Hatte schon keine Hoffnung das es damit überhaupt läuft, aber aktuell läuft es soweit auch mit dem vdr 2.7.7 zusammen, nur musste ich feststellen, dass ich einen ca. 1cm breiten Streifen am oberen Bildschirm habe welcher ganz schnell flimmert, ist aber nicht bei jedem Sender. Bin mir nicht sicher ob es das schon beschriebene Problem ist, weil OSD muss ich dazu nicht offen haben, habe schon Deinterlacer aktivieren und deaktivieren versucht, ändert aber daran nichts.

Weiterhin habe ich festgestellt, dass ich nicht nach jedem umschalten Audio ausgabe bekomme, sondern teilweise die Audioquelle im VDR wechseln muss oder noch mal hin und her schalten muss damit der Ton wieder kommt.

@bacardischmal wie hoch ist denn die CPU-Auslastung bei der Wiedergabe?

Gruß Fabian

Hello

Running the plugin just fine on my RPI4, this new version has lots of improvements and increased stabilty! Thanks for that.

One little thing: when I run ./vdr -V it segfaults:

./vdr -V

Segmentatiefout            ./vdr -V

This only happens when I have the lib "libvdr-softhddevice-drm-gles.so.9" in PLUGINS/lib

Showing the plugins parameters returns nothing with:

./vdr --help | grep softhdd

Is this reproducable for anyone?

Thanks for checking, I also couldn't get a useful back trace ..