[softhddevice-drm-gles] Raspberry 4 und 5

Quote from rell

Sobald neue hdr Daten kommen, setze ich den Farbraum hier auf full range. Vermutlich ist das falsch. jojo61 macht das auch nicht sondern setzt hier auf limited.

Ich habe zwar noch nicht verstanden, warum bei hdr der full range falsch ist, aber wahrscheinlich fehlt mir der Zusammenhang...
Ich ändere das mal, dann kannst du nochmal testen. Am besten wäre es, wenn rfehr den neuen hdr-rebased branch dafür nehmen könnte...

Kann ich gerne machen

Quote from rell

Den eac3 fix habe ich jetzt gleich noch mit rein, dann kann neumann2k das auch testen.

so ist gebaut

Quote from rell

Ich habe zwar noch nicht verstanden, warum bei hdr der full range falsch ist, aber wahrscheinlich fehlt mir der Zusammenhang...

Ich denke, es kommt darauf an, welches Endgerät verbunden ist. Full-Range sollte bei Monitoren gesetzt werden und Limited bei TV-Geräten. Der Standard sollte also Limited (16-235) sein. Und das unabhängig ob HDR oder non-HDR. Am Besten also eine Setup-Option einbauen. Ausgebagerät: Monitor = Full Range, Ausgabegerät: TV = Limited.

Quote from rfehr

so ist gebaut

Dankeschön. Ich teste heute Abend.

Quote from rell

Dr. Seltsam Vielleicht hast du ja die Möglichkeit, diesen Branch mal zu testen und mit den neuen Optionen zu spielen und zu versuchen, ein Log zu entlocken... Der versucht sich, deinem Problem zu nähern..

Kompiliert und getestet - leider gleiches Problem. Welche Logs sind wichtig?

Was mir auffällt: Der Sequence Start Code wird durch die byte-Folge 0 0 1 definiert. So prüft es auch jojo61 in softhdodroid:

		while (len--) {
			if (nalHeader[0] == 0 &&
				nalHeader[1] == 0 &&
				nalHeader[2] == 1) {

Die Google KI sagt, dass es auch 4 byte-Startcodes gibt, aber anscheinend kommen die in der Praxis bei DVB nicht vor.

Wenn ich Deinen neuen Code richtig verstehe, prüft Du jetzt zwar beide Varianten (3 und 4 bytes), aber weiterhin nur die letzte Stelle auf 1.
Kann es sein, dass es byte Folgen gibt, bei denen das 3. oder 4. byte zwar eine 1 ist, die aber trotzdem keinen Sequence Start Code darstellen?

Quote from Dr. Seltsam

Kann es sein, dass es byte Folgen gibt, bei denen das 3. oder 4. byte zwar eine 1 ist, die aber trotzdem keinen Sequence Start Code darstellen?

Die 0 0 1 ist wichtig. Da ich mich byteweise durch den stream hangele um die Startsequenz zu finden, ist es egal ob 0 0 0 1 oder 0 0 1 als Start gesendet werden. Im Stream selber ist 0 0 1 verboten.

Quote from rell

Dann hatte ich da einen Denkfehler. Ich habe den Range von HDR ein/aus abhängig gemacht. Ich speichere den Colorrange ab, bevor der erste modeset mit dem hdr blob gemacht wird. Dabei wird auf limited gesetzt. Beim Beenden von VDR wird der COLOR_RANGE wieder auf den ursprünglichen Wert zurückgesetzt.

D.h. die aktuelle Setup-Option könnte ich eigentlich unter der Voraussetzung weglassen, dass ein hdr modesetting vom Ausgabegerät ignoriert wird, wenn es damit nichts anfangen kann. Ist das in jedem Fall sichergestellt?

Ich weiß nicht, ob ich Dich richtig vestehe, aber die Einstellung der Range ist NUR abhängig vom angeschlossenem Bildschirmtyp. Monitore möchten gerne mit Full-Range befüttert werden und TVs mit Limited. Das hat erstmal gar nichts mit HDR zu tun. Also grundsätzlich muss der Benutzer dem VDR Plugin ja irgendwie mitteilen, an welcher Art von Bildschirm er angeschlossen ist. Das Plugin kann das ja nicht wissen.

Ich hab mich auch ein bisschen eingelesen, und jetzt kommen wir wieder zu dem Punkt, wo wir, so verstehe ich das zumindest, generell weg von RGB sollten. Insbesondere bei 4K60 und RGB sind wir außerhalb der HDMI Spezifikationen des RPI4, da die Bandbreite dermaßen hoch ist.

Wir sollten daher auf YCbCr 4:2:0 wechseln. Das soll über kms mit dem Paramter "output format" möglich sein.

Quote from rell

Das Plugin kann den aktuell im drm plane gesetzten COLOR_RANGE abfragen -> https://github.com/rellla/vdr-plu…evice.cpp#L1086

Woher der gesetzte Wert kommt, weiß ich nicht. Ob der Monitor/TV das als Standard über die EDID angibt, keine Ahnung...

Ich frage mich, ob man an diesem gesetzten Wert überhaupt etwas ändern soll/muss. Bei jojo61 und jetzt auch bei mir wird limited forciert, sobald der erste hdr kommt, wenn ich es richtig verstehe.

Ja, korrekt. Der abgefragte Wert kommt sehr wahrscheinlich von der in der config.txt angegeben Werte.

Aber limited sollte auch für non-HDR gesetzt werden. Es sei denn, jemand betreibt das Plugin an einem PC-Monitor.

EDIT: Ich könne natürlich in der config.txt folgendes setzen:

## hdmi_pixel_encoding
##     Force the pixel encoding mode.
##     By default it will use the mode requested from edid so shouldn't
##     need changing.
##
##     Value    Description
##     -------------------------------------------------------------------------
##     0        Use EDID provided values (Default)
##     1        RGB limited   (16-235)
##     2        RGB full      ( 0-255)
##     3        YCbCr limited (16-235)
##     4        YCbCr limited ( 0-255)
##
hdmi_pixel_encoding=1

Standard wie beschrieben kommt per EDID vom Gerät. Daher passt auch der Kontrast bei non-HDR Inhalten aktuell, da Du ja den gesetzten Wert abfragst.

Das ist jetzt natürlich eine Frage der Interpretation, wie man das Ganze umsetzen möchte. Mein Verständnis ist folgendes:

Das Plugin ist DAS Ausgabe-Device und sollte daher auch alle Möglichkeiten haben (und hat es ja auch per kms) die Auflösung, Farbraum, Wiederholfrequenz etc. zu setzen. Ich hatte das ja schon mal geschrieben, aber meiner Meinung nach muss in das Setup auch Optionen zum Setzen der Auflösung, Wiederholrate, Farbraum etc. So wie es bei jedem Consumer-Gerät üblich ist. Just my 2 cents.

Quote from rell

das habe ich nicht, aber worin äußert sich dieses Problem, falls es eines gibt:

Teure Kabel nötig bei langen Wegen, nicht jedes Gerät unterstützt 4k60 in RGB. Bei meinem Onkyo Receiver musste ich erst den Modus per "geheimen" Menü aktivieren.

## hdmi_pixel_encoding
## Force the pixel encoding mode.
## By default it will use the mode requested from edid so shouldn't
## need changing.
##
## Value Description
## -------------------------------------------------------------------------
## 0 Use EDID provided values (Default)
## 1 RGB limited (16-235)
## 2 RGB full ( 0-255)
## 3 YCbCr limited (16-235)
## 4 YCbCr limited ( 0-255)
##
hdmi_pixel_encoding=3

Ich teste heute Abend einmal diesen Eintrag in der config.txt.

Nach meinem Verständnis sollte das Plugin ja diesen Zustand übernehmen. Dann schaue ich mal am TV, was dort ankommt.

Quote from rell

Jetzt könnte man sagen, der TV kann UHD und wenn vom VDR UHD kommt schaltet der in seine UHD-Auflösung, wenn HD kommt, schaltet der TV in HD-Auflösung. Kann der TV das besser?

Das ist EXAKT das, was ich meine. Und ja, der TV kann das besser. Wird z.B. beim Apple TV so gemacht (was nachweislich der Goldstandard in Audio/Video Processing ist) inkl. Bildwiederholrate.

Quote

Wiederholrate: Bisher kenne ich DVB-S nur mit 50Hz, daher ist das aktuell der Standard (der aber angepasst werden kann). Hier kann man überlegen, die Wiederholrate anzupassen, wenn anderes Quellmaterial vorliegt (aber wenn dann automatisch).

Denk an MKV oder andere Mediendateien, die jemand über den Medienplayer abspielt. Alles, was von Bluray kommt und in einer MKV liegt hat 24fps.

Quote

Das mit den YCbCr 4:2:0 habe ich noch nicht verstanden. Was wäre das für ein Output Parameter? Mit drm prime werden die Daten so wie sie der Dekoder liefert auf ein drm plane gelegt, das evtl. noch bestimmte modifier hat. Das Plane für Video ist schon ein NV12 plane und kein RGB. Osd ist ARGB. Oder meinst du was anderes?

Ich teste heute Abend einmal, was die Änderung am Farbraum in der config.txt bringt. Dort stelle ich mal auf YCbCr und gucke, ob das Plugin das übernimmt (sollte es ja).