Sollte drin sein, ansonsten mach es gerne nochmal
[softhddevice-drm]
-
-
Hm, bei Nov 26 15:27:16 raspberrypi kernel: [ 8064.568030] [drm:drm_stub_open [drm]] gehts los und bis zum Ende sehe ich nur DRM_IOCTL_PRIME_FD_TO_HANDLE,DRM_IOCTL_MODE_ADDFB2,DRM_IOCTL_MODE_ATOMIC , was bei Video normal sein sollte.
Bin mir aber auch nicht sicher, ob der Fehler dort auftaucht, Sinn würde es aber machen, wenn der ioctl nicht klappt.
Vielleicht kannst du nochmal schauen, und mit dem Zeitstempel im syslog vergleichen. Danke!
-
So jetzt nochmal mit debug gestartet
-
Nochmal ich, vielleicht ist "1" zu wenig. Wenn du es noch mal mit "
echo 0xf > /sys/module/drm/parameters/debug"
versuchen könntest, wärs top. Dann belästige ich dich auch nicht mehr
Gruß
Andreas
-
Dann belästige ich dich auch nicht mehr
Scherzkeks. Am besten ich beschwere mich jetzt noch das du mir hilfst.
meld dich wenn es was zum testen gibt
jetzt noch mit0xf
-
rookie1 Bei mir auf einem pineh64b kommt folgendes sehr oft im log mit "echo 0xf > /sys/module/drm/parameters/debug":
Code
Alles anzeigen... Nov 26 16:10:49 pineh64-b kernel: [25396.985170] [drm:sun4i_crtc_atomic_flush] Committing plane changes Nov 26 16:10:49 pineh64-b kernel: [25396.985176] [drm:sun8i_mixer_commit [sun8i_mixer]] Update blender routing Nov 26 16:10:49 pineh64-b kernel: [25396.985182] [drm:sun8i_mixer_commit [sun8i_mixer]] Committing changes Nov 26 16:10:49 pineh64-b kernel: [25397.004781] [drm:drm_mode_object_put.part.3] OBJ ID: 50 (3) Nov 26 16:10:49 pineh64-b kernel: [25397.004794] [drm:drm_mode_object_put.part.3] OBJ ID: 53 (2) Nov 26 16:10:49 pineh64-b kernel: [25397.004881] [drm:drm_ioctl] comm="vdr" pid=2203, dev=0xe200, auth=1, DRM_IOCTL_MODE_ATOMIC Nov 26 16:10:49 pineh64-b kernel: [25397.004903] [drm:drm_mode_object_get] OBJ ID: 55 (2) Nov 26 16:10:49 pineh64-b kernel: [25397.004909] [drm:drm_mode_object_get] OBJ ID: 50 (2) Nov 26 16:10:49 pineh64-b kernel: [25397.004917] [drm:drm_mode_object_get] OBJ ID: 54 (3) Nov 26 16:10:49 pineh64-b kernel: [25397.004921] [drm:drm_mode_object_put.part.3] OBJ ID: 55 (3) Nov 26 16:10:49 pineh64-b kernel: [25397.004925] [drm:drm_mode_object_put.part.3] OBJ ID: 54 (4) Nov 26 16:10:49 pineh64-b kernel: [25397.004929] [drm:drm_mode_object_put.part.3] OBJ ID: 54 (3) Nov 26 16:10:49 pineh64-b kernel: [25397.004977] sun4i-drm display-engine: [drm:drm_calc_timestamping_constants] crtc 41: hwmode: htotal 2640, vtotal 1125, vdisplay 1080 Nov 26 16:10:49 pineh64-b kernel: [25397.004984] sun4i-drm display-engine: [drm:drm_calc_timestamping_constants] crtc 41: clock 148500 kHz framedur 20000000 linedur 17777 Nov 26 16:10:49 pineh64-b kernel: [25397.004999] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Updating VI channel 0 overlay 0 Nov 26 16:10:49 pineh64-b kernel: [25397.005005] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Layer source offset X: 0 Y: 0 Nov 26 16:10:49 pineh64-b kernel: [25397.005011] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Layer source size W: 1280 H: 720 Nov 26 16:10:49 pineh64-b kernel: [25397.005020] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] HW scaling is enabled Nov 26 16:10:49 pineh64-b kernel: [25397.005087] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Layer destination coordinates X: 0 Y: 0 Nov 26 16:10:49 pineh64-b kernel: [25397.005093] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Layer destination size W: 1920 H: 1080 Nov 26 16:10:49 pineh64-b kernel: [25397.005108] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Using GEM @ 0x00000000f0700000 Nov 26 16:10:49 pineh64-b kernel: [25397.005114] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Layer 1. line width: 1280 bytes Nov 26 16:10:49 pineh64-b kernel: [25397.005120] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Setting 1. buffer address to 0x00000000f0700000 Nov 26 16:10:49 pineh64-b kernel: [25397.005126] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Using GEM @ 0x00000000f0700000 Nov 26 16:10:49 pineh64-b kernel: [25397.005132] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Layer 2. line width: 1280 bytes Nov 26 16:10:49 pineh64-b kernel: [25397.005138] [drm:sun8i_vi_layer_atomic_update [sun8i_mixer]] Setting 2. buffer address to 0x00000000f07e1000 Nov 26 16:10:49 pineh64-b kernel: [25397.005144] [drm:sun8i_vi_layer_enable [sun8i_mixer]] Enabling VI channel 0 overlay 0 Nov 26 16:10:49 pineh64-b kernel: [25397.005151] [drm:sun4i_crtc_atomic_flush] Committing plane changes ..
-
Ok danke. Hilft leider nicht. Sehe nur den gleichen Fehler -22 (Invalid argument).
Irgendwas passt nicht mit drm und hängt damit zusammen, dass zpos beim RPI nicht geht. Ich muss da erst ein bißchen nachdenken und melde mich wieder
-
-
Hallo,
nachdem ich letztes Jahr das Plugin schon ausprobiert hatte, dann aber aus beruflichen und privaten Gründen keine Zeit für weitere Tests hatte, habe ich nun mal wieder meinen Banana Pi rausgekramt und das Plugin an einem Kabelanschluss getestet.
Als Kernel habe ich 5.10.61-gentoo (mit CONFIG_VIDEO_SUNXI_CEDRUS=y) und ffmpeg in der Version 4.4-r1 mit dem v4l2-request Patch verwendet.
Leider bekomme ich nur eine Diashow mit ca. allen 5 Sekunden ein Bild. Die CPU-Last ist <10%.
Wenn ich nun im alsamixer "Power Amplifier DAC" und "Power Amplifier Mute" aktiviere (siehe https://linux-sunxi.org/Audio_Codec#Troubleshooting) und den PA-Level hochdrehe, läuft das Bild wesentlich flüssiger, ruckelt aber immer noch (sowohl bei HD- als auch SD-Sendern) und die CPU-Last steigt auf ~150%.
Anscheinend erfolgt die Audio-Dekodierung in Software und überfordert der Banana Pi. Gibt es die Möglichkeit ein Dummy Audio Device einzurichten, um zu prüfen, ob die Video-Dekodierung überhaupt flüssig auf dem Banana Pi läuft?
Tonausgabe per HDMI (erfordert diesen Kernel-Patch) habe ich auch probiert. Hier sorgt das Starten des VDR aber dafür, dass das Audio Device verschwindet und der VDR-Prozess sich nicht einmal mehr mit kill -9 beenden lässt. Anbei das Log dazu (mit aktivierten DRM Debug-Meldungen).
-
Anscheinend erfolgt die Audio-Dekodierung in Software und überfordert der Banana Pi.
Das ist ein Klax für's BananaPi. Das wird nebenher mit Gähnen erledigt.
Hab gestern auch grad das Banana neu aufgesetzt. Das Problem liegt in fehlenden Patches und an der falscher Kernel Version.
FFmpeg braucht v4l2-drmprime, v4l2-request und diese ffmpeg Patches.
Das Kernel 5.15.5 benötigt die linux patches.
-
Hab gestern auch grad das Banana neu aufgesetzt. Das Problem liegt in fehlenden Patches und an der falscher Kernel Version.
Das Plugin läuft bei Dir sauber auf einem Banana Pi? Das klingt ja super.
FFmpeg braucht v4l2-drmprime, v4l2-request und diese ffmpeg Patches.
Das Kernel 5.15.5 benötigt die linux patches.
Die ffmpeg-Patches hatte ich zwischenzeitlich auch noch integriert - hat aber keine Besserung gebracht.
Ich versuche es dann mit einem neueren Kernel. Da ich den Kernel direkt auf dem Banana Pi kompiliere, kann ich frühestens morgen berichten
PS: Einer der ffmpeg-Patches hat bei mir zunächst für einen Fehler beim Kompilieren gesorgt (drm_fourcc.h wurde nicht gefunden). Es gibt die Datei ja zweimal. Einmal unter /usr/include/drm/ von den Kernel-Headern und unter /usr/include/libdrm/ von libdrm. ffmpeg-001-v4l2-drmprime.patch scheint beide Includes zu verwenden. Nach dem Setzen von USE=libdrm konnte ich ffmpeg erfolgreich kompilieren. Ich hoffe, das passt so.
-
Du kannst Dich daran orientieren:
[rockpro64] Ausgabe-Plugin softhddevice-drm - notwendige Schritte
-
Für den Fall, dass die Patches von LE noch nicht auf die verwendete Kernel-Version angepasst wurden, kann man das so selber machen. Wusste ich vorher nicht...
gentoo-vdr Hast du denn keine Möglichkeit, den Kernel woanders zu bauen? Da sitzt du ja ewig da
-
Danke Euch beiden.
Die Kernel-Patches habe ich einfach nach /etc/portage/patches/sys-kernel/gentoo-sources/ kopiert und dann den neuesten Kernel (5.15.6) installiert. Die Patches wurden problemlos angewendet.
Leider hat der neue Kernel auch keine Verbesserung gebracht.
Ich habe mir dann die verlinkte Anleitung angeschaut und festgestellt, dass es nicht ausreicht die Patches anzuwenden, sondern man diese auch im configure-Schritt aktivieren muss...
Also ffmpeg noch mal mit EXTRA_FFMPEG_CONF="--enable-v4l2-request --enable-libudev" installiert. Da es auch ein Update gab, habe ich es mit ffmpeg-4.4.1-r1 versucht. Leider funktioniert der Patch ffmpeg-001-v4l2-request.patch nicht mit Version 4.4.1, also habe ich den Patch angepasst und den Revert-Patch gleich integriert (siehe Anhang).
Danach habe ich noch mal VDR und das Plugin kompiliert, jedoch bekomme ich nun nur noch ein grünes Bild.
Ideen, was jetzt noch nicht passt?
-
Da wird igendwas zu irgendwas nicht passen. Ich lade mir immer LE runter und nehme die da angegebenen Versionen von Kernel und FFmpeg mit den dazu gehörigen Patches aus LE. Das hat immer funktioniert.
-
Ich lade mir immer LE runter und nehme die da angegebenen Versionen von Kernel und FFmpeg mit den dazu gehörigen Patches aus LE. Das hat immer funktioniert.
Ist hier auch so. Und wenn die kernel oder ffmpeg patches (noch) nicht zu den Versionen passen, kann man sie updaten wie oben geschrieben, damit “git am“ klappt.
Bei ffmpeg installiere ich übrigens keins von den Paketen aus der Anleitung. Meine config ist auch deutlich schmaler:
Code
Alles anzeigen./configure --prefix=/opt/prefix \ --pkg-config-flags=--static \ --extra-cflags=-I/opt/prefix/include \ --extra-ldflags=-L/opt/prefix/lib/arm-linux-gnueabihf \ --extra-libs='-lpthread -lm' \ --bindir=/opt/prefix/bin \ --enable-v4l2_m2m \ --enable-libdrm \ --enable-v4l2-request \ --enable-libudev \ --disable-vdpau \ --disable-vaapi \ --enable-neon \ --disable-libdav1d \ --enable-hwaccels
Wie zille schon geschrieben hat, kernel und ffmpeg muss zusammenpassen. Auch auf die header achten. Wenn man sich an LE hält, sollte es klappen.
... sollte als Kurzzusammenfassung eigentlich ausreichen. Die kernel config vor dem Bauen halt noch checken...
Gruß Andreas
-
Hallo zusammen,
ich nutze seit einiger Zeit nun den Pine H64 Modell B mit dem softhddevice-drm Ausgabedevice-Plugin.
CodeBBC World News Europe HD;SES ASTRA:11229:VC23M5O20P0S1:S19.2E:22000:2091=27:0;2092=@106:0:0:5001:1:1002:0 CNBC HD;SKY:12070:HC910M2O35P0S1:S19.2E:27500:2559=27:0;2563=eng@106:0:0:125:133:8:0
Ich habe hier zwei Sender (Astra 19.2°), welche sich aktuell nicht anzeigen lassen. Mit einem rpi3b+ funktionieren beide Sender.
Was wird benötigt (an logs oder eine kurze Aufnahme?), um diese beiden Sender mit dem softhddevice-drm zum laufen zu bringen?
GrußUwe
-
Bei mir funktionieren beide Sender auf AW Rockpro64. Schalt im Makefile mal DEBUG und CODEC_DEBUG ein. Mal sehen ob das was verät.
-
-
a/v start, no valid audio
Es wird kein Audiostream erkannt. Was sagt "ffmpeg -codecs | grep AC-3" ?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!