softhdcuvid jetzt mit VAAPI und HDR support

    Hallo


    ich habe nun eine erste Version vom softhdcuvid mit VAAPI support eingecheckt. Man muss es im Makefile auswählen.

    Derzeit habe ich es mit einer Intel i915 Graphikkarte getestet. der 2 GHz PC schafft sogar dann UHD. Es ist nicht ganz trivial es zu kompilieren weil die Shader Version nicht unbedingt passt.

    Wer beim ausführen Errors mit den Shadern hat sollte sich die Datei drirc als .drirc ins home directory legen. Damit sollte es dann gehen. Wenn ihr das softhdcuvid als VAAPI compiliert dann wird der Treiber softhdvaapi genannt. Das ist beim eintragen in den vdr start zu berücksichtigen.


    Ich bin auf Feedback gespannt.


    mfg

    jojo61


    PS: Ich nutze die aktuelle ffmpeg Version.


    https://github.com/jojo61/vdr-plugin-softhdcuvid


    Kleiner Nachtrag: ab #246 wird auch HDR supported.

    In https://launchpad.net/~seahawk…rchive/ubuntu/softhdvaapi gibt es ein Paket, das zum VDR 2.4.1 aus https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.4.1 passt.


    Ich habe es auf einem Laptop mit einem Core i5-4200U und Ubuntu Server 18.04.3 mit yavdr-ansible als Basis ausprobiert, leider scheint die IGP zu alt zu sein, mehr als ein Crash beim Attachen ist nicht drin:

    Code
    INTEL-MESA: warning: Haswell Vulkan support is incomplete
[...]
vdr: ../src/gpu.c:377: pl_tex_create: Zusicherung »params->w > 0« nicht erfüllt.

Thread 42 "cuvid video dis" received signal SIGABRT, Aborted.


    Es waren außerdem einige Anpassungen notwendig, die unabhängig von meiner zu alten Hardware nötig sein sollten:

    • in der /etc/X11/xorg.conf.d/20-intel.conf in der ersten Section "Device" eine Zeile Option "DRI" "3" einfügen
    • Unterstützung für yavdr-frontend:
    Python: /usr/lib/python3/dist-packages/yavdr_frontend/frontends/softhdvaapi.py
    from .genericfrontend import SofthdBaseClass

class Softhdvaapi(SofthdBaseClass):
    name = 'softhdvaapi'

    Und in der /etc/yavdr-frontend/config.yml im Abschnitt vdr -> frontends:

    Code: /etc/yavdr-frontend/config.yml
    vdr:
    id: 0  # vdr instance id
    dbus2vdr_bus: SystemBus  # the bus to communicate with the dbus2vdr plugin - SystemBus or SessionBus
    attach_on_startup: auto  # choose one of auto, always or never
    wakeup_ts_file: "/var/cache/vdr/acpiwakeup.time"
    frontends:  # assign output plugins to a frontend implementation
        softhdvaapi:
            module_name: yavdr_frontend.frontends.softhdvaapi
            class_name: Softhdvaapi
            use_pasuspend: False  # suspend pulseaudio while softhddevice is active, so it has direct ALSA access


    Ob man die https://raw.githubusercontent.…-softhdcuvid/master/drirc als /var/lib/vdr/.drirc hinterlegen muss, weiß ich nicht (ich habe es gemacht, aber um die Tatsache, dass Intel libvulkan nicht für haswell unterstützt komme ich nicht herum).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

    Zitat von jojo61

    Könntest du mal mit debug laufen lassen.

    Wo kann ich das einschalten? Oder geht es dir erst mal nur darum was das Plugin mit den vorgegebenen Debug-Flags ins Log schreibt?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Jetzt habe ich es gerade geschafft, dass er detached startet, dann nach etwas Wartezeit die Ausgabe attached (es kam sogar ein Bild, das dann eingefroren ist) - der Crash kam dann erst beim Versuch den Kanal zu wechseln: vdr-portal.de/index.php?attachment/43165/


    Wie es aussieht, fehlt da noch was für die GLX-Unterstützung (glxgears läuft aber unter dem User vdr ohne zu meckern):

    Code
    Aug 22 17:08:04 yavdr-vaapi vdr[3110]: video/glx: GlxOsdInit called without glx enabled
Aug 22 17:10:45 yavdr-vaapi vdr[3110]: video/glx: GlxOsdDrawARGB called without glx enabled

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

    Ach ja - da der VDR über streamdev-client ohne Filter-Streaming angebunden ist, hat er kein EPG, eventuell ist das der Grund dafür, dass die Textur keine Breite hat.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ich habe dem VDR mal über epg2vdr ein EPG gegeben, aber der Crash beim Umschalten bzw. beim Öffnen des OSD-Menü ist immer noch da.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    Wo kann ich das einschalten? Oder geht es dir erst mal nur darum was das Plugin mit den vorgegebenen Debug-Flags ins Log schreibt?

    Ja es geht mir um das normale Log das im Syslog ausgegeben wird. Ich teste auch mit Streamdev, daran kann es also nicht liegen.

    Die Log Datei die du angehängt hast ist leider leer bzw. falsch.

    Nutzt du das openglosd ? Das ist nötig bei VAAPI. Habe es nun im Makefile angepasst. Ausserdem habe ich noch einen compile Error beim openglosd behoben.

    Habe gerade gesehen das es noch Probleme mit dem Sync zw Ton und Bild gibt. Da muss ich nochmal ran. Aber man kann zumindest schonmal soweit testen das man Bild und OSD mit Ton bekommt. Das ist schonmal die halbe Miete :)

    Zitat von jojo61

    Die Log Datei die du angehängt hast ist leider leer bzw. falsch.

    Entschuldige, da ist beim Umbenennen etwas schief gegangen.

    Zitat von jojo61

    Nutzt du das openglosd ? Das ist nötig bei VAAPI. Habe es nun im Makefile angepasst.

    Ah ok, ich hatte den Kommentar so verstanden, dass es nur in Verbindung mit CUVID Sinn macht - jetzt funktioniert das OSD und der Crash beim Umschalten ist weg. Beim Attachen sieht es jetzt so aus:

    Die Video-Ausgabe sieht mit 720p und 576i Material etwas ruckelig aus (er scheint laut Statistik im Plugin-Menü Frames zu überspringen. die Frame Process time schwankt zwischen -14,00 und -30,00 ms und scheint von den Scaling-Einstellungen abzuhängen) - liegt das an meiner alten Intel IGP oder am Plugin?


    PS: Könnte man eventuell noch den DeviceName an den im Makefile gesetzten Plugin-Namen angleichen? https://github.com/jojo61/vdr-…ter/softhdcuvid.cpp#L2427 - mein Frontend-Skript geht davon aus, dass die beiden (wie bei allen anderen Ausgabeplugins auch) identisch sind (ich habe den DeviceName im Paket aus dem PPA mal angepasst, damit Tester dadurch keine Probleme haben).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    2 Mal editiert, zuletzt von seahawk1986 ()

    Trotz LIBPLACEBO=0 kommt bei mir:


    Code
    softhdcuvid.cpp:54:33: schwerwiegender Fehler: libplacebo/filters.h: Datei oder Verzeichnis nicht gefunden
  #include <libplacebo/filters.h>


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

    Libplacebo ist zwingend notwendig, wenn man VAAPI angeschaltet hat: https://github.com/jojo61/vdr-…blob/master/Makefile#L135

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Jetzt hänge ich daran fest:


    Code
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lGLX
    Code
    vdr4 /usr/lib64/xorg/modules/extensions # ls -l
insgesamt 288
-rwxr-xr-x 1 root root 293776  4. Aug 19:21 libglx.so


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

    Zitat von jsffm

    Jetzt hänge ich daran fest:


    Code
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lGLX
    Code
    vdr4 /usr/lib64/xorg/modules/extensions # ls -l
insgesamt 288
-rwxr-xr-x 1 root root 293776  4. Aug 19:21 libglx.so

    Das ist kein xorg lib sondern eine lib aus /usr/lib64 bzw /usr/lib Also so etwas wie libGLX.so


    seahawk1986 das mit dem devicenamen mache ich gleich noch.

    Die Scaling Einstellungen sind natürlich von der Leistung der IGP abhängig. Stelle es anfangs mal auf nearest. Dann kann man in Ruhe testen. Mir ist noch unklar war so eine IGP leisten kann.

    Zitat von jojo61

    Die Scaling Einstellungen sind natürlich von der Leistung der IGP abhängig. Stelle es anfangs mal auf nearest. Dann kann man in Ruhe testen.

    Leider habe ich damit auch noch übersprungene Frames. Ich habe mal versuchsweise die Monitor-Auflösung von 1080p50 auf 720p50 gestellt, aber dadurch ist die pro Frame benötigte Zeit angestiegen.


    Es scheint auch nicht an den Energiespareinstellungen der CPU/GPU zu liegen, auch wenn ich da den Takt fest stelle, schwankt die Dauer fürs Frame-Rendering.


    Mit einem neueren Kernel und Xorg aus dem Ubuntu HWE Stack ist die minimale Dauer pro Frame niedriger, aber die maximale Dauer verhindert immer noch, dass eine flüssige Wiedergabe von MPEG2 SD Material und 720p50 h264-Material möglich sind.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ja da ist noch etwas gröberes im argen. Ich habe gesehen das ich immer 2 Frames wegwerfen muss nach einem angezeigten Frame um mit den Audio PTS in Sync zu bleiben. Das liegt sicher nicht an der Performance des Rechners. Da ist noch etwas andereres falsch. Das werde ich noch analysieren.
    Da komme ich aber erst ab Montag dazu.


    mfg

    jojo61

    Hi,


    ich habe es nun auf meinem Server mit ASRock J4105M auch compiliert bekommen.


    Bei mir läuft auch alles nur in Zeitlupe und der VDR läßt sich nur sehr träge bedienen.


    Hier mal ein gekürzter Logauszug.


    Logauszug

    Gestartet wird auf RTL-SD und ich habe einmal umgeschaltet auf RTL2-SD. Wenn weitere Infos benötigt werden oder ich was spezielles testen soll, bitte bescheid geben.



    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

    So ich habe das Problem mit dem Sync nun hoffentlich behoben. Allerdings ist die IGP von Intel (zumindest meine I915 hier) nicht in der Lage die aufwändigen Scalingalgos von Placebo in Echtzeit auszuführen. Ich habe nun alle Scaling einstellungen auf Bicubic gestellt und dann funktioniert auch alles. Bicubic scheint da nativ ausgeführt zu werden.

    Würde mich interessieren ob eine 630 er Grafikeinheit da besser ist. Leider stimmt die Anzeige der Frameprozesszeit derzeit nicht.


    Feedback ist willkommen.


    jojo61

    Danke, ich habe das gerade mal verpackt - auf den ersten Blick sieht das deutlich flüssiger aus und mit der richtigen Scaling-Einstellung habe ich auch keine Framdedrops mehr. Neben bicubic tun es bei mir auch ein paar andere Scaler für SD-Material, u.a. spline64.


    Im Direkten Vergleich von softhdcuvid auf einer GT1030 und softhdvaapi auf einer Intel HD 4400 ist das Bild mit VAAPI etwas blasser (geht IMHO in Richtung weniger stark überzeichnete Farben), dafür wirken Laufschriften (z.B. auf WELT) flüssiger.


    Gibt es irgendwo eine Übersicht zu den angebotenen Scalern? Da sind viele dabei, unter deren Namen ich mir noch nichts konkretes vorstellen kann.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Gefällt mir 1

    Die Scaler sind alle von Libplacebo. Die meisten kann man googlen und sie basieren auf einem Standard Ansatz. Darüber hinaus sind einige wohl abwandlungen von einem Standard mit leicht veränderten Parametern.

    https://superuser.com/question…ithm-to-choose-for-videos


    Ich habe festgestellt das einige gar nicht bei mit auf der I915 laufen und zum crash führen. Das liegt wohl an der GL Version die Intel da einsetzt. Da werden wohl auch float Basisvariablen verwendet die es nicht überall gibt. Ist aber nix spezielles von softhdvaapi sondern ergibt sich aus Libplacebo.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden