Raspberry Pi 4B Unterstützung

Zitat von jsffm

Bei mir funktioniert es jetzt wieder nachdem ich diese Änderungen wieder zurückgeschraubt habe.

Ich habs jetzt mit dieser /boot/config.txtam Laufen.

Meine unfundierte Meinung ist, dass die Speicheraufteilung (gpm_mem und cma-xxx) wichtig ist.

Aber Achtung: Wenn gpu_mem ist groß ist, bootet der Raspberry nicht mehr.

# See /boot/overlays/README for all available options

initramfs initramfs-linux.img followkernel

dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=up,rc-map-name=nec

gpu_mem=320
dtoverlay=vc4-kms-v3d-pi4,cma-512
dtoverlay=rpivid-v4l2
disable_overscan=1
disable_fw_kms_setup=1
hdmi_pixel_encoding=2
max_framebuffers=2

#dtparam=audio=on
#dtoverlay=vc4-fkms-v3d

Zitat von CKone

so, hab jetzt in yavdr-ansible Bild auf dem rpi4b, Ton tue ich mich noch schwer.

auf welcher Basis debian / ubuntu 32/64 Bit ?

Danke

catatho

ubuntu focal 32Bit, mittlerweile hab ich aber auch Ton

Zitat von jsffm

Bez. 6 Kanal Audio, es wäre interessant zu wissen, ob Librelec Passthrough beim Pi4 beherscht, denn dann würde das Mapping wohl stimmen.

Kannst du doch mal testen.

Gruß,

Roland

Wenn ich das richtig sehe, ignoriert der derzeitige Code den 2. Connector (der hat bei mir die richtigen Modes).

Folgender patch sollte helfen:

index 73a6491..d5ad217 100644
--- a/video_drm.c
+++ b/video_drm.c
@@ -502,9 +515,9 @@ search_mode:
                        }
                }
                drmModeFreeConnector(connector);
-               if (!render->mode.hdisplay || !render->mode.vdisplay)
-                       Fatal(_("FindDevice: No Monitor Mode found! Give up!\n"));
        }
+       if (!render->mode.hdisplay || !render->mode.vdisplay)
+               Fatal(_("FindDevice: No Monitor Mode found! Give up!\n"));
 
        // find first plane
        if ((plane_res = drmModeGetPlaneResources(render->fd_drm)) == NULL)

Das ist richtig. Es wird momentan nur der erste Connector benutzt. Raspi4 ist das erste Board mit 2 HDMI Anschlüssen. Das ist aber nur dann wichtig wenn an dem zweiten Abschluss noch ein Monitor hängen soll. Sonst braucht nur der erste Anschluss benutzt werden. Mit der Änderung das 60Hz Modes unterstützt werden würde dann aber der falsche Monitor erkannt und benutzt. Wie ist Dein Setup? Das muss ich noch mal genauer durchdenken.

Zitat von zillerbaer

Wie ist Dein Setup?

Ein Fernseher an HDMI2 angeschlossen, HDMI1 frei.

... und warum benutzt Du nicht einfach den anderen HDMI?

HDMI1 ist doch der, den man normal immer nimmt

Zitat von jsffm

6 Kanal geht mit dem neueren Audio-Treiber, aber das Mapping stimmt noch nicht, da muss noch was angepasst werden, z.B. im Alsa.

da gab es früher schon was bei softhddevice und alsa beim 6 Kanalton, da kam beim Downmix kaum Sprache weil die hinteren und vorderen Kanäle vertauscht waren.

Das haben wir dann immer so betrieben:

http://www.vdr-wiki.de/wiki/in…Softhddevice-plugin#Audio

das wird hier nichts zur Lösung beitragen aber vllt ist es die gleiche Ursache wie dein Problem.

Die Vorschläge von amair und nafets227 sind umgesetzt.

Zitat von zillerbaer

... und warum benutzt Du nicht einfach den anderen HDMI?

Hat keinen Grund. War einfach Zufall, daß ich den zweiten HDMI genommen habe, ist an meinem Gehäuse nicht beschriftet.

Hallo zillerbaer,

Zitat von zillerbaer

Der Aufwand wäre recht groß und es betrifft nur alte Mpeg Formate. Vielleicht später mal wenn Zeit ist.

Kann leider nicht beurteilen, wieviel Aufwand das ist. Ich weiß auch nicht, ob ich da behilflich sein kann. Jedoch habe ich noch mehrere alte Aufnahmen, die noch 4:3 sind. Die werde ich mir sicher nicht in die Breite gezogen anschauen.

Was mir dazu auch noch einfällt: das Plugin sucht sich einmal am Start den TV-Modus, den es verwendet. Das heißt , dass das Plugin SD auf HD skaliert, oder? Und dann skaliert der TV ggf. HD auf UHD, richtig? Gut, wenn das Plugin nun UHD verwendet, dann hätte man nur einmal skalieren. Wäre es nicht besser, nur dem TV das Skalieren zu überlassen? Ich weiß nicht, wie gut der Raspi das kann, aber gute Fernseher sollten das doch besser können, oder nicht? Oder ist der Widerspruch hier "Raspi an gutem Fernseher"?

Auf was ich hinaus möchte: kann das Plugin nicht den TV-Modus verwenden, der am besten zum abzuspielenden Video passt?

Zitat von zillerbaer

Das liegt am Pixelformat das Raspi nutzt. Auf Rockchip und Allwinner ist das nicht der Fall. Ich würde erst mal abwarten ob das noch angepasst wird. Am TV kann das weg geschnitten werden.

Am TV habe die grünen Balken links und rechts auch, außer es wird HDready dargestellt. Mal kurz gezappt: ARD, ZDF, BR sind OK, Sat.1 nicht.

Hat sich das vom Raspi 2 auf 4 geändert? Mit Raspi2 hatte ich das noch nie, läuft aber mit KODI als VNSI-Client.

Gruß

Andreas

Zitat von amair

Kann leider nicht beurteilen, wieviel Aufwand das ist. Ich weiß auch nicht, ob ich da behilflich sein kann. Jedoch habe ich noch mehrere alte Aufnahmen, die noch 4:3 sind. Die werde ich mir sicher nicht in die Breite gezogen anschauen.

Das Bild kommt in 720 x 576 heißt 16 : 9. Das müsste skaliert werden auf 4 : 3 und dann müßte rechts und links noch schwarz eingefügt werden. Da habe ich momentan noch keine Idee wie man das Umsetzen kann.

Zitat von amair

Was mir dazu auch noch einfällt: das Plugin sucht sich einmal am Start den TV-Modus, den es verwendet. Das heißt , dass das Plugin SD auf HD skaliert, oder? Und dann skaliert der TV ggf. HD auf UHD, richtig? Gut, wenn das Plugin nun UHD verwendet, dann hätte man nur einmal skalieren. Wäre es nicht besser, nur dem TV das Skalieren zu überlassen? Ich weiß nicht, wie gut der Raspi das kann, aber gute Fernseher sollten das doch besser können, oder nicht? Oder ist der Widerspruch hier "Raspi an gutem Fernseher"?

Auf was ich hinaus möchte: kann das Plugin nicht den TV-Modus verwenden, der am besten zum abzuspielenden Video passt?

Es wird eine Mode gewählt und alles auf die Mode skaliert. Wenn verfügbar wird HD gewählt. Mit UHD Mode wird aktuell noch nicht gearbeitet. Wird ein UHD TV genutzt skaliert der TV dann auf UHD hoch. Wenn eine SD Mode verwendet werden würde, wäre auch das OSD in SD. Das hochskaliert kann man sich nicht ansehen, sieht furchtbar aus. Den Umgang mit UHD müsste man sicherlich zwei geteilt machen. Einmal eine Mode HD und darunter und einmal UHD. Dann weiß ich aber noch nicht wie schnell ein OSD in UHD gezeichnet wird. Da ist vielleicht erst einmal GL OSD wichtig. Die Prio ist aber momentan nicht hoch. Wie gesagt, es gibt erst Testsender und mein TV muß auch noch kaputt gehen.

Die grünen Streifen sind bei SD Material. Der SW Decoder und Deinterlacer gibt YUV420 aus. Das wird zu NV12 kopiert. Das Raspi2 hat das in HW decodiert und deinterlaced und das interne Pixelformat genutzt. Ich habe schon gesucht aber nix gefunden das besser machen zu können. Eventuell findest Du ja was.

Ich lasse jetzt ffmpeg die Konvertierung von yuv420 zu nv12 machen. Damit sollten die grünen Ränder bei SD weg sein.

Edit: Vielleicht kann ffmpeg auch die Konvertierung von 4:3 zu 16:9?