softhdcuvid jetzt mit VAAPI und HDR support

  • Ich nutze seit geraumer Zeit softhdcuvid mit libplacebo mit meiner GeForce GT 1030 unter gentoo.


    vor einigen Tagen hat mir ein Update libplacebo-2.43.0 eingespielt. Damit erhalte ich (ebenso mit libplacebo-2.72.0) ein weißes Bild, in dem wohl nur Differenzbilder angezeigt werden. Sieht teilweise sehr psychedelisch aus.


    Versuchsweise bin ich dann auf libplacebo-1.29.1. Damit habe ich korrektes Videobild, aber manche Menüs sind verzerrt. Man beachte die bogenförmige Krümmung rechts im Bild:



    Also zurück auf libplacebo-1.21.0-r1. Damit ist dann alles wieder OK, so wie es vorher war.


    Ich lese allerdings, daß anderswo die 72er API läuft. Was könnte bei mir falsch laufen?


    Christian

  • Ich nutze x11-drivers/nvidia-drivers-440.82-r3, also grob Deine Version des Treibers.


    Das Plugin habe ich jeweils mittels make clean, make, make install im plugin-Verzeichnis aktualisiert, sonst wäre vdr vermutlich auch gar nicht gestartet. Ich meine, gestern auch mal vdr mit allen plugins gecleant und neu gebaut zu haben.

    Aber irgendsowas müsste es sein, wenn es bei allen anderen läuft.


    Code
    1. vdr ~ # journalctl --since today |grep -i "placebo mit api"
    2. Jun 24 13:20:47 vdr vdr[337]: Init Placebo mit API 29
    3. Jun 24 13:26:10 vdr vdr[3977]: Init Placebo mit API 21
    4. Jun 24 13:29:49 vdr vdr[6537]: Init Placebo mit API 72
    5. Jun 24 13:47:00 vdr vdr[8905]: Init Placebo mit API 21
    6. Jun 24 19:31:49 vdr vdr[342]: Init Placebo mit API 21


    Ich probiere in den nächsten Tagen noch ein wenig rum, momentan ist der vdr fest in Familienhand. Da komme ich nicht ran ;-)

    Christian

  • Nach einem der letzten Updates von softhdvaapi und/oder libplacebo kann funktioniert im Plugin osdteletext nicht mehr die Transparenz auszuschalten.

    Die Funktion "Hintergrund-Transparenz" = 255 hat keine Wirkung mehr und der Hintergrund ist nicht mehr schwarz, sondern transparent.


    Wurde denn irgendwas geändert, was das verursachen könnte?

  • Ich probiere in den nächsten Tagen noch ein wenig rum, momentan ist der vdr fest in Familienhand. Da komme ich nicht ran ;-)

    Die API 29 habe ich inzwischen am Laufen, da war irgendwas nicht sauber kompiliert.

    Weiterhin bringen mir die 43 und die 72 den annähernd weißen Bildschirm mit Differenzbildern (gezeigt wird nur, was sich bewegt hat).


    Edit: ich bin da jetzt mal mit git bisect durchgegangen. Der erste commit in libplacebo, der nicht mehr läuft ist dieser hier (shaders/colorspace: actually implement pl_color_adjustment.gamma) . Der war von jojo61 angefordert worden, also scheint mir das plausibel. Bringt mich jetzt nicht direkt weiter, aber vielleicht hat jetzt jemand einen Tip, woran es hängt. Schön finde ich die Anmerkung im commit: '

    Code
    1. I have no idea how horribly this breaks for images with an alpha
    2. channel. I guess *somebody* will find out.

    Das bin dann wohl möglicherweise ich...


    Christian

  • Hallo jojo61,


    keine Ahnung, ob das hier im Thread richtig ist.

    Seit einiger Zeit habe ich Probleme, wenn eine Aufnahme an eine letzte Schnittmarke kommt (pauseatlastmark=0). Dann läufz die Aufnahme in Superzeitlupe. Der VDR reagiert auf keine FB-Eingaben wie exit/back oder Stop. Das Log zeigt rein gar nichts.

    Erst ein kill des vdr hilft.


    Liegt es evtl. an einer der letzten Änderungen im softhdvaapi?


    Markus

  • Seit einiger Zeit habe ich Probleme, wenn eine Aufnahme an eine letzte Schnittmarke kommt (pauseatlastmark=0). Dann läufz die Aufnahme in Superzeitlupe. Der VDR reagiert auf keine FB-Eingaben wie exit/back oder Stop. Das Log zeigt rein gar nichts.

    Erst ein kill des vdr hilft.


    Liegt es evtl. an einer der letzten Änderungen im softhdvaapi?

    An der Stelle habe ich nichts geändert. Ich denke auch nicht das die Ursache im Ausgabeplugin liegt. Das Plugin zeigt an was an Streamdaten geliefert wird. Wenn da nix mehr kommt dann zeigt es das letzte Frame an. Dadurch wird der vdr aber nicht unbedienbar. Das muss dann davor irgendwo liegen.

    Soweit die Theorie. Passiert das auch mit dem anderen vaapi plugin ?

  • Kann ich nicht sagen, benutze nur softhdvaapi. softhddrm hatte ich auf die Schnelle nicht zum Laufen bekommen. Ist ja eigenartigerweise auch nicht immer so. Muss ich mal nach dem Urlaub, wenn mir wieder so eine Aufnahme unterkommt mit dem normalen softhddevice probieren.

    Ist auch eigenartig, ist wirklich super-slowmotion, alle paar Sekunden bewegt sich das Bild mit Ton gefühlt einen Frame weiter. Per Fernbedienung geht überhaupt nichts mehr und das Log schweigt.

  • Hallo zusammen,
    ich habe mir gerade meinen VDR komplett neu als YaVDR Ansible (Focal) aufgesetzt und nutze aktuell vdr-plugin-softhdvaapi aus seahawk´s PPA.
    Genau wie bei meiner alten Installation tritt noch das Problem auf, dass nach Ausblenden des OSDs (Skindesigner basiert) oft ein Strich am unteren OSD-Rand auf dem Bildschirm bleibt...
    Gibt es dafür eine Lösung oder eine Lösung (oder einen Workaround)?
    Ist nicht dramatisch (2x "Menu" und alles ist wieder OK), aber schöner wäre es ohne :)

    Cine S2 V6.5 + DuoFlex V4 Apollo-Lake Celeron (Asrock J3355M), ATRIC Einschalter, MLD 5.4 testing

  • Wenn du den gepatchten Skindesigner hast dann kann ich da wenig tun.


    Evtl. kannst du das ausblenden schneller einstellen. Da wird ja mehrfach das OSD gemalt bevor es ganz weg ist. Da das aber nicht syncronisiert ist mit dem vdr-pluginsofthdvaapi kann es halt vorkommen das ein rest zurückbleibt.


    mfg

    jojo61

  • Nur zur Info: Dieses (ziemlich nervige...) Problem hab ich auch, IIRC ausschliesslich mit SD Sendern.

    Allerdings läuft bei mir noch ein VDR 2.4.0 mit vdr-plugin-softhddevice-0.7~git20180203, compiliert vor 2 Jahren, auf Celeron J4105 CPU...

    VDR1:ASRock Ion 3D 152B, Sundtek SkyTV Ultimate openSUSE Leap 42.2, VDR 2.4.0,
    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.0

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git)

  • Aktuell habe ich diverse Probleme mit libplacebo. Ich nutze VAAPI (und CUDA auf einem zweiten System), mit libplacebo 1.29 war es kein Problem. Jetzt nach Neuinstallation Fedora 33 mit aktuellsten Treibern und libplacebo 2.72.0 nur ein weißes Videobild, das OpenGL-Overlay funktioniert aber. VAAPI ohne libplacebo funktioniert auch. softhdvaapi ist natürlich entsprechend gegen die Libraries neu gebaut worden.


    Aug 17 08:58:29 nuc vdr[1089]: [1089] switching to channel 1 S19.2E-1-1019-10301 (Das Erste HD)

    Aug 17 08:58:29 nuc vdr[1089]: Init Placebo mit API 72

    Aug 17 08:58:30 nuc vdr[1089]: [1103] [softhddev]OglThread cleanup

    Aug 17 08:58:31 nuc vdr[1089]: GetFormat Init ok 1280x720

    Aug 17 08:58:31 nuc vdr[1089]: video: crop to +0+0 1280x720

    Aug 17 08:58:31 nuc vdr[1089]: video: normal aspect output 1875x1055+21+0

    Aug 17 08:58:31 nuc vdr[1089]: video: crop to +0+0 1280x720

    Aug 17 08:58:31 nuc vdr[1089]: video: normal aspect output 1920x1080+0+0


    jojo61 , hast Du eine Idee?


    Dirk


    PS: Beim Shutdown des Systems bekomme ich folgenden Fehler, der sich immer wiederholt:


    Aug 17 08:51:00 nuc runvdr[2046]: error: vk->GetPhysicalDeviceSurfaceCapabilitiesKHR(vk->physd, p->surf, &caps): unknown error

    System 1: Hardware : ASUS B150M-C, Intel Pentium G4560, DVB cineS2, 1x 2TB HDD, 1x 214GB SSD, Gehäuse Antec Remote Fusion Black, 8 GB DDR4 RAM.
    Software : Fedora 33, vdr 2.4.5, softhddevice GIT, Kernel 5.9.16
    System 2: Hardware : Intel NUC10i5FNK, Intel Core i5-10210U (Comet Lake), DVB TechnoTrend TT-connect S2-4600 USB, 1x 1TB NVMe, 32 GB DDR4 RAM.
    Software : Fedora 33, vdr 2.4.5, softhdcuvid GIT, Kernel 5.9.16

  • Wurde hier glaube ich schon einige Male beschrieben. Ab einer bestimmten Version, muss der Gamma-Wert im softhdvaapi-Plugin umgestellt werden. Hab es grad nicht im Kopf, entweder von min>max oder eben andersrum.

  • PS: Beim Shutdown des Systems bekomme ich folgenden Fehler, der sich immer wiederholt:


    Aug 17 08:51:00 nuc runvdr[2046]: error: vk->GetPhysicalDeviceSurfaceCapabilitiesKHR(vk->physd, p->surf, &caps): unknown error

    Ist da eventuell der X-Server schon weg, bevor der VDR beendet wird?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wurde hier glaube ich schon einige Male beschrieben. Ab einer bestimmten Version, muss der Gamma-Wert im softhdvaapi-Plugin umgestellt werden. Hab es grad nicht im Kopf, entweder von min>max oder eben andersrum.

    Ja ich hatte schon immer einen Gamma Wert eingebaut, aber libplcebo hatte den ignoriert. Als er dann dort aktiviert wurde stelle sich heraus das der default falsch war. Damit ergab sich dann ein fast weisses Bild.

  • Wurde hier glaube ich schon einige Male beschrieben. Ab einer bestimmten Version, muss der Gamma-Wert im softhdvaapi-Plugin umgestellt werden. Hab es grad nicht im Kopf, entweder von min>max oder eben andersrum.

    Richtig, hätte ich auch selber finden können. gamma auf "max" und gut ist. Ich schaue mal, ob man das vielleicht nicht als Default setzt. Die Wertebereiche finde ich im Übrigen sehr komisch: Gamma auf Max, damit mit den Standard-Gammawert bekommt?


    Das Decoding der Streams ist im Übrigen leider immer noch nicht so stabil wie bei softhddevice, ich bekomme manchmal beim Programmwechsel einen fehlerhaften Stream (Klötzchenbildung), der Fehler geht dann erst weg, wenn ich noch einmal zappe. Da wird irgendwas nicht sauber angestartet bzw. initialisiert.


    Dirk

    System 1: Hardware : ASUS B150M-C, Intel Pentium G4560, DVB cineS2, 1x 2TB HDD, 1x 214GB SSD, Gehäuse Antec Remote Fusion Black, 8 GB DDR4 RAM.
    Software : Fedora 33, vdr 2.4.5, softhddevice GIT, Kernel 5.9.16
    System 2: Hardware : Intel NUC10i5FNK, Intel Core i5-10210U (Comet Lake), DVB TechnoTrend TT-connect S2-4600 USB, 1x 1TB NVMe, 32 GB DDR4 RAM.
    Software : Fedora 33, vdr 2.4.5, softhdcuvid GIT, Kernel 5.9.16