softhdcuvid jetzt mit VAAPI und HDR support

jojo61 · 8. Januar 2020

Ja diesen Artikel habe ich gelesen. Damit habe ich die Lösung ja erst gefunden.

Da steht das man als nicht root zum master wird wenn man das device öffnet und es wird spekuliert wie man wieder zum master werden kann wenn man den master als nicht root droppen könnte. Was nicht geht ist den master zu verlieren wenn man das device schliesst. Das habe ich ausprobiert. Man verliert den master nur dann wenn man sich beendet. Deswegen musste ich die Funktion drmDropMaster einbauen und die braucht leider root. Aus meiner Sicht ist das unsinn aber das ist halt mal so im Kernel. Ich bin auch nicht glücklich mit root und werde mal schauen wie X das macht. Der X server läuft ja auch ohne root und kann den master abgeben. Evtl gibt es ja da noch ein Lösung.

Noch ein Nachtrag:

Wer keine umschaltung zu Kodi braucht (kein DETA/ATTA nutzt), der braucht den vdr auch nicht als root laufen zu lassen. Und root wird auch nur bei drm gebraucht.

jojo61 · 8. Januar 2020

Zitat von 9000H

Hi,

I see another issue with the drm version here, not sure if it is fixable.

I do use also the old mpv plugin, which I got working for softhdvaapi but did crash with drm.

Spoiler anzeigen

[470530.163338] oglThread[11576]: segfault at 7f8df626e980 ip 00007f8df626e980 sp 00007f8d92ffce08 error 14 in libglapi.so.0.0.0[7f8df6c0d000+b000]

CU

9000h

Alles anzeigen

Ich vermute das das mpv plugin nur mit X läuft. Falls es doch mit drm läuft dann gibt es dort evtl. das gleiche Problem mit dem drmMaster der nicht gedroppt wird.

9000H · 8. Januar 2020

Hi,

will do some more debug, but libmpv should work also with drm only.

CU

9000h

seahawk1986 · 9. Januar 2020

Zitat von jojo61

seahawk1986 So ich habe gerade einen Fix für das DETA/ATTA Problem mit drm eingecheckt. Wäre prima wenn du das mal testen könntest.

Leider muss der vdr nun als root laufen weil die Funktion drmDropMaster das braucht.

Danke, ich probiere das aus, wenn ich wieder an mein Testsystem komme. Pakete dafür habe ich schon gebaut.

Zitat von jojo61

Deswegen musste ich die Funktion drmDropMaster einbauen und die braucht leider root. Aus meiner Sicht ist das unsinn aber das ist halt mal so im Kernel. Ich bin auch nicht glücklich mit root und werde mal schauen wie X das macht. Der X server läuft ja auch ohne root und kann den master abgeben. Evtl gibt es ja da noch ein Lösung.

Falls alle Stricke reißen: Kann man dem Plugin den drmMaster-Status von außen wegnehmen?

theonlychriss · 11. Januar 2020

Hallo Seahawk,

Zitat von seahawk1986

Da es nur eine Refreshrate für die Auflösung gibt würde ich mal video=DP-1:2560x1440e bzw. video=DP-1:e probieren

habe mich durch viele Versuche gekämpft, alle ohne Erfolg. Beim Angeben per "e" (e=enable) hagelte es Kernel Errors mit dem Ergebnis, dass gar keine Ausgabe ab Laden von Grub mehr möglich war. Es ging stark in diese Richtung: https://bugzilla.freedesktop.org/show_bug.cgi?id=103347 und https://bugzilla.freedesktop.org/show_bug.cgi?id=106291

Also, für Displayport scheint das Setzen ohne angeschlossenes Device wohl auch für die Treiberschreiber tricky zu sein.

Daher habe ich die Boot-Parameter gelassen, wie sie waren (video=DP-1:2560x1440@59.95D) und einen Workaround mit einer UDEV-Rule und einem Script gebastelt, der jetzt funktioniert. War im zweiten von mir genannten Link angerissen worden. Das mit "Suspending AIGLX clients for VT switch" ist immer der letzte "Fehler" im Log bei mir, wenn der Monitor beim Booten nicht an ist.

Code: /etc/udev/rules.d/95-monitor-hotplug.rules

KERNEL=="card0", SUBSYSTEM=="drm", ACTION=="change", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/chriss/.Xauthority", RUN+="/video/commands/startkde.sh"

Bash: startkde.sh

#!/bin/bash
  
DISPLAYMANAGER="sddm"

if [[ -z $(grep 'Suspending AIGLX clients for VT switch' /var/log/Xorg.0.log ) ]] ; then
        sleep 5 
        sudo systemctl restart sddm
        exit;   
else    
        echo "Xorg OK"
        exit;   
fi

Alles anzeigen

Vielen Dank für deine Hilfestellung!!

Viele Grüße,

Chriss

seahawk1986 · 12. Januar 2020

Zitat von jojo61

seahawk1986 So ich habe gerade einen Fix für das DETA/ATTA Problem mit drm eingecheckt. Wäre prima wenn du das mal testen könntest.

Leider muss der vdr nun als root laufen weil die Funktion drmDropMaster das braucht.

Ich bin jetzt endlich mal dazu gekommen das auszuprobieren und kann einen Teilerfolg vermelden:

DETA als root klappt (danach sehe ich das UEFI-Boot-Logo von meinem Laptop), dann kann ich KODI starten und nach dem Beenden von KODI wieder ein ATTA machen.

Was leider nicht mehr nach dem erneuten Attachen funktioniert ist das OSD - sobald ich das Aufrufe oder den Kanal wechseln will, springt er zwischen den letzen beiden Frames hin- und her und hängt sich weg:

Code

Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] [softhddev]CreateOsd: left 154, top 621, level 0, using OpenGL OSD support
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] [softhddev]Trying to start OpenGL Worker Thread
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] oglThread thread started (pid=1369, tid=1469, prio=high)
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] [softhddev]OpenGL Context initialized
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] [softhddev]Shaders initialized
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] [softhddev]vdpau interop initialized
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] [softhddev]Vertex buffers initialized
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] [softhddev]Maximum Pixmap size: 0x0px
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] [softhddev]OpenGL Worker Thread successfully started
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] [softhddev]cOglOsd osdLeft 154 osdTop 621 screenWidth 1920 screenHeight 1080
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] [softhddev]ERROR::cOglOutputFb: Framebuffer is not complete!
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] [softhddev]ERROR: 512 Framebuffer is not complete!
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] [softhddev] cannot allocate pixmap of 1664px x 372px, clipped to 0px x 0px!
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] [softhddev]ERROR: 512 Framebuffer is not complete!
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] [softhddev]SetPlayMode: 0
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] [softhddev]SetVideoDisplayFormat: 1
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] [softhddev]GetSpuDecoder:
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] video/glx: error openglosd.cpp:1266 1281 'invalid value'
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] video/glx: error openglosd.cpp:1266 1281 'invalid value'
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] video/glx: error openglosd.cpp:1266 1281 'invalid value'
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1469] video/glx: error openglosd.cpp:1266 1281 'invalid value'
Jan 12 21:56:54 yavdr-focal vdr[1369]: [1369] switching to channel 2 C-1-1079-11110 (ZDF HD)

Alles anzeigen

Gäbe es denn eine Möglichkeit dem VDR von außen den drmMaster Status wegzunehmen? Dann könnte man den VDR vielleicht doch als normalen Nutzer innerhalb einer Systemd Session laufen lassen....

jojo61 · 13. Januar 2020

Zitat von seahawk1986

Was leider nicht mehr nach dem erneuten Attachen funktioniert ist das OSD - sobald ich das Aufrufe oder den Kanal wechseln will, springt er zwischen den letzen beiden Frames hin- und her und hängt sich weg:

Gäbe es denn eine Möglichkeit dem VDR von außen den drmMaster Status wegzunehmen? Dann könnte man den VDR vielleicht doch als normalen Nutzer innerhalb einer Systemd Session laufen lassen....

seahawk1986 Danke für den Test. Ich schau mal nach dem OSD Problem nach den ATTA.

Leider gibt es keine möglichkeit von aussen den drmMaster Status zu ändern. Ich hab mal nachgeschaut wie der X server das macht. Da wird ein Hilfsprogramm gestartet (mit root rechten) und dem wird dann der Filepointer des drm devices übergeben und der macht dann das DropMaster. Gefällt mich nicht.

Es gibt wohl auch X Server die den Filepointer in einer Environmentvariablen ablegen und dann kann man diesen FP nutzen ohne das drm Device erneut zu öffnen und damit wird man kein Master. Aber auch diese Lösung habe ich noch nirgendwo in Betrieb gesehen. Im Moment würde ich gerne mal abwarten was Kodi 20 da macht. Die wollen da ja auch auf drm ausweichen. Wenn aber unbedingt sofort eine Lösung gebraucht wird das würde ich die Lösung mit dem Hilfsprogramm implementieren. Wie sieht du das ?

mini73 · 13. Januar 2020

Hilfsprogramm klingt gut.

seahawk1986 · 13. Januar 2020

Zitat von jojo61

Im Moment würde ich gerne mal abwarten was Kodi 20 da macht. Die wollen da ja auch auf drm ausweichen.

KODI 18 kann ja prinzipiell schon über drm ausgeben (auch wenn man da u.a. noch keine Möglichkeit hat den Bildschirm zu wählen) - bis KODI 20 wäre das ja noch mindestens ein Jahr, nachdem im November eine Vorabversion von KODI 19 angekündigt wurde, oder?

Zitat von jojo61

Wenn aber unbedingt sofort eine Lösung gebraucht wird

Nachdem die restlichen Komponenten für die 10-Bit Wiedergabe mit 50 Hz noch nicht so weit zu sein scheinen, muss das eigentlich nicht sofort passieren - mir ist eine langfristig gut nutzbare Lösung lieber als ein schneller Workaround.

jojo61 · 13. Januar 2020

Zitat von seahawk1986

KODI 18 kann ja prinzipiell schon über drm ausgeben (auch wenn man da u.a. noch keine Möglichkeit hat den Bildschirm zu wählen) - bis KODI 20 wäre das ja noch mindestens ein Jahr, nachdem im November eine Vorabversion von KODI 19 angekündigt wurde, oder?

Nachdem die restlichen Komponenten für die 10-Bit Wiedergabe mit 50 Hz noch nicht so weit zu sein scheinen, muss das eigentlich nicht sofort passieren - mir ist eine langfristig gut nutzbare Lösung lieber als ein schneller Workaround.

Ich hatte in einem Chat gelesen das Kodi 20 erst HDR und drm bringen soll. Hatte aber nicht im Blick wann das soweit sein soll. Aber die Linux Treiber sind ja auch alle noch nicht so extrem weit. Und ffmpeg ist auch noch nicht soweit mit den v4lm2m codecs auf die Kodi setzen will. Also keine Eile.

jojo61 · 18. Januar 2020

Ich habe noch ein paar kleiner Fixes gemacht und nun sollte auch drm einigermaßen sauber sein. Auch shady sollte nun funktionieren.

Allerdings scheint der vaapi dekoder bei hevc in bestimmten Situationen (fehlerhafte Frames) Speicher zu fressen. Ob das am Dekoder oder an FFMPEG liegt konnte ich nicht rausfinden. Zumindest scheint auch mit mpv der Speicher weniger zu werden. Am besten sieht man das mit travelxp. Nur leider kann ich da mit mpv nicht testen weil der verschlüsselt ist.

CKone du wolltest doch mal eine travelxp Aufnahme mit dem Problem extrahieren. Evtl. kann man ja damit dann den Fehler eingrenzen. Wenn ich mit meinem Plugin behaupte es ist ffmpeg dann glaubt das niemand, aber wenn es mit mpv reproduzierbar ist dann ist das was anderes

CKone · 19. Januar 2020

jojo61 also ich hätte ein 2 Minuten Stück travelxp (wie erwartet beim Sendungsübergang bei dem ich es recht sauber reproduzieren kann.

Kann ich die 230Mb irgendwo hochladen?

ich versuche gleich nochmal andersherum und lasse ihn in der Aufnahme von einer Stunde über diese 2 Minuten rüberspringen, mal sehen was dann passiert

Uwe · 19. Januar 2020

Zitat von 9000H

Hi,

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

CU

9000h

Vielen Dank 9000h für den Patch, dadurch crasht es bei Timerkonflikten bei einem VDR-Start mit aktiven skinnopacity-Skin nicht mehr.
Siehe hier: softhdcuvid jetzt mit VAAPI und HDR support

Gruß

Uwe

jojo61 · 19. Januar 2020

So und ein weiterer Versuch das memoryleak zu beheben. Zumindest bei mir bleibt die Speichernutzung stabil.

CKone kannst du das nochmal teste bitte.

wmautner · 19. Januar 2020

Zitat von 9000H

Hi,

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

CU

Danke, scheint auch bei mir den WAF wieder zu erhöhen

CKone · 19. Januar 2020

ich lasse es grad auf launchpad neu bauen, teste ich nachher wenn es durch ist.

Danke an dich und an Alex fürs "Pakete auflegen"

Grillbert · 20. Januar 2020

Zitat von wmautner

Danke, scheint auch bei mir den WAF wieder zu erhöhen

Das klingt doch sehr gut
Danke an jojo61 für den Einsatz - MEGA!!

Leider habe ich bei mir keinen Test-VDR und ein hoher "WAF" ist überlebenswichtig für den (Zitat) "Nerd Kram" im Wohnzimmer.

Was funktioniert denn inzwischen und wo hakt es noch? Ist das Plugin inzwischen reif für einen Intel-basierten "Familien" - VDR?

wmautner · 20. Januar 2020

Das bezog sich jetzt auf den timer-conflict-Patch für nopacity, ich verwende derzeit eine nvidia-Karte und das normale softhddevice-Plugin.

Danke

jojo61 · 20. Januar 2020

Grillbert Also die Version mit vaapi dekoder sollte stabil sein solange du kein UHD schaust. Bei UHD gibt es noch Probleme mit Speicherverlust.

Wenn ich mir deinen Footer anschaue dann empfehle ich dir die drm Version weil die sehr wenig resourcen braucht und ohne X server läuft.

Mir ist schon klar das der WAF nötig ist, aber man muss sich auch mal durchsetzen können

JoeBar · 25. Januar 2020

Welche CPU bzw. IGP sind empfehlenswert für UHD? Reicht ein Pentium G4560 mit HD 610 oder sollte besser ein i3 7100 mit HD 630 her?

Viele Grüße

Edit: Ich hab mit jetzt mal den ganzen Thread durchgelesen... also funktioniert das ganze erst ab gen8 CPUs im NUC wegen Hdmi 2.0a?

softhdcuvid jetzt mit VAAPI und HDR support

Jetzt mitmachen!

Teilen