softhdcuvid jetzt mit VAAPI und HDR support

kamel5 · November 1, 2019 at 12:03 PM

Hi,

you can try this version of skinnopacity:

gitlab.com/kamel5/SkinNopacity.

This should work with GraphicsMagick.

kamel5

zork · November 1, 2019 at 12:15 PM

Quote from jojo61

Die Sourcen compilieren bei mir nicht. Ich habe Image Magick in der aktuellsten Version hier.

Code

imagemagickwrapper.c: In member function 'cImage* cImageMagickWrapper::CreateImage(int, int, bool)':
imagemagickwrapper.c:30:11: error: 'PixelPacket' does not name a type
   30 |     const PixelPacket *pixels = buffer.getConstPixels(0, 0, w, h);
      |           ^~~~~~~~~~~

Kompiliert bei mir ohne Probleme durch, ich habe allerdings aktuelle Libs, denke ich:

Code

ImageMagick-6.9.10.67-1.fc31.x86_64
ImageMagick-c++-6.9.10.67-1.fc31.x86_64
ImageMagick-c++-devel-6.9.10.67-1.fc31.x86_64
ImageMagick-devel-6.9.10.67-1.fc31.x86_64
ImageMagick-libs-6.9.10.67-1.fc31.x86_64

Ich würde Dir skinflat-plus empfehlen, ist noch etwas schicker. GraphicsMagick als Replacement kann ich nicht empfehlen, das läuft bei mir auch instabil.

zork

jojo61 · November 2, 2019 at 3:52 PM

9000H Ich habe nun mal das OSD für PLACEBO gefixt. Damit sollte dann auch skinnopacity gehen. Muss aber PLACEBO aktiv sein.

Ich hoffe das hilft. Ohne Placebo ist das schwierig zum laufen zu bekommen. Da stören sich die VAAPI Frames mit dem egl Buffern vom OSD.

mfg

jojo61

jojo61 · November 5, 2019 at 10:10 PM

So ich habe nun auch das OSD für die Varianten ohne Placebo überarbeitet und hoffe das damit nun alle Skin Plugins sauber laufen.

mfg

jojo61

Ich denke nun könnte man mal wieder Pakete bauen

Wie geht es nun weiter ? Ich bin gerade am HDR Support für Intel. Dabei geht es aber nur langsam voran weil es da praktisch keine Doku zu gibt.

Als erstes muss es mir gelingen YCrCb 4:2:0 mit 10 Bit Farbtiefe auszugeben. Da bin ich noch dran.

Dann muss ich die HDR Metadaten über den Port ausgeben. Dafür hat Intel den Treiber ja erweitert und ich bin gespannt wie das klappt.

Ich vermute das ich dafür das device /dev/dri/card0 brauche und damit geht das dann nur ohne X Server. Es bleibt spannend

Ich hoffe das dann als Weihnachtsgeschenk fertig zu bekommen.

9000H · November 5, 2019 at 11:44 PM

Hi,

the OSD looks better now with and without placebo. I do have now only one channel where I get a crash also with LCARS skin only

Code

ARTI TV;MB Satellite:11054:HC56M2S0:S13.0E:27500:310=2:320=eng@4:0:0:8003:318:12700:0

Display Spoiler

Code

Core was generated by `vdr -l3 -w 60 --chartab=ISO-8859-1 -Pfemon -Pskinnopacity -Pepgsearch -v 3 -Psa'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f543c151290 in ?? ()
[Current thread is 1 (Thread 0x7f5405ffb700 (LWP 14373))]
(gdb) bt full
#0  0x00007f543c151290 in  ()
#1  0x00007f54c53be9e6 in FT_Done_FreeType ()
    at /lib/x86_64-linux-gnu/libfreetype.so.6
#2  0x00007f54bf79dfb8 in cOglFb::Init() (this=0x7f54bf7c1010)
    at openglosd.cpp:581
#3  0x00007f54bf7a2ff1 in cVector<cOglPixmap*>::Realloc(int) const
    (Index=0, this=0xf0) at /usr/local/include/vdr/tools.h:705
        i = 0
        PixmapMutexLock = 
            {<cMutexLock> = {mutex = 0x7f53fc000e30, locked = 112}, <No data fields>}
        dirty = false
#4  0x00007f54bf7a2ff1 in cVector<cOglPixmap*>::At(int) const
    (Index=0, this=0xf0) at /usr/local/include/vdr/tools.h:696
        i = 0
        PixmapMutexLock = 
            {<cMutexLock> = {mutex = 0x7f53fc000e30, locked = 112}, <No data fields>}
        dirty = false
#5  0x00007f54bf7a2ff1 in cVector<cOglPixmap*>::operator[](int)
    (Index=0, this=0xf0) at /usr/local/include/vdr/tools.h:707
        i = 0
        PixmapMutexLock = 
--Type <RET> for more, q to quit, c to continue without paging--c
            , <No data fields>}
        dirty = false
#6  0x00007f54bf7a2ff1 in cOglOsd::Flush() (this=0x0) at openglosd.cpp:2196
        i = 0
        PixmapMutexLock = {<cMutexLock> = {mutex = 0x7f53fc000e30, locked = 112}, <No data fields>}
        dirty = false
#7  0x0000000100003825 in  ()
#8  0x0000000000000000 in  ()
(gdb)

Display More

CU

9000h

jojo61 · November 6, 2019 at 8:02 AM

9000H Welche Auflösung hat der Channel denn ? Ich bekomme leider kein 13.0E

jojo61

PS: ich mache noch das XKey repeat rein.

CKone · November 6, 2019 at 10:47 AM

Quote from jojo61

Ich bin gerade am HDR Support für Intel.

...

Es bleibt spannend

Ich hoffe das dann als Weihnachtsgeschenk fertig zu bekommen.

richtig spannend ist was wir da alle am Black Friday shoppen gehen sollen damit wir Weihnachten auch mitspielen können

Danke für deinen Einsatz, wir sind alle sehr gespannt!

Christian

jojo61 · November 6, 2019 at 11:24 AM

In den Linux Quellen sieht man das Intel es offiziell ab Generation 10 unterstützt. Da ich aber nur eine Gen9 Grafik habe (NUC8) und die das unter Windows aber auch kann, denke ich das es auch mit Gen9 zu schaffen sein sollte. Beim testen habe ich schon mehrfach den Intel drm Kerneltreiber gepatcht um weiter zu kommen

Was du nun shoppen sollst ist mir auch nicht klar

9000H · November 6, 2019 at 1:34 PM

Hi,

ARTI TV

https://www.satindex.de/channel/22846/

I saw it only by accident, and it's not really important to me, but the other softhddevices do not crash on this channel.

CU

9000h

M-Reimer · November 6, 2019 at 5:05 PM

jojo61 Siehst du denn eine Chance die Buil-Abhängigkeit zu diesem riesigen Cuda loszuwerden?

jojo61 · November 6, 2019 at 10:40 PM

Im Moment ist das nicht meine priorität. Ist das wirklich ein so großen Problem ?

M-Reimer · November 7, 2019 at 6:38 AM

Sagen wir's so: Das riesige Paket ist der Grund dafür das das Plugin bei vdr4arch aus dem Autobuild ausgeschlossen ist.

Nur für das eine Paket werden wir den V-Server nicht "aufrüsten" lassen.

jojo61 · November 7, 2019 at 7:38 AM

So wie ich das sehe werden aus dem Paket nur ein paar include Dateien und ein oder zwei Libs gebraucht. Evtl. kann man die ja aus dem Paket extrahieren und auf den Build Server legen. Ich schaue mir das nächste Woche mal an und komm auf dich zurück.

mfg

jojo61

M-Reimer · November 7, 2019 at 8:19 AM

Ja, das ist mit großer Wahrscheinlichkeit so. Entsprechend fragwürdig finde ich, dass Nvidia das in ein so großes Paket packt. Das Zeug wäre deutlich handlicher wenn Nvidia das in einige kleine Päckchen geteilt hätte. Leider habe ich im Internet keine Quelle gefunden wo man die einzelnen Komponenten separat runterladen kann. Sonst hätte ich mir für unser PKGBUILD da schon etwas gebaut das temporär einzelne Dateien an einen entsprechenden Ort ablegt um dagegen zu kompilieren.

sg75 · November 10, 2019 at 10:17 AM

Hallo jojo,

ich habe auf unserem "Produktiv-VDR" auf softhdvaapi (LIBPLACEBO=0) umgestellt (von softhdcuvid mit Nvidia GTX 1030).

Es läuft schon richtig gut Vielen Dank!

Seit 6acd2feb3f2f9515a28c028c757b26d8f8574e98 gibt es allerdings im oberen Zehntel des Bild Tearing.

Weil es so weit oben im Bild es, fällt es nicht sofort auf, sondern nur bei Kameraschwenks oder schnellen Bewegungen.

Es scheint unabhängig vom Codec und Auflösung zu sein.

Vor diesem Commit war dieses Problem nicht da.

Allerdings gab es vor diesem Commit ein anderes Problem:

Beim Seitenwechsel im osdteletext gibt es Sprünge bzw. Zittern im Videostream.

Mir wäre das egal, aber meine bessere Hälfte mag es nicht tolerieren ...

Gibt es irgendwelche Tricks, um das Tearing los zu werden?

Die üblichen xorg.conf Ratschläge habe ich schon erfolglos durchdekliniert:

Code

Section "Device"
        Identifier  "Intel Graphics"
        Driver      "intel"
#       Option      "DRI"       "false"
        Option      "TearFree"  "true"
#       Option      "AccelMethod" "uxa"
        Option      "AccelMethod" "sna"
        Option      "SwapbuffersWait" "true"
        Option      "TripleBuffer" "true"
EndSectio

Schöne Grüße

Christian

jojo61 · November 11, 2019 at 5:50 PM

Hallo sg75

ich würde dir empfehlen von dem veralteten Intel Treiber auf den neuere modesetting Treiber umzustellen. Damit habe ich kein tearing:

Code

Section "Device"
  Identifier "Default Device"
#
Driver "modesetting"
#Driver "intel"

Option "AccelMethod" "glamor"
Option "TearFree" "true"
Option "DRI" "3"
EndSection

sg75 · November 12, 2019 at 8:58 AM

Hallo jojo,

der "modesetting"-Treiber macht es leider noch sichtbarer - jetzt ist es eher ein Viertel statt einem Zehntel mit einem Dreieck auf der linken Seite

Im Kameraschwenk in diesem Beispiel ist es am Besten zu sehen.

Ich baue erstmal wieder die GTX1030 ein, sonst gibt es heute Abend noch Ärger

jojo61 · November 12, 2019 at 11:29 AM

Hast du mal im Xorg Log geschaut ob auch alle Optionen die du eingetragen hast, erkannt und eingestellt werden ?

Ich kann es kaum glauben das du Tearing mit der Konfig hast die ich gepostet habe. Da ist noch etwas anderes faul.

Hast du den NVIDIA Treiber und die Mesa Treiber beide auf dem Rechner ? Die stören sich bei mir.

mfg

Jojo61

sg75 · November 13, 2019 at 9:34 AM

Ja, der "modesetting"-Treiber und nicht der "intel"-Treiber war aktiv genauso wie die "glamor" AccelMethod.

"TearFree" "true" wurde nicht angewendet, weil es keine gültige Option wäre.

Ich kann mein Produktivsystem erst am Wochenende wieder testen. Dann test ich auch meine andere Intel-Hardware mal durch.

Mit aktuelllem git vom softhdcuvid und der GTX1030 läuft das Produktivsystem stabil ... allerdings mit 5-8 Watt mehr Leistungsaufnahme.

9000H · November 19, 2019 at 8:07 PM

Hi,

I think the OSD issue with skinnopacity is the skin itself, my attached patch did the trick here.

CU

9000h

Participate now!