vaapidevice: OSD beim Start erst zu klein; Pixelsalat

Dr. Seltsam · 27. August 2019

Wie bereits unter Ubuntu 18.04 habe ich auch mit 19.04 (Kernel5.0.0-25-generic) Stabilitätsprobleme mit der Intel-Ausgabe meines neuen J4105B-ITX.

Sporadisch gibt es beim Kanalwechsel Pixelsalat.

Generell gibt es beim vdr-Start erstmal kurz ein zu kleines und in den Proportionen verzogenes OSD.

Innerhalb von einer Sekunde kommt dann das OSD in richtiger Größe, aber häufig gibt es anstelle eines Bildes Pixelsalat

Der Pixelsalat verschwindet, wenn man den Kanal umschaltet.

Häufig blitzen grüne Artefakte durch das BIld, obwohl der DVB-C-Empfänger laut femon weder UNC hat noch die BER auffällig ist.

Wenn man das setup-Menü des vaapidevice-Plugins aufruft und die bestehende Video-Konfiguration mit ok bestätigt (ohne etwas geändert zu haben) , wird das Bild dunkel. Erst nach einem Kanalwechsel hat es wieder normale Helligkeit/Kontrast.

Ich verwende das aktuelle vaapidevice aus dem git von rofafor. ffmpeg ist Version ffmpeg version 4.1.3 von Ubuntu.

Sind die beschriebenen Probleme bekannt bzw. gibt es eine Abhilfe?

Hollywood · 27. August 2019

Das ist doch das was ich hier, auch unter deiner Beteiligung , vor einem Jahr schon beschrieben habe.

Und hier geht es aktuell ebenfalls um das Problem.

Probier doch mal den von mir beschriebenen Commit vom vaapidevice und beschreib mal ob es bei dir dann, wie bei mir, besser läuft. Du hast doch fast das gleiche Board wie ich.

Dr. Seltsam · 28. August 2019

Der Revisionsstand 6372704835b62bee882feed92686edc75e70b55f vom vaapidevice kompiliert bei mir nicht:

Code

vaapidev.c: In function ‘VideoNextPacket’:
vaapidev.c:649:50: error: ‘FF_INPUT_BUFFER_PADDING_SIZE’ undeclared (first use in this function); did you mean ‘AV_INPUT_BUFFER_PADDING_SIZE’?
memset(avpkt->data + avpkt->stream_index, 0, FF_INPUT_BUFFER_PADDING_SIZE);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
AV_INPUT_BUFFER_PADDING_SIZE
vaapidev.c:649:50: note: each undeclared identifier is reported only once for each function it appears in
vaapidev.c: In function ‘PesInit’:
vaapidev.c:1197:49: error: ‘FF_INPUT_BUFFER_PADDING_SIZE’ undeclared (first use in this function); did you mean ‘AV_INPUT_BUFFER_PADDING_SIZE’?
pesdx->Buffer = av_malloc(PES_MAX_PAYLOAD + FF_INPUT_BUFFER_PADDING_SIZE);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
AV_INPUT_BUFFER_PADDING_SIZE

Alles anzeigen

FireFly · 28. August 2019

Welche ffmpeg-Library Versionen hast Du installiert? Bei mir kompiliert's mit 3.4 und 4.0

Hollywood · 28. August 2019

Du musst einfach den Compiler-Hinweisen folgen und FF_INPUT_BUFFER_PADDING_SIZE in AV_INPUT_BUFFER_PADDING_SIZE in den Zeilen 649 und 1197 umbenennen.

Wahrscheinlich kommt da dann noch eine ähnliche Meldung in codec.c !

Dr. Seltsam · 28. August 2019

Danke, das hat funktioniert. In code.cmusste CODEC_CAP_HWACCEL noch durch AV_CODEC_CAP_HARDWARE ersetzt werden.

Wenn der vdr auf einem SD-Kanal startet, kommt das grüne Pixelgewitter jetzt nicht mehr (es kam vorher auf HD-Kanälen meistens -vielleicht sogar immer- auch nicht). Das OSD ist weiterhin beim Start nicht gleich in richtiger Größe vorhanden.

Dazu habe ich hier übrigens etwas gefunden:

https://github.com/pesintta/vdr-plugin-vaapidevice/pull/122

Zitat

TODO:

black surface should be displayed if no video data available

initial osd not drawn at startup

ffmpeg stream info issues with some test recordings and rofafor#4

occasional lip sync issues with huge negative A/V drift values

Ob der Rest besser läuft, muss ich morgen testen.

Bislang kann ich noch nicht erkennen, warum ich nicht einfach wieder meine Nvidia-Karte einstecken sollte und mit einem älteren ffmpeg und VDPAU weiterarbeite. Das hat wenigstens stabil funktioniert, und das Bild war auch brillianter.

Hollywood · 28. August 2019

Bei mir gibt es direkt nach dem Start gleich ein korrekt positioniertes OSD. Hast du Xorg auf UHD oder HD eingestellt ?

Die Skalierung muss ich auf Fast oder Normal stellen, sonst wird es asynchron und die komplette Bedienung des VDR um einiges zäher. Deinterlacer habe ich auf Motion Adaptive eingestellt.

Dr. Seltsam · 28. August 2019

xorg läuft auf 1920x1080@50. Dieses OSD-Problem hatte ich mit softhddevice übrigens nicht.

Die Skalierung steht auf normal, und ich habe sowohl Bob als auch Motion Adaptive probiert. Asynchronitäten habe ich ebenfalls.

Zwischen 20.02.18 und Anfang März gab es im vaapidevice so viele Umbaumaßnahmen, dass es schwer werden wird herauszufinden, ob und welcher einzelne commit die Ursache ist.

Was mich mal interessieren würde: Was für Versionen von Plugin, ffmpeg benutzen denn die Leute, die von der Intel-Ausgabe so schwärmen, und was sagt dort vainfo?

Hollywood · 28. August 2019

Zitat von Dr. Seltsam

Zwischen 20.02.18 und Anfang März gab es im vaapidevice so viele Umbaumaßnahmen, dass es schwer werden wird herauszufinden, ob und welcher einzelne commit die Ursache ist.

Ja die Änderungen scheinen mir auch recht umfangreich, mich wunderte das jojo61 in dem anderen Thread sagte, dass dort nur etwas am Buffermanagement gebastelt wurde und die Änderungen keinen Einfluß auf die Dekodierung haben. Ich hatte Hoffnung das er vielleicht anhand der Commits sehen könnte in welchem Bereich es hakt, aber vielleicht haben wir da irgendwie aneinander vorbei geredet.

Dr. Seltsam · 28. August 2019

richtig stabil läuft das leider auch nicht.

Mittendrin beim Live-TV wird das Bild plötzlich schwarz und kommt auch nach dem Umschalten nicht wieder

Code

Aug 28 23:08:39 ubuntuvdr1 vdr: [1041] switching to channel 22 C-61441-10014-10355 (hr-fernsehen HD)
Aug 28 23:08:39 ubuntuvdr1 vdr: [2037] osdteletext-receiver thread ended (pid=1041, tid=2037)
Aug 28 23:08:39 ubuntuvdr1 vdr: [1041] buffer stats: 0 (0%) used
Aug 28 23:08:39 ubuntuvdr1 vdr: [2036] device 1 TS buffer thread ended (pid=1041, tid=2036)
Aug 28 23:08:39 ubuntuvdr1 vdr: [2035] buffer stats: 112988 (2%) used
Aug 28 23:08:39 ubuntuvdr1 vdr: [2035] device 1 receiver thread ended (pid=1041, tid=2035)
Aug 28 23:08:39 ubuntuvdr1 kernel: [  852.599259] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0
Aug 28 23:08:39 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:08:39 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (34869/96) 0 v-buf
Aug 28 23:08:39 ubuntuvdr1 vdr: [2041] device 1 receiver thread started (pid=1041, tid=2041, prio=high)
Aug 28 23:08:39 ubuntuvdr1 vdr: [1041] creating directory /var/cache/vdr/vtx/C-61441-10014-10355
Aug 28 23:08:39 ubuntuvdr1 vdr: [2042] device 1 TS buffer thread started (pid=1041, tid=2042, prio=high)
Aug 28 23:08:39 ubuntuvdr1 vdr: [2043] osdteletext-receiver thread started (pid=1041, tid=2043, prio=high)
Aug 28 23:08:39 ubuntuvdr1 vdr: [1041] DvbapiInfoDraw
Aug 28 23:08:40 ubuntuvdr1 vdr: message repeated 3 times: [ [1041] DvbapiInfoDraw]
Aug 28 23:08:41 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:08:41 ubuntuvdr1 vdr: [1041] DvbapiInfoDraw
Aug 28 23:08:44 ubuntuvdr1 vdr: message repeated 5 times: [ [1041] DvbapiInfoDraw]
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (37601/2735) 0 v-buf
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (37612/2744) 0 v-buf
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (37621/2751) 0 v-buf
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (37623/2751) 0 v-buf
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (37632/2758) 0 v-buf
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (37634/2758) 0 v-buf
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (37641/2763) 0 v-buf
Aug 28 23:09:35 ubuntuvdr1 vdr: video: slow down video, duping frame
Aug 28 23:09:35 ubuntuvdr1 vdr: video: decoder buffer empty, duping frame (37643/2763) 0 v-buf

Alles anzeigen

Dr. Seltsam · 28. August 2019

und Artefakte huschen weiterhin gelegentlich durchs Bild

Dr. Seltsam · 14. September 2019

Ich bin hier am verzweifeln. kls sagt, dass das vaapidevice mit git-Stand 18.November 2018 bei ihm auf dem J4105M stabil funktioniert. Ich hatte zeitweilig sogar seine Umgebung (openSUSE 15.0. mit manuell installierten libva und intel-vaapi-driver aus dem git von Intel sowie ffmpeg 4.0) installiert, habe dort aber die gleichen Probleme und bin wieder zurück auf derzeit Xubuntu 19.04., das aber gegenüber 18.04. keine Verbesserung brachte - allenfalls die Bildqualität hat sich in Punkto Detailschärfe möglicherweise etwas verbessert.

Auch ein Versuch unter Xubuntu 19.10 ergab die gleichen Probleme.

Ich habe jeweils sowohl die libva+Treiber von Ubuntu als auch jeweils die neuesten aus dem gut probiert. Ebenfalls verschiedene Versionen von ffmpeg.

Fazit ist weiterhin:

vdr mit softhddevice oder vaapidevice bis 20.02.18 laufen mit Einschränkungen (alle paar Minuten sausen Artefakte durchs Bild oder das BIld bleibt stehen/wird schwarz)
Das aktuelle vaapidevice läuft grottig - bei SD-Sendern gibt es gelegentlich beim Umschalten und generell, wenn vdr auf einem SD-Kanal startet, Pixelsalat.

Der x-server läuft auf 1920x1080 mit dieser xorg.conf:

Code

ection "ServerFlags"
Option         "NoPM" "true"
Option         "BlankTime" "0"
Option         "StandbyTime" "0"
Option         "SuspendTime" "0"
Option         "OffTime" "0"
Option         "Xinerama" "0"
Option         "DontZap" "1"
Option         "DontZoom" "1"
Option         "DPMS"  "false"
Option         "AllowMouseOpenFail"  "false"
EndSection
Section "Monitor"
Identifier     "HDMI-1"
HorizSync       15.0 - 68.0
VertRefresh     23.0 - 61.0
ModeLine       "1920x1080@50p" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
EndSection
Section "Screen"
Identifier     "Screen0"
Monitor        "HDMI-1"
SubSection     "Display"
Modes      "1920x1080@50p"
EndSubSection
EndSection
Section "Monitor"
Identifier     "HDMI-2"
Option         "Ignore" "true"
EndSection
Section "Monitor"
Identifier     "DP-1"
Option         "Ignore" "true"
EndSection

Alles anzeigen

Kann jemand, bei dem die Ausgabe über Intel UHD Graphics 600 (Gemini-Lake-Generation) stabil läuft, mal seine Ausgabe von vainfo (ist Teil der libva-utils) posten?

Ich suche im Moment auch noch nach einer Erklärung, warum der TV nach ein paar Minuten immer auf "no signal" schaltet, obwohl in den xfce-Einstellungen die Bildschirm-Energieverwaltung bereits aus ist. Das HDMI-Kabel geht vom Mainboard in den AVR und der Ausgang des AVR in den TV. Der AVR ist so eingestellt, dass er im Stand-by das Signal durchschleust. Das klappt beim VDR2 mit Nvidia-Grafik auch problemlos. Nur beim VDR1 mit Intel-Ausgabe verschwindet das Bild immer wieder und ich muss dann den AVR ein- und wieder ausschalten, damit es wieder beim TV ankommt.

dad401 · 14. September 2019

Ich habe das J4105-ITX und nutze softhddevice aus den YaVDR-PPA. Ich kann hier absolut nicht klagen (SD, HD und HVEC über DVB-T2). Läuft stabil.

Laut Installation wird folgende Version genutzt:

vdr-plugin-softhddevice-vdpau-hevc 0.7.0+git20180203-724-3781118-pesintta-2yavdr3~bionic

vaapidevice konnte mich damals beim Umstieg auf das J4105-System nicht so überzeugen.

Anbei noch paar Ausgaben:

Code

libva-dev:amd64                        2.1.0-3                                               amd64        Video Acceleration (VA) API for Linux -- development files
ii  libva-drm2:amd64                       2.1.0-3                                               amd64        Video Acceleration (VA) API for Linux -- DRM runtime
ii  libva-glx2:amd64                       2.1.0-3                                               amd64        Video Acceleration (VA) API for Linux -- GLX runtime
ii  libva-wayland2:amd64                   2.1.0-3                                               amd64        Video Acceleration (VA) API for Linux -- Wayland runtime
ii  libva-x11-2:amd64                      2.1.0-3                                               amd64        Video Acceleration (VA) API for Linux -- X11 runtime
ii  libva2:amd64                           2.1.0-3                                               amd64        Video Acceleration (VA) API for Linux -- runtime
ii  libvariable-magic-perl                 0.62-1                                                amd64        module to associate user-defined magic to variables from Perl
ii  chromium-codecs-ffmpeg-extra           74.0.3729.169-0ubuntu0.18.04.1                        amd64        Extra ffmpeg codecs for the Chromium Browser
ii  ffmpeg                                 7:3.4.6-0yavdr1.18.04.2                               amd64        Tools for transcoding, streaming and playing of multimedia files
ii  libavcodec-ffmpeg57                    3.3.6-0yavdr2~bionic                                  amd64        ffmpeg codec library
ii  libavutil-ffmpeg55                     3.3.6-0yavdr2~bionic                                  amd64        ffmpeg utility library
ii  libswresample-ffmpeg2                  3.3.6-0yavdr2~bionic                                  amd64        ffmpeg audio rescaling library
ii  libswscale-ffmpeg4                     3.3.6-0yavdr2~bionic                                  amd64        ffmpeg video scaling library

Alles anzeigen

Code

libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Gemini Lake - 2.1.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileH264MultiviewHigh      : VAEntrypointVLD
      VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileH264StereoHigh         : VAEntrypointEncSlice
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointEncSlice
      VAProfileVP9Profile2            : VAEntrypointVLD

Alles anzeigen

Code

# X Configuration

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "BlankTime"   "0"   # Zeit wann der Monitor Schwarz wird (Standard: 10 Minuten)
    Option         "StandbyTime" "0"   # Zeit wann der Monitor in den Standby geht (Standard: 20 Minuten)
    Option         "SuspendTime" "0"   # Zeit wann der Monitor in den Suspend geht (Standard: 30 Minuten)
    Option         "OffTime"     "0"   # Zeit wann sich der Monitor abschaltet (Standard: 40 Minuten)
EndSection

Section "Files"
EndSection

Section "Extensions"
    Option      "Composite"     "Disable"
    Option      "DPMS"          "Disable"
EndSection

Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "type1"
    Load           "freetype"
    Load           "glx"
EndSection

Section "ServerFlags"
    Option         "Xinerama" "0"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
        Identifier      "Keyboard0"
        Driver          "kbd"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "de"
        Option          "XkbVariant"    "nodeadkeys"
EndSection

Section "Monitor"
    Identifier      "Monitor0"
    VendorName      "Samsung"
    ModelName       "Unknown"
    HorizSync       30.0 - 110.0
    VertRefresh     50.0 - 150.0
    Option         "DPMS" "False"

#     Option         "ExactModeTimingsDVI"   "true"
#     Option         "UseEDIDFreqs"          "FALSE"

    Modeline       "1920x1080@60i" 74.250 1920 2008 2052 2200 1080 1085 1095 1125 +hsync +vsync Interlace
    ModeLine       "1920x1080@50" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
    ModeLine       "1920x1080@60" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

    #DisplaySize   32 18
    Option         "DPI" "200 x 200"
    #Option        "DPI" "150 x 150"

Endsection

Section "Device"
    Identifier     "Device0"
    Driver         "intel"
    Screen         0
    Option         "Coolbits"         "1"
    Option         "NoLogo"           "False"
    Option         "ConstantDPI"      "False"
    Option         "UseEDIDDpi"       "False"
    #Option         "CustomEdid"       "HDMI1:/opt/vdr/config/edid-samsung.bin" # leads to kodi crash
    Option         "ConnectedMonitor" "HDMI1"
    Option         "UseDisplayDevice" "HDMI1"
    Option         "ExactModeTimingsDVI" "True"
    Option         "ModeValidation" "HDMI1: AllowNon60HzDFPModes,NoEdidModes,NoVesaModes,NoXServerModes,NoPredefinedModes,NoDFPNativeResolutionCheck,NoHorizSyncCheck,NoVertRefreshCheck"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Viewport    0 0
        Depth       24
        Modes      "1920x1080@50"
    EndSubSection
EndSection

Alles anzeigen

Grillbert · 21. September 2019

Hallo,
ich benutze das YaVDR ansible setup und bei mir läuft das Ganze rund mit

Code

# dpkg -l | grep softhd
vdr-plugin-softhddevice-vpp           0.7.0+git20180203-724-3781118-pesintta-1yavdr10~bionic amd64        Plugin for VDR. A software and GPU

frr · 2. Januar 2020

Zum Thema "Pixelsalat":

Bei mir passiert es, wenn ich von einem "DVB-T MPEG2 SD" Kanal nach einen anderen "DVB-T MPEG2 SD" Kanal umschalte. Bei dem ersten mal, als ich etwas mit MPEG2 wähle, läuft das Bild ausgezeichnet - aber als ich danach direkt einen anderen MPEG2 Kanal wähle, kommt unbedingt der grüne Pixelsalat. Dieses Problem gibt es gar nicht bei den T2 Muxes (alle senden H.265 HEVC HD oder QHD) und auch kein Problem bei manchen DVB-T (nicht T2 !) Kanälen die in der H.264 Kodierung laufen. Und mein "Workaround im Testbetrieb" ist, zuerst nach einem H.264 oder H.265 Kanal umzuschalten, dann kann ich wieder etwas in MPEG2 wählen...

Dies ist mein zweiter Versuch, den VDR in Betrieb zu nehmen In Mai hatte ich manchen Rechner mit Skylake, jetzt habe ich eine J4105-ITX von AsRock (= Gemini Lake ATOM). Der Pixelsalat passiert ebenso auf beiden Intel GPU's - die beiden VAAPI unterstützen. Hier in Tschechien kann ich vor meinem Ort ca 4 DVB-T Muxes und 2 DVB-T2 Muxes empfangen. Mein Ziel ist VAAPI auf der Gemini Lake Hardware zu benutzen, und VDR gefällt mir - darum versuche ich mit dem vdr-plugin-vaapidevice zu arbeiten...

Meine SW Versionen: VAAPI frisch aus dem GIT (ca 2 Wochen alt), FFMPEG/libva 4.2.1-release (4.2.2 ist ca 2 Tage alt - habe ich nicht getestet), VDR 4.2.1-release, vdr-plugin-vaapidevice aus dem Git von Rofafor (vor 2 Wochen), Debian 10, kernel 5.4.6

Dr. Seltsam · 2. Januar 2020

probier mal softhddevice oder eine ältere vaapidevice-Version. Ich füge mal die vaapidevice-Version vom 20.02.2018 bei. Da ist bereits ein Patch für neuere ffmpeg-Versionen enthalten, so dass es kompiliert.

Diff

diff -ur vaapidevice-20.02.2018-MD/codec.c vaapidevice-20.02.2018/codec.c
--- vaapidevice-20.02.2018-MD/codec.c	2019-08-28 01:12:04.000000000 +0200
+++ vaapidevice-20.02.2018/codec.c	2019-08-28 01:05:59.000000000 +0200
@@ -219,7 +219,7 @@
decoder->VideoCtx->thread_count = 1;
pthread_mutex_lock(&CodecLockMutex);
// open codec
-    if (video_codec->capabilities & (AV_CODEC_CAP_HARDWARE)) {
+    if (video_codec->capabilities & (CODEC_CAP_HWACCEL)) {
Debug(3, "codec: video mpeg hack active");
// HACK around badly placed checks in mpeg_mc_decode_init
// taken from mplayer vd_ffmpeg.c

Alles anzeigen

Damit sollte der grüne Pixelsalat nicht mehr auftreten. Trotzdem läuft es bei mir um Welten instabiler als der alte VDR mit VDPAU und Nvidia GT520. Und ein sichtbar besseres Bild liefert die Nvidia auch noch.

SurfaceCleanerZ · 2. Januar 2020

Hi,

Du kannst auch mal das neue softhdcuvid mit vaapi versuchen.

S. Entsprechenden Thread hier im Forum.

Seahawks ppa enthält das.

Mfg Stefan

frr · 2. Januar 2020

Okay danke ich werde das im Abend ausprobieren.

Ich lese noch gleich jetzt das lange Thema über dem neuen "softhdcuvid" plugin - es wundert mich ob es auf meiner HW laufen kann (reine Gemini Lake igp) = ich werde darüber unter dem entsprechenden Thema den Kollege jojo61 fragen.

SurfaceCleanerZ · 2. Januar 2020

softhdcuvid jetzt mit VAAPI und HDR support

Meinte ich!

Mfg Stefan

frr · 2. Januar 2020

Ja doch, und danke Ich bin in dem Thread auf Seite 5 aus 18 Nährungsreiches Lesen. Ich muss mich Notizen schreiben.

vaapidevice: OSD beim Start erst zu klein; Pixelsalat

Jetzt mitmachen!

Teilen