[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

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

    Im ffmpeg SW Deinterlacer gibt es ein Bug. Der PTS hat genau den doppelten Wert. Damit ist ein synchronisieren von Audio zu Video unmöglich. Wie alt ist Deine FFmpeg? Mit AW H5 und der aktuellen FFmpeg von LE gibt es diesen Bug nicht im HW Deinterlacer Filter.

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

  • 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.

  • 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...

  • Hi,

    Guck doch evtl mal in softhddrm...

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • 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...

  • Hi,

    Kann ich nichts zu beitragen.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Hi Andreas,

    hab mich jetzt mit dem Thema befasst und will meine Erkenntnisse Teilen. Wie ich das jetzt sehe gibt es zwei Möglichkeiten.


    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.


    Die zweite Variante ist die Renderxxx Datei zu öffnen und einen FB Rendern zu lassen. Der FB müsste dann von video_drm.c angezeigt werden.


    Dabei ist ein neues Problem hoch gekommen. Im Mainline Kernel ist zpos entfernt worden. Das patched LE momentan wieder ins Kernel rein. zpos wird benötigt um die Reihenfolge der planes fest zulegen. Das wird z.B. bei Allwinner benötigt da die primary plane nur ARGB kann und die yuv Formate auf der overlay plane. Um jetzt ein OSD darzustellen müssen beide planes vertauscht werden weil die primary plane sonst hinter der video plane liegt und nicht sichtbar ist. Dafür habe ich noch keine Lösung.


    Gruss

    zille

  • 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

  • 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...

  • Wow, vielen Dank rell


    Ich bin echt gespannt, hardware-beschleunigtes OSD auf den Arm-Kistchen wäre echt der Burner! :)