[softhddevice-drm]

Hallo zille,

ich habe hier ein Problem mit softhddevice-drm auf Allwinner H3. Seit https://github.com/zillevdr/vd…c74ca0ef46c94b47999e5c93f bekomme ich nur noch ein schwarzes Bild und das scheint an dieser Änderung zu liegen:

https://github.com/zillevdr/vd…4a0789dd34a21abaa7e1R1365

Wenn ich die Zeile wieder nach vorne schiebe, funktioniert es. Zumindest das Log wird nicht mehr mit "AudioEnqueue: start? in Rb 552ms to skip 0ms" Meldungen geflutet.

Was macht die Zeile bzw. kannst du dir das nochmal ansehen?

Danke und Gruß

Andreas

ffmpeg version d02898aed0-Kodi Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-6)
  configuration: --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-hwaccels
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100

Ich kann mal versuchen, ffmpeg zu aktualisieren, aber sollte bei 576i nicht der HW Deinterlacer einspringen?

Ok, wird wohl damit https://github.com/LibreELEC/L…oth-destination.patch#L90 zusammenhängen. Ich schieb die Zeile vorerst wieder zurück und besorg mir bei Zeiten ein neues ffmpeg.

Btw, am OpenGL/ES OSD bin ich dran Ich hoffe, ich bekomms in den nächsten Wochen soweit, dass es benutzbar ist. Die GL-Seite läuft, aber für den drm part könnte ich nachwievor Hilfe brauchen, wenn einer mit seiner Zeit nicht weiß wohin

Zitat von zillerbaer

Das klingt gut! Was brauchst Du für den drm Teil?

Ich habe das fertige OSD auf einem GL framebuffer bzw. einem GBM surface. Mir fehlt der Teil, wie ich das BO auf das drm plane bekomme. https://github.com/rellla/soft…englosd/commits/drm-gles2 ist der aktuelle Stand ohne drm Integration, https://github.com/rellla/soft…ommits/drm-gles2_UGLY_WIP mit zwei zusätzlichen richtig bösen und unfertigen commits um mich heranzutasten, aber das ist momentan mehr try&error und produziert teilweise noch segfaults...

Wenn sich jemand mit drm auskennt, für den ist es wohl relativ einfach, das einzubauen... Orientiert habe ich mich am kmscube Beispiel.

Zitat von zillerbaer

Das ist ein sehr beliebter Testcode. Welche Version nutzt Du da?

Ich habe ins aktuelle https://gitlab.freedesktop.org/mesa/kmscube/ geschaut, was da so gemacht wird. https://gitlab.freedesktop.org…/master/drm-atomic.c#L304 wäre wohl die Stelle, wo was gemacht werden muss.

Im Prinzip ist es

eglSwapBuffers()-> gbm_surface_lock_front_buffer()-> drm_fb_get_from_bo()/drmModeFB2AddWithModifiers()-> ? setze irgendwas ?-> drmModeAtomicCommit-> gbm_surface_release_front_buffer()

Aber so ganz habe ich es noch nicht verstanden

Und jetzt gehts halt darum, wo das am besten in softhddevice-drm eingebaut werden muss. Das Grundgerüst habe ich mal versucht zu erstellen...

Zitat von SurfaceCleanerZ

Hi,

Guck doch evtl mal in softhddrm...

Mfg Stefan

Danke, hab ich schon. Das Prinzip scheint das gleiche zu sein. Allerdings wird bei softhddrm das Video und OSD als texture in denselben framebuffer und damit auf dasselbe drm plane gerendert, sehe ich das richtig? Ich würde gerne dem Video und dem OSD jeweils ein eigenes plane gönnen. Aber ich habe das Gefühl, es fehlt nicht mehr viel...

Zitat von zillerbaer

Es wird /dev/dri/cardX geöffnet, die plane benutzt die video_drm.c als osd_plane gibt. Darauf wird dann gerendert und angezeigt. Ich weiss aber nicht ob beide cardX Dateien parrallel geöffnet und benutzt werden können.

Den ersten Satz versteh ich nicht

Unabhängig davon wird ja bereits ein EGL/GL Context erzeugt und die GPU rendert einen FB. Was fehlt, ist, dass der FB von video_drm.c angezeigt wird.

Einfachste Möglichkeit wäre, in VideoOsdDrawARGB nicht das argb zu kopieren sondern den FB zu mappen wie ich es in dem write_png-Schnipsel mache und statt des argb einfach auf buf_osd zu kopieren. Aber das ist ja nicht der Sinn der Sache.

Man dürfte keinen dumb_buffer für das OSD verwenden, sondern müsste mit Hilfe von gbm_surface_lock_front_buffer einen bo vom gbm_surface bekommen, mit dessen handle man dann mit drmModeAddFB2 einen FB erstellt.

Im Prinzip so ähnlich, wie das mit primedata schon gemacht wird.

Ich schau mir das nochmal an... und hoffe, ich liege nicht komplett daneben.

Gruß

Andreas

Zitat von zillerbaer

Sicher? Muss dazu nicht eine Device Datei der GPU geöffnet werden?

Ja, sicher. Ich weiß, ich habe vorher auch danach gesucht. Kann es sein, dass sich Mesa automatisch vom Kernel das richtige device holt?

Wenn du es probieren willst, sollte https://github.com/rellla/soft…englosd/commits/drm-gles2 funktionieren. Wenn du im Makefile WRITE_PNG setzt, sollten von OpenGL pngs vom OSD gemacht werden. Die Logs sollten auch entsprechend aussagekräftig sein.

Gruß Andreas

Zwischenstand, GL Osd klappt erstmal grundsätzlich.

Allerdings ist es hier auf dem H3 ziemlich langsam... Das muss ich mir nochmal anschauen. Ich vermute auch, dass ich meine GPU clk etwas höher setzen sollte

OsdClear geht noch nicht und Aufräumen muss ich auch noch, aber ich bin erstmal froh, dass was auf dem Display ankommt...