xinliboutput - leichtes Ruckeln - Ursachenforschung

[Wicky]

Hallo zusammen,

etliche der xinliboutput User haben ein leichtes Ruckeln bei Laufschriften und schnellen Kamerafahrten festgestellt.

Die Beabachtungen und Ursachenforschung beginnt sich gerade in verschiedenen Threads abzuspielen. Ich denke wir sollten das Thema in diesem Thread bündeln.

Gesammelte Beobachtungen zum Thema

Vergleich 50Hz Ausgabe zu 60Hz Ausgabe:
Das beschriebene Problem tritt gleichermaßen bei 60Hz als auch bei 50Hz Ausgabe auf !!!
Eine 50Hz/60Hz Problematik liegt also nicht vor !!

Vergleich XV zu XVMC:

XV:
- Bei schnell bewegtem TV-Bild ruckelt das Bild sichtbar (z.B. Ski-Springen bei der Anfart auf dem Sprungtisch, Fußball)
- Laufschriften ruckeln sichtbar. Aber die Ruckelabstände sind nicht periodisch !!
- goom ruckelt massiv

XVMC
- Bei schnell bewegtem TV-Bild ruckelt das Bild nicht mehr.
- Laufschriften ruckeln nur leicht. Die Ruckelabstände sind fast periodisch !!
- goom läuft absolut flüssig

Messwerte:
1) CPU-Auslastung XV
2) CPU-Auslatung XVMC + VLD
3) hdparm -tT /dev/hd?? bei laufendem VDR
4) hdparm -tT /dev/hd?? bei nicht laufendem VDR

System1: bromberwilli, M2N-HDMI, DVB-S, CPU ??, ondemand-governor
1)  ~ 40%
2) ~ 20%
3) 330MB/sec, 38,46MB/sec   
4) 572MB/sec, 53MB/sec
Ruckelverhalten:
a) xineliboutput-XV: ??
b) xineliboutput-XVMC: ??
c) softdevice-XV: ??
d) softdevice-XVMC: ??

System2: bromberwilli, M2N-HDMI, DVB-S, CPU ??, performance-governor
1) ~ 11%
2) ~ 9%
3) ??
4) ??
Ruckelverhalten:
a) xineliboutput-XV: ??
b) xineliboutput-XVMC: ??
c) softdevice-XV: ??
d) softdevice-XVMC: ??

System3, bromberwilli, Epox EP-8RDA3+,XP2500+,512MB,Geforce4 MX440
1) ~14%
2) ~26%
3) 381MB/sec, 57MB/sec   
4) 445MB/sec, 57MB/sec

Ruckelverhalten:
a) xineliboutput-XV: ??
b) xineliboutput-XVMC: ??
c) softdevice-XV: ??
d) softdevice-XVMC: ??

@all Eventuell sollten  wir im easyvdr-wiki einen temporären Artikel zum Thema öffnen und dort die Beobachtungen systematisch, also in einheitlicher Form und kategorisiert, in Tabellen sammeln.

Zur Ursachen Forschung:
Mögliche Ursachen, die mir in den Kopf kommen:
A) Der DDR2-Speicher ist für die onboard-Grafik nicht schnell genug.
B) Die Grafikkarte ist nicht performant genug.
C) xineliboutput/xine/sfxe sind ineffektiv und einzelne Bearbeitungsschritte werden nicht schnell genug ausgeführt, so dass es gelegentlich zu Rucklern kommt.
D) xineliboutput/xine/sfxe arbeitet qualitativ nicht gut genug und eines der Programme baut bei einem Bearbeitungsschritt Ruckler in die VideoDaten ein.

Ausschlussverfahren:

zu A) Wenn meine CPU @1GHz läuft, so sinkt der DDR2-Datendurchsatz um 50% im Vergleich zur Tacktung bei 2,2GHz. Dies hat jedoch so gut wie keinen Einfluss auf das Ruckeln -> Der DDR2-Speicher scheint nicht der Flaschenhals zu sein.
-> Eventuell sollte man hier aber noch genauer forschen: Verstärkt sich das Ruckeln, wenn man eine hdparm Messung durchführt?

zu B) @all Treten die oben beschriebenen Effekte auch mit leistungsfähigeren Nvidia-Grafikkarten auf? Details !!
Die onboard-Grafik des M2N-HDMI ist bereits etwas leistungsfähiger als die des M2NPV-VM, dennoch trete die selben Effekte auf. Muss die Grafik eventuell noch leistungsfähiger sein?

zu C) Ich habe keine Idee, wie man xineliboutput diesbezüglich auf den Zahn fühlen könnte.
Aber ich habe diesbezüglich eine andere wichtige Information: Wenn man softdevice verwendet, so ruckelt absolut nichts !!!
Leider ist es mir momentan auf meinem System nicht möglich softdevice zum laufen zu bringen. Ich kann diese Beobachtung daher z.Z. nicht näher untersuchen.

@maxx und all
Ich halte es für sehr wertvoll, wenn wir nocheinmal überprüfen würden, ob das Ruckeln mit softdevice verschwindet !!!

Bis denne,
Wicky

[brombeerwilli]

aktualisierte Messwerteandere Festplatte)
1) CPU-Auslastung XV
2) CPU-Auslatung XVMC + VLD
3) hdparm -tT /dev/hd?? bei laufendem VDR
4) hdparm -tT /dev/hd?? bei nicht laufendem VDR

System1: bromberwilli, M2N-HDMI, DVB-S, CPU BE-2350,HDMI-HDMI [email protected] ondemand-governor
1)  ~ 40%
2) ~ 20%
3) 515MB/sec, 49MB/sec 
4) 579MB/sec, 49MB/sec
Ruckelverhalten:
a) xineliboutput-XV: ruckelt(Audio-Aussetzer wenn Laufschrift vorhanden)
b) xineliboutput-XVMC: ruckelt etwas weniger(stärkere Audio-Aussetzer wenn Laufschrift vorhanden)
c) softdevice-XV: läuft noch nicht
d) softdevice-XVMC: läuft noch nicht

System2: bromberwilli, M2N-HDMI, DVB-S, CPU BE-2350,HDMI-HDMI [email protected]  performance-governor
1) ~ 11%
2) ~ 9%
3) 761MB/sec, 49MB/sec
4) 833MB/sec, 49MB/sec
Ruckelverhalten:
a) xineliboutput-XV: ruckelt(Audio-Aussetzer wenn Laufschrift vorhanden
b) xineliboutput-XVMC: ruckelt etwas weniger(stärkere Audio-Aussetzer wenn Laufschrift vorhanden)
c) softdevice-XV: läuft noch nicht
d) softdevice-XVMC: läuft noch nicht

System3: bromberwilli, M2N-HDMI, DVB-S, CPU BE-2350,VGA [email protected] ondemand-governor
1)  ~ 29%
2) ~ 15%
3) 510MB/sec, 49MB/sec 
4) 578MB/sec, 49MB/sec
Ruckelverhalten: wie bei System 1

System4: bromberwilli, M2N-HDMI, DVB-S, CPU BE-2350,VGA [email protected] performance-governor
1)  ~ 13%
2) ~ 10%
3) 701MB/sec, 49MB/sec 
4) 766MB/sec, 49MB/sec
Ruckelverhalten: wie bei System 2


System5, bromberwilli, Epox EP-8RDA3+,XP2500+,512MB,Geforce4 MX440,DVI-HDMI [email protected](Bildqualität schlechter als FBAS von FF, Graka macht "überforderten" Eindruck)
1) ~14%
2) ~26%
3) 381MB/sec, 57MB/sec 
4) 445MB/sec, 57MB/sec
Ruckelverhalten:
a) xineliboutput-XV: ruckelt schon stärker(Audio siehe oben)
b) xineliboutput-XVMC: ruckelt etwas weniger stark(Audio siehe oben)
c) softdevice-XV: läuft noch nicht
d) softdevice-XVMC: läuft noch nicht

Gruß
brombeerwilli

[brombeerwilli]

Moin,
hab mal ganz kurz softdevice(xv) zum laufen bekommen:

System6: bromberwilli, M2N-HDMI, DVB-S, CPU BE-2350,HDMI-HDMI [email protected]  performance-governor

softdevice-XV mit lavac Nachbearbeitung:
CPU: 8%
Das Ruckel bei den Kamera-Schwenks über eine Lanschaftsaufnahme ist weg!!! (Das war das was mich am meisten genervt hat).
Laufbänder ntv/N24: WESENTLICH besser, noch ganz leichtes ruckeln! KEINE Audio-Aussetzer!
Das Bild sieht sehr gut aus!

Gruß
brombeerwilli

[Wicky]

Hallo brombeerwilli,

vielen Dank für die Tests, ich denke die helfen weiter:

Zusammenfassend lässt sich wohl sagen:

1. XVMC vermindert das Ruckeln (führt beim M2N allerdings gelegentlich zu Audio-Aussetzern)
2. Ruckeln verschwindet vollständig mit softdevice !!!! (Damit wäre meine Vermutung bestätigt)

@bromerwilli
Ich vermute, dass du das Skript easyvdr-config-softdevice zur Konfiguration verwendet hast. Aber du musstes vermutlich noch etwas mehr für die Konfiguration unternehmen.

Kannst du bitte möglichst genau beschreiben, was du zusätzlich gemacht hast?
Bei mir läuft nämlich softdevice noch nicht !!
Nachtrag: Habs im Howto Thread gefunden. export DISPLAY:=0.0 muss noch gesetzt werden.

Gruß
Wicky

[sparkie]

hier ein paar Anmerkungen: ich betreibe einen PUNDIT P1-AH2 (ist vergleichbar mit M2NPV-VM) mit einem selbstgebauten VGA->RGB Adapterkabel an einem Roehren-TV (RGB-SCART). Siehe auch http://www.vdr-portal.de/board/thread.ph...post685989

Mit dem lokalen Frontend 'sxfe' (vdr-Thread) habe ich perfekte Wiedergabe von Laufschriften. Wenn ich stattdessen auf derselben Maschine das sxfe remote Frontend starte (separater Prozess), ruckeln Laufschriften. Version: xineliboutput-1.0.0rc2cvs vom 7.2.2008. Falls von Interesse kann ich mal Timingmessungen im Xserver machen.

Das gleiche gilt uebrigens auch fuer einen PUNDIT ID-3. Und da ist eine ATI Grafik (IGP 9100) verbaut.

Es ist also ein wesentlicher Unterschied das lokale oder remote Frontend sxfe zu nutzen.

[brombeerwilli]

Moin,
hier nochmal ein kleiner Zwischenstand von meinen Einstellungen:
System: bromberwilli, M2N-HDMI, DVB-S, CPU BE-2350,HDMI-HDMI [email protected]  performance-governor
-in den Plugineinstellungen hab ich unter xineliboutput|Lokale Anzeige|Dekoder|Puffergröße auf "mittel" gestellt. Daraufhin hab ich keine Audio-Aussetzer mehr. Ist das Zufall? Kann das jemand bestätigen?
Das bisher beste "Anti-Ruckel-Ergebnis" habe ich mit Deinterlacing: "TvTime" und der Methode: "Greedy 2frame.." erzielt. CPU-Auslastung aber so ~ 50%
n24-Laufband: scharfe Schrift, ganz leichtes Ruckeln
ntv-Laufband: scharfe Schrift, eher periodisches Zucken
ARD-Laufband(Wahlen gestern) sehr gute Schriftschärfe, kein Ruckeln!

Gruß
brombeerwilli

[Wicky]

Hallo brombeerwilli,

-in den Plugineinstellungen hab ich unter xineliboutput|Lokale Anzeige|Dekoder|Puffergröße auf "mittel" gestellt. Daraufhin hab ich keine Audio-Aussetzer mehr. Ist das Zufall? Kann das jemand bestätigen?

Das kann ich so bestätigen. Ist die Puffergröße auf klein, so erhalte ich ebenfalls Probleme bzgl. Ton und Bild. Zwischen Puffergröße "mittel" und "groß" kann ich allerdings keine Unterschiede feststellen. "mittel" ist allerdings auch schon der default Wert...

Das bisher beste "Anti-Ruckel-Ergebnis" habe ich mit Deinterlacing: "TvTime" und der Methode: "Greedy 2frame.." erzielt. CPU-Auslastung aber so ~ 50%

Hmmm, ~50% CPU Auslastung ist eine ganze Menge, wenn man bedenkt, dass deine CPU doch schon recht "kräftig" ist. Das gefällt mir nicht. Aber imerhin verschwindet so das Ruckeln.
Momentan schmeckt mir softdevice aber besser. Noch besser fände ich es, wenn wir die xineliboutput Probleme unabhängig vom Deinterlacer vollständig lösen könnten.
Ich werde gleich einmal dem Tipp von sparkie nachgehen, auch wenn ich meine dies schoneinmal erfolglos getestet zu haben.

Bis denne,
Wicky

[brombeerwilli]

"mittel" ist allerdings auch schon der default Wert...

Moin Wicky

war er bei mir nicht! Bei mir war "klein" defaultmäßig drin!

Gruß
brombeerwilli

[maxx]

@sparkie

Es ist also ein wesentlicher Unterschied das lokale oder remote Frontend sxfe zu nutzen.

bei der automatischen Installation die die meisten hier nutzen wird das lokale Frontend sxfe installiert.
Und erstmal Karma++ für Deinen tollen patch
Habe aber auch schon lange nicht mehr probiert ob der noch erforderlich ist, weißt Du da näheres?

war er bei mir nicht! Bei mir war "klein" defaultmäßig drin!

kann ich bestätigen!
Mit "mittel" ist das dann schon viel besser, das sollte dann wohl Standard werden wenn keine Probleme damit hat...

Gruß
maxx

[sparkie]

@maxx:

Und erstmal Karma++ für Deinen tollen patch

oh - danke welchen Patch genau meinst du ?

@brombeerwilli:
du schreibst 'ntv-Laufband: scharfe Schrift, eher periodisches Zucken':
das hatte ich auch einmal, Schuld war offenbar der DVB Treiber? Teste vielleicht mal das Programm
gleichzeitig aufzuzeichnen. Bei mir war es damals so, dass nur das Live-Programm
Unregelmaessigkeiten hatte. Wenn ich dasselbe Programm anschliessend als AUfzeichnung angeschaut habe,
war es stoerungsfrei. Vielleicht testweise auch mal die DVB Treiber blacklisten.

@all:
wenn ich fuer 'xineliboutput.Decoder.PesBuffers' einen Wert < 500 einsetze, dann habe ich insbesondere bei Radiosendern Aussetzer.
Bei Werten >= 500 habe ich vielleicht  noch ca. 1 Ton-Aussetzer pro 1/2Stunde SPielfilm,  wenn ich eine Aufzeichung schaue. Das merke ich
uebrigens nur dann, wenn es sich um Dolby Digital handelt, da dann die Verstaerker-Decoder LED kurz flackert.

Bezueglich Auslastung:
ich setze bei mir:

Code:

xineliboutput.Video.DeinterlaceOptions = method=Greedy2Frame,cheap_mode=0,pulldown=none,framerate_mode=full,judder_correction=0,use_progressive_frame_flag=1,chroma_filter=0,enabled=1

Hier kommt es beim Deinterlacing natuerlich darauf an, ob im Stream das Progressive-Flag gesetzt ist oder nicht.
Bei Kinofilmen ist es typischerweise gesetzt => das Deinterlacing kostet dann keine merkliche CPU-Power mehr.
ALs positiven Nebeneffekt werden dann die Halbbilder ohne Artefakte wieder zusammengesetzt.
Den Unterschied merkt man sofort, wenn man testweise bei einem Kinofilm use_progressive_frame_flag=0 setzt.

[maxx]

oh - danke welchen Patch genau meinst du ?

den autocrop_stabilize.patch meinte ich.
Das Gezappel hatte mich vorher schon ganz nervös gemacht.

maxx

[sparkie]

den autocrop_stabilize.patch meinte ich.

ah - das freut mich, dass es doch jemand brauchen konnte. Hat damals gar kein Reaktion gegeben.
Naja, ich habe den Patch auch gut versteckt

Der Patch ist mit der oben angegebenen xineliboutput Version immer noch noetig.
Vermutlich gibt es bei Petri das Problem nicht, sonst haette er es sicher schon laengst selbst gefixt.

OT:
Seit Anfang Januar hat Petri eine Direkttasten-Korrekturmoeglichkeit in xineliboutput fuer Audio/Video Asynchronitaet eingebaut.
Man muss also nicht mehr ueber's Menue gehen.
Leider floatet bei mir der Wert zwischen 0 und -300ms  bei Dolby Digital. Auf einem anderen VDR, der
nur Stereo wiedergibt, funktioniert es ohne Probleme. Ich habe keine Ahnung, was da die Ursache ist,
oder ob das Problem sonst noch wer hat.

[brombeerwilli]

@brombeerwilli:
Vielleicht testweise auch mal die DVB Treiber blacklisten.

Moin sparkie
Das würd ich gern mal probieren, wenn ich nur wüßte, was Du meinst.
Das mit dem Aufnehemen teste ich.
Theoretisch kann ich doch auch testweise meine Nexus2.2 gegen die Skystar2.6d tauschen, oder verträgt sich xineliboutput nicht mit ner FF-Karte?

Gruß
brombeerwilli

[sparkie]

Hi brombeerwilli,

[quote author=sparkie link=topic=4045.msg29367#msg29367 date=1203973948]
@brombeerwilli:
Vielleicht testweise auch mal die DVB Treiber blacklisten.

Das würd ich gern mal probieren, wenn ich nur wüßte, was Du meinst.[/quote]
ok, muss ja nicht gleich sein. Ich weiss im Moment auch nicht, wie das auf deinem System
am schnellsten geht. Es soll nur dazu dienen, dass die DVB Treiber testweise nicht geladen werden.
Da ich vermute, dass die DVB Treiber Ursache fuer das Ruckeln sind.

Theoretisch kann ich doch auch testweise meine Nexus2.2 gegen die Skystar2.6d tauschen, oder verträgt sich xineliboutput nicht mit ner FF-Karte?

das ist kein Problem, wenn xineliboutput  so konfiguriert ist, dass es 'primary device' ist. Plugin ist also mit '-p' zu starten.

Ich glaube aber nicht, dass der Kartentausch viel bringt. Wenn du aber bereit bist, deinen VDR zu zerpfluecken,
dann kannst du mal alle SAT Karten ausbauen und nach Backup die 'channels.conf' leer machen, damit der VDR trotzdem startet.

Auf diese Weise kannst du testen, wie das Abspielen laeuft, ohne dass  DVB Treiber dazwischenfunken.

-sparkie

[Wicky]

Hallo brombeerwilli,

[quote author=sparkie link=topic=4045.msg29367#msg29367 date=1203973948]
@brombeerwilli:
Vielleicht testweise auch mal die DVB Treiber blacklisten.

Das würd ich gern mal probieren, wenn ich nur wüßte, was Du meinst.[/quote]
Sämtliche DVB-Treiber sollten bei easyvdr geblacklistet sein. D.h. es werden nur die Module geladen, die in der /etc/vdr/driverconfig angegeben sind.

Wenn du hier ein wenig experimentieren möchtest, so kannst du folgendermaßen vorgehen:
1. Mit "hwinfo -dvb" die notwendigen Module bestimmen (dürfte b2c2-flexcop-pci sein)
2. In der driverconfig sämtliche Module mit einem "#" auskommentieren, die nicht benötigt werden.
3. Mit lsmod vergleichen, ob die Maßnahme erfolgreich war.

Theoretisch kann ich doch auch testweise meine Nexus2.2 gegen die Skystar2.6d tauschen, oder verträgt sich xineliboutput nicht mit ner FF-Karte?

xineliboutput arbeitet problemlos auch mit einer FF-Karte.

Gruß
Wicky

[sparkie]

Hallo Leute,

ich habe noch mal intensiver experimentiert. Es scheint tatsaechlich Probleme mit der Anzeige vom Live-Programm zu geben. Das ist mir nur deswegen nicht aufgefallen, da ich praktisch nur Aufzeichnungen sehe.

Ich habe mir einen Debug-VDR aufgesetzt. Dieser verliert ca. mit jeder Minute genau ein Halbbild, weil die Grafikkarte nicht exakt auf 50Hz arbeitet. Wenn ich Deinterlace faellt dieser Halbbildverlust jedoch nicht auf. Es ruckelt also (sichtbar) gar nichts.

Damit ich jeden Halbbildverlust sofort mitbekomme, habe ich deswegen jegliches Deinterlacing abgeschaltet. Man kann jetzt sehr schoen sehen, wie die Fields abwechselnd korrekt/geswapped ausgegeben werden.

Wenn ich jetzt auf ein Live-Programm z.B. N24 tune sehe ich, dass viel haeufiger, als im  erwarteten 60 Sekunden Abstand, Halbbilder gedroppt werden. Wenn ich hingegen die Aufzeichnung desselben Programmes schaue, habe ich wieder genau nur die 60Sekunden Drops. Selbst im Timeshift funktioniert es korrekt!

Fazit:
Es gibt offenbar ein Problem mit dem Livemodus zwischen VDR-Core<->xineliboutput, das bei Wiedergabe von Aufzeichnungen nicht exisiert. Ich muss bei Gelegenheit mal nachschauen, was da aus Sicht von xineliboutput der Unterschied ist.

-sparkie

[maxx]

Hallo,

Was mir noch aufgefallen ist und eventuell auch in die Thematik paßt:
Aktiviere ich Live Buffer (egal ob über Festplatte oder RAM), habe ich sehr viele Probleme beim Kanalumschalten, er bleibt regelmäßig hängen mit "No Signal"
Deaktiviere ich das habe ich sofort keine Probleme mehr.

edit: paßte hier nicht rein, weil das gleiche Problem auch unter softdevice...

Gruß
maxx

[sparkie]

es gibt neue Erkenntnisse speziell zu N24:

diese Schlaumeier setzen das progressive_frame_flag obwohl mindestens die Laufschrift mitnichten progressiv gesendet wird.
D.h. wenn jemand in seiner setup.conf use_progressive_frame_flag==1 konfiguriert hat, ruckelt es zwanglaeufig (b.z.w. es werden
die Fields immer wieder mal vertauscht)

Danke an Reinhard fuer diesen Hinweis, ueber den ich gerade gestolpert bin:
http://vdr-portal.de/board/thread.php?po...post665891

ich habe es selbst nachgeprueft. Wenn ich use_progressive_frame_flag==0 setze, funktioniert N24. Wegen denen werde ich
das aber sicherlich nicht dauerhaft auf 0 gesetzt  lassen

[Wicky]

Hallo sparkie,

diese Schlaumeier setzen das progressive_frame_flag obwohl mindestens die Laufschrift mitnichten progressiv gesendet wird. D.h. wenn jemand in seiner setup.conf use_progressive_frame_flag==1 konfiguriert hat, ruckelt es zwanglaeufig (b.z.w. es werden
die Fields immer wieder mal vertauscht)

Wenn ich das ganze richtig verstehe, kann dieser Flag jedoch nur dann zum ruckeln führen, wenn das verwendete Display nicht interlaced arbeitet.

D.h. wer einen normalen Röhren TV verwendet, der interlaced arbeitet, kann von diesem N24 Bug nicht betroffen werden.

Sehe ich dies korrekt?

Und noch eine Frage:
Lautet die Syntax des setup.conf Parameters wirklich "use_progressive_frame_flag==1" ?
-> Damit wäre es doch kein xineliboutput Parameter !!
Lautet die Syntax eventuell:

Code:

xineliboutput.use_progressive_frame_flag=1

Danke an Reinhard fuer diesen Hinweis, ueber den ich gerade gestolpert bin:
http://vdr-portal.de/board/thread.php?po...post665891

Wegen denen werde ich das aber sicherlich nicht dauerhaft auf 0 gesetzt  lassen

Welche Auswirkungen hätte es, wenn du es tätest?

Gruß
Wicky

P.S. Vielen Dank für die vielen Aufkärungen von dir... ich denke wir müssten sonst deutlich mehr forschen. Das kostet aber viel Zeit.

[sparkie]

Hallo Wicky,

D.h. wer einen normalen Röhren TV verwendet, der interlaced arbeitet, kann von diesem N24 Bug nicht betroffen werden.

richtig. Zumindest darf kein Zwischenschritt non-interlaced sein. Ich betreibe ein interlaced Roehren-TV an einer
VGA Karte und muss deswegen (noch) in einem Zwischenschritt deinterlacen. Das zaehlt quasi auch als Display, das
nicht interlaced arbeitet, da die Fields nicht 1:1 'durchgeroutet' werden.

Wenn ich das ganze richtig verstehe, kann dieser Flag jedoch nur dann zum ruckeln führen, wenn das verwendete Display nicht interlaced arbeitet.

die Frage ist, wie genau die Frames ihren Weg auf das Display (TV?) finden.

Wie betreibst du mit xineliboutput ein Display, das interlaced arbeitet?

-> Damit wäre es doch kein xineliboutput Parameter !!

in meiner setup.conf ist per OSD-Eingabe folgendes konfiguriert, also ein '=' weniger

Code:

xineliboutput.Video.DeinterlaceOptions = method=Greedy2Frame,cheap_mode=0,pulldown=none,framerate_mode=full,judder_correction=0,use_progressive_frame_flag=1,chroma_filter=0,enabled=1

Welche Auswirkungen hätte es, wenn du es tätest?

es wird dann moeglicherweise per Software deinterlaced, obwohl die Fields nur 'billig' wieder zusammengesetzt werden koennten:
- dadurch kommen unnoetig alle Fehler ins Spiel, die man von Software-Deinterlacern kennt.
- es kostet unnoetig CPU-Power

- sparkie

[Wicky]

Hallo sparkie,

Wie betreibst du mit xineliboutput ein Display, das interlaced arbeitet?

Ich verwende den TV-out meines M2NPV-VM. Dieser gibt ausschließlich interlaced aus. Die Deinterlacing Fähigkeiten von xineliboutput habe ich deaktiviert. Bei dieser Konfiguration sollte in meinen Augen keiner der Schritte deinterlaced ablaufen. Wenn dennoch einer der Schritte deinterlaced abläuft, so wäre das Verhalten auch bei interlaced Ausgabe erklärbar.

in meiner setup.conf ist per OSD-Eingabe folgendes konfiguriert, also ein '=' weniger

Code:

xineliboutput.Video.DeinterlaceOptions = method=Greedy2Frame,cheap_mode=0,pulldown=none,framerate_mode=full,judder_correction=0,use_progressive_frame_flag=1,chroma_filter=0,enabled=1

AhA, use_progressive_fame ist eine Option des Deinterlacers von xineliboutput... jetzt verstehe ich die Syntax.

Welche Auswirkungen hätte es, wenn du es tätest?

es wird dann moeglicherweise per Software deinterlaced, obwohl die Fields nur 'billig' wieder zusammengesetzt werden koennten:
- dadurch kommen unnoetig alle Fehler ins Spiel, die man von Software-Deinterlacern kennt.
- es kostet unnoetig CPU-Power

...ich befürchte, dass ich mich mit dem Thema Deinterlacing und der Umsetzung in xine/xineliboutput/tvtime noch tiefer auseinandersetzen muss.

Gruß
Wicky

[avrfan]

Hallo Ruckelforscher,

nach vielen Testläufen mit softdevice, xineliboutput und der Ruckelproblematik, habe ich für mich eine brauchbare Lösung gefunden.
Ich betreibe mein Display jetzt mit 1920x1080_25Hz(p) und xineliboutput (xv) über HDMI. Bei 50Hz habe ich mit softdevice wie auch mit xineliboutput immer irgendwann mit dem Ruckeln zu kämpfen (man wartet ja schon darauf). Seitdem ich auf die 25Hz gewechselt bin, ist das Ruckeln für mich gelöst. Als Deinterleacer setze ich Bob ein. Mit tvtime sind die Laufbänder leicht problematisch. Das größte Hindernis für tvtime sind aber Aufzeichnungen (Kinofilme), welche vermutlich ein falsch gesetztes progressive Flag haben (wie kann ich das testen?). Diese laufen ohne Deinterleacer völlig OK, mit tvtime sind "Makroruckler" vorhanden.

Die Systemauslastung von meinem System liegt bei 37% mit der sysinfo Anzeige. Da Doppelkernprozessor also die eigendliche Systemauslastung bei 19% mit top (die Bestimmung der Systemauslastung sollte für diesen Thread genauer definiert sein).

Gruß
avrfan

[brombeerwilli]

Moin avrfan,
Das wäre der absolute Kracher, wenn ich mit der Umstellung auf 25Hz endlich das Ruckeln weg kriegen würde. Ich hab irgendwie das Gefühl, daß wir mit der Auflösung 1920x1080 am meisten darunter leiden. Hab beim Durchfliegen der nvidia-setting gar kein Punkt für die Frequenzumstellung gesehen! Du hast es doch über die nvidia-settings gemacht?
Mist, daß ich das erst nach Feierabend probieren kann! 

Gruß
brombeerwilli

[avrfan]

Hallo brombeerwilli,

ich habs in die xorg.conf reingesetzt. Mit nvidia-settings funktioniert es auch und steht dort bei mir auch zur Auswahl. Vermutlich ist es aber eine Frage des angeschlossenen Displays, welche Modis von diesem unterstützt werden. Meine derzeitige xorg.conf ist im Anhang (durch das viele Probieren sicher noch nicht optimal).

Gruß
avrfan

[brombeerwilli]

Hallo brombeerwilli,

ich habs in die xorg.conf reingesetzt. Mit nvidia-settings funktioniert es auch und steht dort bei mir auch zur Auswahl. Vermutlich ist es aber eine Frage des angeschlossenen Displays, welche Modis von diesem unterstützt werden. Meine derzeitige xorg.conf ist im Anhang (durch das viele Probieren sicher noch nicht optimal).

Gruß
avrfan

moin avrfan,
25Hz kann mein Sharp leider nicht über HDMI 
aber folgendes hab ich im vdr-wiki (http://www.vdr-wiki.de/wiki/index.php/VDR_mit_DVI/VGA) gefunden:

Wichtig für ruckelfreies Deinterlacing ist zusätzlich noch die Option

Section "Device"
[...]
    Option "UseEvents" "True"
[...]
EndSection

Hab ich jetzt mal in meine xorg.conf eingetragen, bisher hab ich das Gefühl, das Ruckeln ist besser, aber das muß ich mal länger testen!

Gruß,
brombeerwilli