xine-plugin/xine-ui: Xorg giert nach CPU wenn tvtime deinterlacer an ist

Hi,

bevor mein neu aufgesetzter VDR wieder ins Wohnzimmer kann, gilt es noch ein *knackiges* Problem zu lösen.

Ich betreibe vdr 1.7.11 als budget-System mit xine-plugin / xine-ui (0.9.3)
Hardware siehe Signatur.
Für gute Bildqualität möchte ich einen tvtime-deinterlacer einschalten.

Problem: Sobald ich einen Deinterlacer aktiviere, z.B. so:
-Dtvtime:method=Linear,enable=1,chroma_filter=0
geht Xorg von ~40% CPU hoch auf ~ 70% d.h. bis alle Reserven aufgebraucht sind (idle = 0%).
Das xine-ui Menü ist dann nicht mehr bedienbar/extrem träge. Keine Reserven mehr für z.B. noad.

• Bei DvD bleibt die Xorg last bei ~40% CPU, egal welchen Deinterlacer ich wähle.
• Damit es zu Aussetzern wie oben geschildert kommt muß ich schon "schwerstes Geschütz" auffahren: Erst mit TomsMoComp + CromaFilter wird die Last (durch xine ~ 60%, Xorg bei 40%) zu groß. Der o.a. Linear erzeugt normalerweise nur ca 10% Last.
• Mit dem Nicht-tvtime-Filter "Denoise3D" bleibt die Xorg-Last normal.
• Bisher hatte ich meinen VDR 1.3+FF-Karte mit tvtime und Deinterlacer ohne Probleme laufen. Die CPU/HW ist definitiv stark genug!
• Der alte xine-Deinterlacer (Option -D) funktioniert ohne Probleme, taugt aber nichts.

Daraus (Mit DvD ok, mit VDR-Datenstrom geht die Xorg last hoch) mutmaße ich, das Xorg aus irgendeinem Grund pollt.

Meine Fragen:

• Hat jemand anderes auch dieses Problem oder kann es mal testen?
• Für was sind die filter --post vdr_audio und --post vdr_video gut? Bild + Ton kommen auch ohne..
• Irgendwelche Tipps? Ich bin recht ratlos....

Grüße
Ralf

Hi,

ich glaub ich bin jetzt dicht an der Ursache & Vermeidung dran
(Klingt jetzt blöd, wenige Minuten nach dem Post - Aber ich habe mich vorher schon ca. 8h mit dem Problem rumgeschlagen. Manchmal hilfts halt wenn man sich mal ausheult und das Problem aufschreibt.

Die Xorg-Last bleibt normal, wenn ich cheap_mode=1 setze.

Link Erklärung der Deinterlacer

Zitat

Cheap_mode: This will skip the expensive YV12->YUY2 image conversion, tricking tvtime/dscaler routines like if they were still handling YUY2 images. Of course, this is not correct, not all pixels will be evaluated by the algorithms to decide the regions to deinterlace and chroma will be processed separately. Nevertheless, it allows people with not so fast systems to try deinterlace algorithms, in a tradeoff between quality and cpu usage.

Ich hätte die Last für YV12->YUY2 bei xine erwartet (vielleicht ist sie da auch noch?), dass sie bei Xorg Auftritt sieht mir danach aus daß ich keine YUY2 Hardware-Unterstützung habe und das aufwändig in Software zurückgerechnet wird....

xine-check meldet:

[ good ] found xvinfo: X-Video Extension version 2.2
[ good ] your Xv extension supports YV12 overlays (improves MPEG performance)
[ good ] your Xv extension supports YUY2 overlays
[ good ] Xv ports: YUY2 YV12 I420 UYVY

Grüße
Ralf

Hi,

erstmal danke für das Feedback!
Ich werde die einzelnen angesprochenen Punkte noch untersuchen.

Ich hab mir einen Benchmark gebastelt. -> Im Anhang
Zum einen kann ich damit einfach immer wieder die gleichen Sequenzen anschauen und die Qualität vergleichen, zum anderen gibt es vergleichbare CPU Kosten aus.

Die Ergebnisse finde ich bemerkenswert und überraschend, höchster Aufwand bedeutet nicht höchste Qualität, im Gegenteil!

Mein Favorit: ScalerBob:
xorg Last : 17%
xine Last : 15%
Summe Last: 32%
Bildqualität gut
An den bewegten Rändern etwas unscharf
Warum ist die xorg last so niedrig? Normal sind ~ 40%

Die Tests liefen natürlich mehrfach und liefern konstante Ergebnisse.

P.S: Zusätzlich habe ich mir noch ein paar Standbilder (Schnittmarken mit VDR angefahren) angeschaut. Manches sieht da echt grauselig aus....

Hat jemand eine Idee wie man das im Bench (ohne VDR) automatisieren könnte?
Man müsste einen Snapshot an einem ganz bestimmten Frame schiessen.

Als nächstes werde ich mal mit Athlon K7 Optionen kompilieren, und das MTRR sieht mir zu klein aus.

xine standard
-------------


video="/video/@Wintersport_Biathlon-Weltcup_7,5km_Sprint_Damen/2010-01-13.18.06.2-0.rec/00001.ts"
xine_param_std="--post upmix"
xine_param_test="--post tvtime:method=ScalerBob,enable=1,chroma_filter=0,cheap_mode=1"
xine $xine_param_std $xine_param_test $video & 


Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=Linear,enable=1,chroma_filter=0,cheap_mode=1
xorg elapsed: 2190 hs
xine elapsed: 1163 hs
xorg Last : 36%
xine Last : 19%
Summe Last: 55%


Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=Linear,enable=1,chroma_filter=0,cheap_mode=0
xorg elapsed: 3681 hs
xine elapsed: 1465 hs
xorg Last : 61%
xine Last : 24%
Summe Last: 85%
Warnung von xine


Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=Greedy,enable=1,chroma_filter=0,cheap_mode=1
xorg elapsed: 2147 hs
xine elapsed: 1002 hs
xorg Last : 35%
xine Last : 16%
Summe Last: 51%
Unruhiges Bild, subjektiv schlechter als "Linear"
An den bewegten Rändern leicht ausgefranst


--- Favorit ------------------------------------
Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=ScalerBob,enable=1,chroma_filter=0,cheap_mode=1
xorg elapsed: 1061 hs
xine elapsed: 908 hs
xorg Last : 17%
xine Last : 15%
Summe Last: 32%
Bildqualität gut
An den bewegten Rändern etwas unscharf
Warum ist die xorg last so niedrig?
------------------------------------------------


Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=ScalerBob,enable=1,chroma_filter=0,cheap_mode=0
xorg elapsed: 2520 hs
xine elapsed: 1181 hs
xorg Last : 42%
xine Last : 19%
Summe Last: 61%
YV12->YUY2 Konvertierung (cheap_mode=0) kostet hier 30%


Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=GreedyH,enable=1,chroma_filter=0,cheap_mode=1
xorg elapsed: 2278 hs
xine elapsed: 1109 hs
xorg Last : 37%
xine Last : 18%
Summe Last: 55%
Bildqualität gut


Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=GreedyH,enable=1,chroma_filter=0,cheap_mode=0
xorg elapsed: 3329 hs
xine elapsed: 1846 hs
xorg Last : 55%
xine Last : 30%
Summe Last: 85%
YV12->YUY2 Konvertierung (cheap_mode=0) kostet hier 30%


Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=TomsMoComp,enable=1,chroma_filter=0,cheap_mode=1
xorg elapsed: 2115 hs
xine elapsed: 1474 hs
xorg Last : 35%
xine Last : 24%
Summe Last: 59%
Schnell bewegte feine Strukturen (Haare) flimmern. Im Standbild deutliche Pixelfehler.


Laufzeit Test: 60 s
Test Parameter: --post tvtime:method=TomsMoComp,enable=1,chroma_filter=0,cheap_mode=0
xorg elapsed: 2418 hs
xine elapsed: 2764 hs
xorg Last : 40%
xine Last : 46%
Summe Last: 86%
Kommentar dto., d.h. cheap_mode=0 bringt hier nichts.

Grüße
Ralf

Zitat

Original von fnu

Hehe, tatsächlich hat mich dieser Parameter interessiert, denn hattest Du oben "verschluckt".

Nun, xorg ist wohl nicht ganz unbeteiligt, da xine das Video-Material an Xorg und Grafiktreiber weitergibt, das wäre die andere Frage von mir gewesen, wie rufst Du xine auf? Also mit welchem Video-Out Modus?

Viel Erfolg noch.

Gruß
Frank

Alles anzeigen

Hi Frank,

xine gibt über xv aus.
Leider wird nicht angegeben auf welchen Xv port: YUY2 YV12 I420 UYVY

Grüße
Ralf

Zitat

Original von fnu
@RalfDietz

Dann poste doch mal Deinen xine-Aufruf in seiner Gänze und alle tvtime Optionen die Du gewählt hast, das ist ja nur ein Auschnitt.

Entspricht die genutze Software immer noch Deiner Signatur?

Hast Du irgendwelche Buffer Einstellungen im xine-plugin oder xine-ui (~/.xine/config) vorgenommen?

Gruß
Frank

Alles anzeigen

Hi,

ja, SW & HW entsprechen der Signatur. Die FF-Karte ist deaktiviert.
Buffer von xine hab ich noch nicht verstellt. Ich weiss das die vdpau'ler (HD) dran drehen müssen, aber das ist ja was anderes, oder?

Apropos HD: Sehr interessant! HD Benchmark