Aua
[softhddevice-drm-gles] Raspberry 4 und 5
-
-
spdif_sz = 61440 // 4*15360 siehe https://github.com/xbmc/xbmc/blob…kIEC61937.h#L22
Und spdif[3] = htole16(61424); oder so ähnlich.
-
neumann2k Danke für deine Pull requests... Wenns geht bitte die commits squashen und pro Thema wäre mir ein separater PR lieber.
Ich kann dir auch eine git-mini-Einführung geben, falls nötig...
-
Wenns jemand testet und Erfolg vermeldet, checke ich es ein .... https://github.com/rellla/vdr-plu…e/WIP/truehdV01
Nachtrag: Mich würds fast wundern wenn das klappt, kodi macht da noch etwas mehr Hokuspokus aussen rum...
-
Wenn rfehr es baut, teste ich direkt.
rell Was mir noch aufgefallen ist: Das Plugin gibt Video im Farbraum RGB aus, allerdings ist wohl YCbCr der Standard. Ich bin jetzt nicht so bewandert mit diesen verschiendenen Farbräumen, denke aber, dass die Ausgabe in YCbCr der richtigere, bessere Weg wäre. Ich bin auch nicht sicher, ob überhaupt das Plugin dafür verantwortlich ist, oder eher der Kernel DRM Treiber. Weißt Du mehr dazu?
-
Das Video ist auf einem NV12 drm layer, OSD auf einem ARGB layer. Der hardware decoder liefert ein hardwarespezifisches YUV-Format und das wandert so wie es ist an die Hardware. Lediglich beim software decoder wird yuv420 in nv12 gewandelt, aber da wird nur im Speicher verschoben. Umwandlungen von und nach RGB finden nicht statt.
Wie kommst du darauf, dass das Video RGB ist?
-
Wenn rfehr es baut, teste ich direkt.
rell Was mir noch aufgefallen ist: Das Plugin gibt Video im Farbraum RGB aus, allerdings ist wohl YCbCr der Standard. Ich bin jetzt nicht so bewandert mit diesen verschiendenen Farbräumen, denke aber, dass die Ausgabe in YCbCr der richtigere, bessere Weg wäre. Ich bin auch nicht sicher, ob überhaupt das Plugin dafür verantwortlich ist, oder eher der Kernel DRM Treiber. Weißt Du mehr dazu?
Um welche Änderung geht es denn ?
-
Wenns jemand testet und Erfolg vermeldet, checke ich es ein .... https://github.com/rellla/vdr-plu…e/WIP/truehdV01
Nachtrag: Mich würds fast wundern wenn das klappt, kodi macht da noch etwas mehr Hokuspokus aussen rum...
neumann2k habe es bei mir mal gebaut, jetzt bist du dran
-
mal eine Frage hast du auch einen odroid?
Ich habe bei mir zwar Ton u. OSD aber kein Bild.
Gruß,
Roland
-
Ja, habe ich. Aber schon länger nicht mehr probiert. Das letzte Mal gings aber noch. Mit mainline bzw. kernel/ffmpeg von LE. Ich kanns mal wieder probieren...
Falls du den odroid mit softhddevice-drm-gles testen willst, brauchst du zwingend gepatchtes ffmpeg und kernel.
-
Ja, habe ich. Aber schon länger nicht mehr probiert. Das letzte Mal gings aber noch. Mit mainline bzw. kernel/ffmpeg von LE. Ich kanns mal wieder probieren...
Falls du den odroid mit softhddevice-drm-gles testen willst, brauchst du zwingend gepatchtes ffmpeg und kernel.
ich nehme dafür immer das rpi-ffmpeg
-
Das müsste imho passen. Kernel?
-
Das müsste imho passen. Kernel?
Kernel ist 6.6.35
-
Ok. Die Chancen steigen, wenn du es so machst wie hier: https://github.com/LibreELEC/Libr…/package.mk#L19
mit den angegebenen patches inkl. https://github.com/LibreELEC/Libr…X/patches/linux
Leider ist da nichts upstream, was man braucht... Insbesondere die vdec patches inkl. https://github.com/LibreELEC/Libr…-P-B-FRAM.patch
-
Ok. Die Chancen steigen, wenn du es so machst wie hier: https://github.com/LibreELEC/Libr…/package.mk#L19
mit den angegebenen patches inkl. https://github.com/LibreELEC/Libr…X/patches/linux
Leider ist da nichts upstream, was man braucht... Insbesondere die vdec patches inkl. https://github.com/LibreELEC/Libr…-P-B-FRAM.patch
ich schaue mal
wir bauen die MLD 6.5 ja für einige Hardware
rpi2/3
rpi4/5
odroid
x86/x86-qemu
rock-pi
-
Das Video ist auf einem NV12 drm layer, OSD auf einem ARGB layer. Der hardware decoder liefert ein hardwarespezifisches YUV-Format und das wandert so wie es ist an die Hardware. Lediglich beim software decoder wird yuv420 in nv12 gewandelt, aber da wird nur im Speicher verschoben. Umwandlungen von und nach RGB finden nicht statt.
Wie kommst du darauf, dass das Video RGB ist?
Das sagt mein A/V Receiver. Siehe Bild.
-
Was heißt das RGB hier? Vielleicht soll es erstmal nur verdeutlichen, dass die Farbtiefe 8bit pro Kanal beträgt? Z.b. YUV 4:2:0? Das wäre schon richtig, denn 10bit sind es nicht. Das hat mit RGB oder YCbCr evtl. gar nichts zu tun?!
-
Was heißt das RGB hier?
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 -
Danke dir für die Erklärung!
-
Mittwochs machen wir hier immer einen VideoCall
kannst ja gerne mal vorbei schauen, ist dann glaube ich einfacher als alles immer zu schreiben
Aber heute ist der VideoCall ausgefallen? Wollte gerade mal vorbeischauen, ist aber offensichtlich keiner da, der mich reinlässt. Oder mache ich etwas falsch?
-
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!