softhdcuvid/softhdvaapi/softhddrm with hevc and UHD

  • Hi jojo,


    ich hatte auf der NVidia-Homepage das Ubuntu-Package gewählt und bin nach einem Tutorial aus dem Netz vorgegangen. Dort wurden explizit die Samples mit installiert. Ich habe die nun mal weggelassen und etwas Platz auf der Platte gemacht. Aber ca. 3,9 GB wollte das Setup immer noch haben die letztendlich aber nicht belegt wurden. Ich vermute mal nur temporär zum entpacken und installieren.


    Nun meckert dein Plugin gerade, dass es die libswscale nicht findet, die ist aber da, mal gucken wo es da nun hängt.


    Wie ist denn die Mindestanforderung an ffmpeg, ich habe derzeit eine selbstcompilierte 3.3.6, sollte das eher 4.0.2 sein ?


    Gruss


    Stefan

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • Hi,


    jetzt habe ich ffmpeg 4.0.2 und das Plugin compiliert bekommen. Beim starten gab es dann immer eine Fehlermeldung, shared object File libcudart.so.9.2 konnte nicht gefunden werden oder so ähnlich.


    ich habe dann den Pfad exportiert wo die lib liegt


    export LD_LIBRARY_PATH="/usr/local/cuda/lib64/"


    danach wurde mir beim ausführen von ldd auch alles korrekt angezeigt


    ldd libvdr-softhdcuvid.so.2.4.0

    Code
    libcuda.so.1 => /usr/lib/x86_64-linux-gnu/libcuda.so.1 (0x00007f0b5744c000)libcudart.so.9.2 => /usr/local/cuda/lib64/libcudart.so.9.2 (0x00007f0b571e2000)libnvcuvid.so.1 => /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1 (0x00007f0b56d83000)


    Die Fehlermeldung beim starten blieb aber. Ich habe dann einen Link in /usr/lib auf die angemeckerte lib in /usr/local/cuda/lib64/ erstellt. Wenn ich nun aber den VDR starte, startet er mehrmals neu, meckert nicht mehr wegen der fehlenden Lib aber im Log steht sowas


    Kann es sein, dass meine Grafikkarte zu alt ist und Cuda nicht voll unterstützt wird, es ist eine GeForce GT 520 ? Bei den Spezifikationen bei NVIdia war aber etwas von Cuda aufgeführt.


    Oder war vielleicht das anlegen des Links in /usr/lib nach /usr/local/cuda/lib64/ zur libcudart.so.9.2 nicht so sinnvoll ?


    Gruss


    Stefan

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • Hi nochmal,


    das mit shared object File not found bezüglich der libcudart.so.9.2 hab ich lösen können. Habe den von mir angelegten Link wieder entfernt und


    ldconfig /usr/local/cuda/lib64


    ausgeführt. Ich hatte den Pfad /usr/local/cuda/lib64 zwar in ld.so.conf und dann ldconfig ohne weitere Parameter aufgerufen und dachte, damit wird das Verzeichnis dann mit genutzt. :/


    Egal nun wird die Lib ganz normal gefunden, das Problem mit can't open video codec! bleibt allerdings.


    Hier nochmal ein etwas ausführlicheres Log mit den Einträgen von softhdcuvid:


    Was kann ich nun tun ?


    Gruss


    Stefan

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • Kann es sein, dass meine Grafikkarte zu alt ist und Cuda nicht voll unterstützt wird, es ist eine GeForce GT 520 ? Bei den Spezifikationen bei NVIdia war aber etwas von Cuda aufgeführt.

    Ja, die Karte beherrscht prinzipiell Cuda, hat aber hat keinen passenden Videodecoder - laut https://developer.nvidia.com/v…decode-gpu-support-matrix geht das erst ab einer Geforce 630 (mit Kepler Chipsatz).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • Hollywood tja die Karte scheint mir zu alt zu sein. Ich denke um das Plugin sinnvoll zu nutzen ist eine GTX 10x0 notwendig. Ab da geht dann alles incl. UHD mit dem CUDA decoder.


    Ich habe noch einen Fix für SD Video eingecheckt. Da wäre mir Feedback ganz recht.


    mfg

    jojo61

  • SD funktioniert! Damit sind wir einen großen Schritt weiter! :tup


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ich habe das Plugin gerade mal unter Ubuntu 18.04 gegen das cuda-toolkit und ffmpeg 3.4 aus den Paketquellen gebaut.

    Die Reihenfolge der Argumente in https://github.com/jojo61/vdr-…blob/master/Makefile#L250 passt so nicht, der Linker erwischt auf meinem System nur dann alle Symbole, wenn man $(OBJS) und $(LIBS) vertauscht:

    Code
    $(CXX) $(CXXFLAGS) $(LDFLAGS) -shared $(OBJS) $(LIBS) -o $@

    Mein Testsystem hat eine GT 1030, mit LCARS als Skin läuft das auf den ersten Blick gut mit DVB-T2 und DVB-C in SD und HD.

    Mit dem Skindesigner scheint das skalieren den Videobild bei offenem Hauptmenü des OSD noch nicht zu klappen, das OSD wird dabei zu klein gerendert und das Bild nach unten versetzt angezeigt und der Übrige Hintergrund flackert mit den letzten Frames vor dem öffnen des Menüs, im Log sieht man dabei Meldungen wie video/glx: osd upload 921x177+922+769 1ms 652068 durchrauschen und wenn man das Menü zu lange stehen lässt, wird einige Sekunden später alles schwarz und man sieht bis zum Neustart des X-Servers kein Bild mehr, auch wenn man den VDR neu startet.


    PS: da man libnvidia-decode-390 aus den Ubuntu restricted Paketquellen zum erfolgreichen Linken braucht, ist es nicht so einfach ein Paket für das Plugin in Launchpad PPAs zu bauen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moin,


    könntest du dir vorstellen, das hardwarebeschleunigte OSD einzubauen?


    Siehe https://github.com/louisbraun/softhddevice-openglosd


    Ich habe mich zwar nicht in die Cuda API eingelesen, aber theoretisch sollte es relativ einfach auf deine Umgebung portierbar sein. Ich rendere offscreen per OpenGL auf ein OpenGL Surface und gebe das dann per OpenGL / VDPAU Interop als VDPAU Surface aus. Ähnliches sollte doch mit Cuda auch machbar sein, womöglich sogar direkter...


    Unterstützung kann ich dir leider keine anbieten, da ich aktuell weder eine passende Grafikkarte noch eine Entwicklungsumgebung aussen herum habe ;) Aber ich würde natürlich gerne auf Fragen deinerseits bzgl. des Codes eingehen.


    Wäre cool, wenn du Lust hättest, dir das mal anzuschauen :)


    Ciao Louis

  • Hollywood tja die Karte scheint mir zu alt zu sein. Ich denke um das Plugin sinnvoll zu nutzen ist eine GTX 10x0 notwendig. Ab da geht dann alles incl. UHD mit dem CUDA decoder.


    mfg

    jojo61

    Tja schade, mein Grundgedanke war eigentlich in Zukunft eine aktuelle FFMpeg-Version nutzen zu können. Soweit ich das hier gelesen habe wird vdpau ja von den aktuellen Versionen nicht mehr unterstützt. Kodi verlangt auch eine 4.x um nicht die interne nutzen zu müssen und so wollte ich mal probieren wie weit es schon läuft.


    Dann wird´s wohl Zeit für was neues, das hatte ich wegen UHD eh mal vor. Ich wollte dem VDR, wie scheinbar viele in letzter Zeit nicht den Rücken kehren, bin mir aber nicht sicher was hier die beste Lösung für mich ist. Neues Board mit aktueller Intel-Grafik und vaapi, ich brauche aber 2 PCI und 1 PCIe Steckplatz für meine DVB-S2-Karten, oder meinem vorhandenes System nur eine neue NVidia-Grafikkarte gönnen ? Was neues stromsparenderes wäre mir eigentlich lieber, da das jetzige System 80-100 Watt nimmt. Wenn da jemand einen Tip hat ? Aber vermutlich besser in einem neuen Thread.


    Gruss


    Stefan

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • Aber das jetzige OSD wird auch schon mit opengl gemacht.

    Wir reden von zwei unterschiedlichen Sachen: bei dir wird bei der Ausgabe des OSD die komplette Surface per CPU im Hauptspeicher gerendert, dadurch entsteht z.B. im Falle von UHD ein 4096 × 2048 großes Array aus 32bit ARGB Werten. Das sind dann pro Surface ca. 32 MByte an Daten, die du aus dem Hauptspeicher per OpenGL auf die GPU transferierst.


    Das OpenGL OSD hingegen überschreibt die cOsd und cPixmap Klassen vom VDR, wodurch die Erzeugung von Pixmaps und das Zeichen auf diesen Pixmaps direkt per OpenGL auf der GPU und im dortigen Speicher geschieht. Zum einen sind so die Zeichenbefehle effizienter auf der GPU per OpenGL abbildbar, zum anderen müssen die Daten nicht mehr quer durch die Maschine geschoben werden...das sollte von der Performance her also schon einen gewissen Unterschied machen ;)


    Ciao Louis

  • Wäre es möglich dem Plugin noch einen DeviceName zu geben, damit man es bei der Auswahl des Primary Device eindeutig identifizieren kann?


    Diff
    --- a/softhdcuvid.cpp
    +++ b/softhdcuvid.cpp
    @@ -2241,6 +2242,7 @@
         cSoftHdDevice(void);
         virtual ~ cSoftHdDevice(void);
     
    +    virtual cString DeviceName(void) const { return "softhdcuvid"; }
         virtual bool HasDecoder(void) const;
         virtual bool CanReplay(void) const;
         virtual bool SetPlayMode(ePlayMode);

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Beim Detachen des Frontends mit svdrpsend plug softhdcuvid deta bekomme ich aktuell einen Segfault, ich probiere es gleich noch mal mit dem aktuellen Git-Stand:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • worauf zeigt denn die libGL.so.1 ?

    Code
    $ ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1
    lrwxrwxrwx 1 root root 14 Jun  5 16:16 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.0.0

    Ubuntu nutzt die libglnvd - soweit ich das verstanden habe, wird dann dynamisch entschieden, welche Implementation (mesa, nvidia usw.) für einen bestimmten Bildschirm genutzt wird. Die Shared Library stammt aus dem Paket libgl1.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!