vaapidevice: OSD beim Start erst zu klein; Pixelsalat

Bei meiner o.g. Konfiguration (auch J4105-ITX) habe ich keine Probleme mit DVB-T aus Tschechien feststellen können. Evtl. probierst Du mal das benannte softhddevice-Plugin.

DVB-Kartenprobleme kannst Du ausschließen - z.B. als Stream läuft es?

dad401 danke für Ihre Gedanken und hilfreiche Vorschläge Leider habe ich gestern abend nicht geschafft, den aktuellen softhddevice-Plugin zu ausprobieren - nächste Chance heute Abend.

Wie mehrere Leute mir hingewiesen haben, auf der Buffering in dem vaapidevice-Plugin wurde vor manchen Monaten etwas gearbeitet und manche Patches in dieser Richtung haben auch in dem dvbsky-Treiber passiert (meinen zweien USB Dongeln entsprechend - daher auch der 5.4.x Kernel).

Streaming habe ich auch noch nicht ausprobiert - das muss noch warten. Es gibt mehrere Kleinigkeiten die ich noch lösen möchte - und ehrlich gesagt der Pixelsalat ist das kleinste Problem, das größtenteils beim Ende Januar verschwinden wird, weil es keine DVB-T Mehr geben wird Prag ist seit dem Ende Novembers schon an T2 umgeschaltet, hier im Norden erwarten wir das in ca drei Wochen. Die Frage sicher schwebt, ob ich den VDR (oder manchen anderen Player) mit meinen alten MPEG2 Aufnahmen künftig verwenden kann, und ob der Pixelsalat für andere "Playback-Weisen" auch gilt. Das muss ich noch alles ausprobieren.

Also ich habe mich endlich etwas bewegt. Durch der Wochenende habe ich den softhdcuvid ausprobiert - namentlich die Variante softhdvaapi ohne libplacebo. Und es arbeitet ganz gut! Oberflächliche Unterschiede zwischen vaapidevice und softhdvaapi, in meinem Fall:

VAAPIDEVICE

Das aktuelle vaapidevice leidet gelegentlich an den Pixelsalat - bei Umschaltung unter MPEG2 Programme, wie früher beschrieben. Anders arbeitet es ganz gut, z.b. keine Probleme mit dem auftauchen des Window Managers in dem Full Screen Mode, und flüssig ist es auch genug. Und, es hat den eigenen "debug Ausgang" = die ca 3 Zeile durch dem Playback, mit etwas detaillierten Daten über dem spielenden Programm. Es ist auch stabil - unter normalen Umständen hat es nie gestorben oder gefroren. Bei dem Start bleibt das Menü durch ein paar Sekunden in manchem "leeren" Status, aber das beleidigt mich nicht. Während des Betriebs, spielend MPEG2 576i oder H.265 540p, frisst vaapidevice ca 13% der J4105 CPU (durchschnitt der allen Kernen). Deinterlacing auf 576i arbeitet nur in dem "bob" mode (Deinterlace=1) und die obige Pixelreihe flimmert. Das weave=2 mode arbeitet nicht (artefakte sichtbar), und bei dem "motion dynamic = 4" mode stirbt VDR nach einen paar Kanal-Umschaltungen.

SOFTHDVAAPI

Das aktuelle softhdcuvid ergibt nie jeglichen Pixelsalat, und war bisher unbedingt stabil. Hat mir nie gefroren oder gestorben. Wann/wenn ich VDR aus einem Terminalfenster auf dem XFCE Desktop starte, und in den FullScreen umschalte, habe ich jedesmal das Problem daß beim ersten verwenden der Tastatur, der Terminal über dem FullScreen auftaucht. Ich muss das Terminalfenster minimisieren, dann ist typisch alles in Ordnung. Es hat mir auch einmal passiert, daß die XFCE "Leiste" (taskbar) aufgetaucht hat - und wollte nicht wieder verschwinden, sondern wann ich das VDR Fenster als "always on top" bezeichnet habe. Es gibt unter dem softhdcuvid keinen "on-screen Debug Ausgang", aber das is kein großes Problem, der Femon zeigt die wichtigste Info auch und man braucht das normalweise nicht, wann alles korrekt konfiguriert ist. Bei dem Start bleibt das Bild durch ein paar Sekunden schwarz und ohne Menü - kein Problem. Während des Betriebs, spielend MPEG2 576i oder H.265 540p, frisst softhdvaapi ca 7-9% der J4105 CPU (durchschnitt der allen Kernen) = ist sparsamer als das vaapidevice ! Deinterlacing auf 576i arbeitet in dem "bob" oder "weave" mode (Deinterlace=0 oder 1) und die obige Pixelreihe ist immer in Ordnung (flimmert nicht). Andere Modi des Deinterlacers habe ich nicht ausprobiert, weil die Anleitung sagt daß sie nicht arbeiten.

Ich habe leider derzeit keinen Multiplex mit HD Material, nur SD. Das wird sich im ende Januar verbessern.

Also die CPU-Load Ziffern entsprechen meiner Situation, wo das empfangene Material in 576i oder 540i auf einen Full-HD Bildschirm skaliert wird - durch HW Offload, denke ich? Und, im Sommer mit vaapidevice erinnere ich mich, daß es damals einen HD Kanal gab, und daß er ganz flüssig/glatt war.

Noch eine Bemerkung zu dem HDMI Ausgang:

Mein Fernseher - etwas billiges von Vestel - hat die Full-HD Auflösung (1920x1080), und die über DDC übermittelten EDID Daten enthalten 1080i@50/60Hz, aber 1080p nur auf 24/25/30 Hz = der Fernseher gesteht keine Fähigkeit von 1080p auf 50 oder 60 Hz. Es ist üblich und bekannt, daß in solchen Fällen der Fenseher die höhere Bild-Frequenzen oft eigentlich unterstützt (z.B. auf VGA Eingang sind sie sondern von meinem Fernseher angeboten). Darum habe ich die übliche Lösung angewendet, wo man eine Modeline durch xorg.conf erzwingen kann. Ich habe eine Modeline "selbst" kalkuliert = mithilfe umc --cvt generiert. (Spezifisch nicht CVT-R). Dot clock cca 141.5 MHz. Mit dieser Modeline sah mir das Bild in X (XFCE) etwas verwischt aus - etwa wie bei analogem VGA mit unpassender Auflösung. Die Buchstaben in Xterm waren etwas unklar usw. Aber die äusere Geometrie des Bildes passte auf meinen Bildschirm, und der Fernseher meldete 1080p@50, darum arbeitete ich damit. Ich habe bemerkt daß xrandr meldete 1080p@49.97 oder soetwas, d.h. etwas ungleich 50 Hz.

Später, während ich mit vaapidevice und softhdvaapi spielte, und die zwei Plugins zu vergleichen versuchte, habe ich in dem Bild etwas unregelmässiges beobachtet. Etwa wie mikroskopisches Zittern. Besonders sichtbar durch Video-Sequenzen wo sich manche scharfe Kante oder Rand in dem Bild langsam bewegt. Cca jede Sekunde würde der Playback winzig "stottern". Bei dem vaapidevice war es scharf und momentan, etwa wie ein Bild "ausser Sequenz". Bei dem softhdvaapi sah es eher aus, als wenn der Playback durch einem Augenblick langsamer und dan wieder schneller ging... Und es ist oft schwierig zu unterscheiden, ob der "Stotter-Effekt" in dem Video-Material ist, oder in dem lokalen System entsteht - weil es in dem Material wirklich solche Effekte gibt (oft grober als mein lokaler Video-Mode-Defekt - siehe unten).

Interessant war, das der Stotter-Effekt von der CPU-Belastung ganz unabhängig war. Ich konnte im hintergrund FFMPEG mit make -j 4 kompilieren, und das Video lief ohne jegliches Problem weiter - nur der Stotter-Effekt war immer da.

Also unter den verschiedenen Sachen die ich testen wollte, es kamm die Zeit noch mit der Modeline etwas zu spekulieren In diesem Forum (dvb-portal.de) habe ich eine andere Modeline getroffen - und ich werde sie hier wortgleich wiederholen:

ModeLine "1920x1080@50" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync

Der leere Rahmen (unsichtbar, rund um dem Bildschirm) ist bedeutsam grösser als in meinem CVT Mode, und auch die "dot clock" ist entsprechend höher. Das Bild auf meinem Fernseher ist jetzt sichtbar schärfer Die Terminal-Buchstaben sind 100% scharf.

Und am wichtigsten: das regelmässige sekündliche Stottern ist weg

Also ich habe jetzt zwei funktionierende Ausgang-Plugins: vaapidevice und softhdvaapi. Beide mit HW-offload. Dast ist doch toll!

Die ältere Version des vaapidevice, vor dem "Umbau der Buffers", habe ich ehrlich nicht getestet. Ich kann, wenn das jemanden noch interessiert. Ehrlich gesagt möchte ich mich jetzt auf andere Probleme rund um den HTPC konzentrieren Ich wollte noch lirc untersuchen, ich möchte die Tuner-Dongeln endlich in das Gehäuse einbauen (zuerst habe ich vor, sie aus dem Kunststoff knacken und bessere Kühlung ihnen zu geben), auf meinem RTLSDR-Skyline gibt es noch auch manche Arbeit usw.