vaapidevice: OSD beim Start erst zu klein; Pixelsalat

  • 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?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • 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.

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • Der Revisionsstand 6372704835b62bee882feed92686edc75e70b55f vom vaapidevice kompiliert bei mir nicht:


    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • 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 !

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • 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


    Quote

    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.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • 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.

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • 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?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD


  • 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.

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • 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


    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • und Artefakte huschen weiterhin gelegentlich durchs Bild

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • 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:



    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.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • 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:

    My VDRs:

  • 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    

    Yavdr auf Yammy / 2 Kabel Empfänger / Asrock j4105-itx / IRMP KDB

  • 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

  • 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.


    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.

    Files

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Hi,

    Du kannst auch mal das neue softhdcuvid mit vaapi versuchen.

    S. Entsprechenden Thread hier im Forum.


    Seahawks ppa enthält das.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • 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.

  • Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!