Posts by zork

Was bekommst Du denn bei diesem Aufruf:

mpv -v --no-config --vo=vaapi --hwdec=vaapi <file>

Ich habe hier das Problem, kein OSD erkannt wird. Und softhddevice meldet Folgendes:

OSD size changed to 1920x1080 @ 1
video/vaapi: can't find a supported subpicture format
video/vaapi: no osd subpicture yet

Usw. Wie gesagt, mehrere softhd* Plugins probiert. Und ein produktives System mit funktionierenden vaapi/subpicture habe ich ja auch.

Hi,

ich wollte softhdcuvid auf einem aktuellen Intel-System aufsetzen, das nicht mehr vom i965 unterstützt wird. Soweit auch alles gut:

# vainfo
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.13 (libva 2.13.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 21.3.4 ()
[...]

Aber: Probleme mit dem OSD, die beim i965 vaapi driver nicht existieren, nachweisbar z.B. mit mpv:

LIBVA_DRIVER_NAME=iHD mpv -v --no-config --vo=vaapi --hwdec=vaapi <file>
[...]
[vo/vaapi/vaapi] Initialized VAAPI: version 1.13
[vo/vaapi] 0 subpicture formats available:
[vo/vaapi] OSD format not supported. Disabling OSD.
[...]

OK, kein OSD. Beim i965 auf einem anderen System sieht das noch so aus:

[vo/vaapi/vaapi] Initialized VAAPI: version 1.11
[vo/vaapi] 6 subpicture formats available:
[vo/vaapi]   AI44, flags 0x6
[vo/vaapi]   IA44, flags 0x6
[vo/vaapi]   IA88, flags 0x6
[vo/vaapi]   AI88, flags 0x6
[vo/vaapi]   BGRA, flags 0x6
[vo/vaapi]   RGBA, flags 0x6

Das betrifft jetzt auch alle Generationen von softhd* Plugins! Dort geht nämlich jetzt kein subpicture mehr, ergo kein OSD! Intel weiß über das Thema auch Bescheid, ist als Feature Request deklariert: https://www.vdr-portal.de

Einzige Lösung, die ich aktuell gefunden habe, ist die Benutzung von libplacebo (softhdvaapi oder softhddrm). Ich würde mir aber gerne die Option offen lassen, ohne libplacebo zu arbeiten. Hat vielleicht einer einen Lösungsansatz?

Quote from cinfo

Hi,

ich hatte gerade versucht den "Git Stand GIT891d432" von heute zu übersetzen (mit Kernel 5.12.rc3).

bei softhddrm (ohne libplacebo) erhalte ich folgenden Fehler

Code

In file included from video.c:618:
hdr.c: In function 'set_hdr_metadata':
hdr.c:332:32: error: storage size of 'data' isn't known
  332 |     struct hdr_output_metadata data;
      |                                ^~~~

softhdvaapi (3.4-GIT891d432) (ohne libplacebo) konnte ich ohne Fehler erstellen

Grüße

cinfo

Display More

Dein libdrm ist zu "alt". Die Definition ist erst in libdrm-2.4.104 drin.

Zork

Na endlich, 5.12 wird die Patche enthalten: https://www.phoronix.com/scan.php?page=…tel-Initial-Gfx

Quote from zork

Ich habe mal mir die Zeit genommen, einen gepatchen Kernel zu übersetzen. 5.11-rc1 und die Patche passen gut zusammen, lässt sich problemlos compilieren und installieren. Leider hängt sich das Display auf, wenn man versucht, eine UHD-Auslösung mit DRM zu aktivieren. Der 5.9er Kernel läuft dabei ohne Probleme (leider bei mir nur bis 30Hz). 5.11 scheint noch etwas buggy zu sein. Mit 5.10.4 gibt es Schwierigkeiten, die Patche zu applien, auch beim Compilieren treten dann Fehler auf. Also heißt es: weiter abwarten auf vernünftige Patche von Intel. Die Situation ist ziemlich nervig, auch im libreelec-Forum sind die Erfolge bescheiden. Leider sind aktuelle Systeme von Intel über LSPCON-Chipsätze angebunden und können nicht nativ HDMI 2.0b sprechen. Ich selber habe eine topaktuelle CPU (Comet Lake), sogar da ist es noch so. So langsam gebe ich die Hoffnung auf, dass es mit native UHD und VDR noch was wird.

Es hat mich jetzt herausgefordert herauszufinden, was die Plattform technisch kann. Als Test habe ich Windows 10+Kodi 19 beta 2 genommen. Und siehe da, UHD/60 Hz funktioniert, HDR wird dynamisch an- und abgeschaltet, CPU-Last beim Abspielen von UHD-Demos sehr gering. Sogar 4K geht (Fernseher schneidet die Ränder dann ab). Was auch sehr gut funktioniert, ist das dynamische Wechseln der Auflösung/Bildfrequenz, das wünsche ich mir auch für softhdxxx. Das Bild ist glasklar, so hohe Frequenzen ist schon ne sehr feine Sache. Die Frage ist, wie lange der Treibersupport unter Linux wohl noch dauern wird, die erste Patche sind von 2018 und immer noch nicht im Kernel integriert (es scheint dort aber endlich weiterzugehen: https://cgit.freedesktop.org/drm/drm-intel/…tel-next-queued.

Ich habe mal mir die Zeit genommen, einen gepatchen Kernel zu übersetzen. 5.11-rc1 und die Patche passen gut zusammen, lässt sich problemlos compilieren und installieren. Leider hängt sich das Display auf, wenn man versucht, eine UHD-Auslösung mit DRM zu aktivieren. Der 5.9er Kernel läuft dabei ohne Probleme (leider bei mir nur bis 30Hz). 5.11 scheint noch etwas buggy zu sein. Mit 5.10.4 gibt es Schwierigkeiten, die Patche zu applien, auch beim Compilieren treten dann Fehler auf. Also heißt es: weiter abwarten auf vernünftige Patche von Intel. Die Situation ist ziemlich nervig, auch im libreelec-Forum sind die Erfolge bescheiden. Leider sind aktuelle Systeme von Intel über LSPCON-Chipsätze angebunden und können nicht nativ HDMI 2.0b sprechen. Ich selber habe eine topaktuelle CPU (Comet Lake), sogar da ist es noch so. So langsam gebe ich die Hoffnung auf, dass es mit native UHD und VDR noch was wird.

Hi,

wie geht es eigentlich mit der UHD/HDR Entwicklung weiter? Soweit ich das sehe, sind die HDR-Patche für Intel+LSPCON immer noch nicht im Kernel 5.10 drin (Referenz: https://patchwork.freedesktop.org/series/68081/). Weiterhin ist es hier auch sehr still um die Weiterentwicklung geworden. Besteht denn noch Interesse an der Weiterentwicklung?

Primär für mich vom Interesse wäre als Erstes die Stabilisierung des Plugins, ich bekomme es recht leicht zum Aufhängen. Auch die neue libplacebo-Version scheint sehr interessant zu werden.

D.

Quote from ofenheizer

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

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

Ja, das ist das, was ich meinte: technisch korrekt: Aber 2.4.3 war kein stable release und wenn jetzt die Plugins .2.4.3 als Suffix haben, vdr aber 2.4.4, ist das etwas verwirrend. Ich denke, es ist einfacher, bei so wenigen Releases die Versionsnummern synchron zu halten. Hat Klaus selbst bei der 2.4.0 gemacht (die glaube ich API-kompatibel zur letzten 2.3.9 ist), um Verwirrung zu vermeiden.

Was mir aufgefallen ist: VDR-Version ist 2.4.4, API-Version ist 2.4.3. Ist technisch bestimmt korrekt, aus Konsistenzgründen würde ich aber vorschlagen, dass die API-Version der VDR-Version entspricht. Denk' doch bitte an die Distris, die die Plugins alle neu übersetzen.

Dirk

Hallo jojo61,

ich habe Dir gerade einen neuen Pull-Request eingestellt, wo ich die Aspect/Crop Funktion überarbeitet habe. Es gibt jetzt keine Rundungsfehler mehr, außerdem wird die Funktion jetzt nur noch so oft wie nötig aufgerufen (wenn noch kein Input da ist, kann man wieder aussteigen). Weiterhin habe ich einen neuen Aspect-Modus "Original" eingeführt, der das Bild unskaliert ausgibt (Pixelratio habe ich allerdings vorher korrigiert). Wäre schön, wenn Du dem Pull-Request zustimmen würdest.

Zork

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:

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

Neuen Pull-Request erstellt, reindent aller Sourcen gemäß common style (wie in anderen Plugins). .indent.pro ist mit eingecheckt, sollte für zukünftige Arbeiten alles etwas übersichtlicher machen.

zork

Ich habe mal angefangen, Deinen Code etwas zu bereinigen und Dir einen pull request geschickt. Ich habe da noch einige Ideen für weitere Bereinigungen und Erweiterungen, würde aber, bevor ich Arbeit investiere, wissen, ob Dir so ein Vorgehen recht ist. Ich finde Dein Plugin sehr gut, es scheint mir auch das Einzige in dem Bereich zu sein, was aktiv weiterentwickelt wird. Interessieren würde mich eine Wayland-EGL Integration.

zork

Die letzte Version habe ich mit vaapi/EGL getestet. Spulen und springen in Aufnahmen geht jetzt, top! Habe mal Skin testweise auf skindesigner (mit deinem Patch) umgestellt, verhält sich aber auch komisch. Das Rendering von einigen Buchstaben funktioniert da nicht, weiterhin hängt er sich dann noch kurzer Zeit auf. Ich habe außerdem folgenden Bug gefunden: PIP aktivieren, dann wieder deaktivieren -> Bild bleibt grün.

zork

Hi,

ich teste gerade softhdvaapi unter Fedora 31. vaapi/egl und vaapi/libplacebo funktionieren beide grundsätzlich. CPU-Load ist bei allen drei Varianten (egl, libplacebo/binlinear und dem gepatchten softhddevice (letzte Version von pesintta, bevor es vaapidevice wurde...)) bei RTL HD ähnlich hoch. Debuglog (egl):

In Aufnahmen kann man leider nicht richtig vorspulen/springen, da hängt die Ausgabe für ca. 30sec oder hängt sich komplett weg!

Wenn mein Skin "skinflatplus" aktiviert ist, startet die egl-Version erst gar, mit libplacebo manchmal, manchmal mit SIGSEGV, anbei die Meldung, wenn es mal startet:

Wie ich das jetzt debuggen soll, weiß ich leider nicht. Wenn das Plugin mit dem Spulen zurechtkommt und das Problem mit skinflatplus geklärt ist, fehlt nicht mehr viel, dass man es praktisch auch mit Intel benutzen kann.

Hallo Klaus,

ich empfehle Dir direkt zwei Switche zu nehmen, die einen SFP+-Port haben, z.B. den Netgear GS110TP. Als Kabeltyp empfiehlt sich bei der kurzen Strecke Multimode. Das kannst du fertig konfektioniert kaufen. Der Abschluss ist dann auf beiden Seiten LC. Für den Switch kaufst Du entweder die Original-SFP+ Module von Netgear, OEM-Module kosten aber unter 20,- EUR, die funktionieren auch.

Dirk

Zurückspulen und Umschalten zwischen den Sendern funktioniert problemlos mit den Settings und ffmpeg 2.7.2.

Quote from ebsi

gut wäre wenn du einen gdb backtrace nachen könntest.

Starte xine mit :

gdb --args xine --no-logo --no-gui --verbose -V vaapi /srv/video/24/24/2010-09-25.23.13.40-0.rec/00001.ts

wenn xine hängt einfach "strg +c" drücken. Danach im gdb "thread apply all bt" eingeben. Den backtace bitte posten.

lg

ebsi

Display More

Yupp, anbei.

Zork