[patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

So Männer,

Halbzeit, sieht gut aus.

Mit 60 Hz, keine Ruckler, keine Framedrops, nach dem umschalten via Xrandr im laufenden Betrieb auf 60 Hz (siehe Log).

Die Framedrops die man sieht sind vom vdpau-recreate.

Grundlage mit xine-vdpau-r285+xine-lib-patch+df-v11

Und Jetzt?, wer hat eine Erklärung für das Phänomen?

Gruß
Wolfgang

Hi Wolfgang,

Zitat

Originally posted by wbreu
Und Jetzt?, wer hat eine Erklärung für das Phänomen?

Erklaerung habe ich direkt auch keine.

ABer ich vermute immer noch ein Problem im USEEVENTS Umfeld. Kannst du vielleicht mal die
XVideoTextureSyncToVBlank und auf Null setzen und sehen ob die
Drops dann auch bei 50Hz abnehmen/weg sind?

- sparkie

Zitat

Original von sparkie
Hi Wolfgang,

Erklaerung habe ich direkt auch keine.

ABer ich vermute immer noch ein Problem im USEEVENTS Umfeld. Kannst du vielleicht mal die
XVideoTextureSyncToVBlank und XVideoSyncToDisplay auf Null setzen und sehen ob die
Drops dann auch bei 50Hz abnehmen/weg sind?

- sparkie

Alles anzeigen

Hi sparkie,

na klar kann ich das, die zweite Halbzeit beginnt gerade damit....

Logs gibts dann beizeiten.

Gruß
Wolfgang

Hi Wolfgang,

hast du in xine-lib XLOCKDISPLAY definiert? Ist ja wieder der Default.

Bei mir gibt es mit xine-ui schon mit SD Programmen periodische Framedrops, falls das Define drin ist (komischerweise nicht mit vdr-sxfe). Ohne Define läuft es wunderbar. Allerdings habe ich als Kabeluser zur Zeit nur die ARD und ZDF HD Trailer zum Testen.

Grüße,
Matthias

Zitat

Original von Rincewind99
Hi Wolfgang,

hast du in xine-lib XLOCKDISPLAY definiert? Ist ja wieder der Default.

Bei mir gibt es mit xine-ui schon mit SD Programmen periodische Framedrops, falls das Define drin ist (komischerweise nicht mit vdr-sxfe). Ohne Define läuft es wunderbar. Allerdings habe ich als Kabeluser zur Zeit nur die ARD und ZDF HD Trailer zum Testen.

Grüße,
Matthias

Alles anzeigen

Hi,

jepp ist definiert, sonst geht gar nix...

Gruß
Wolfgang

Zitat

Original von sparkie
Hi Wolfgang,

Erklaerung habe ich direkt auch keine.

ABer ich vermute immer noch ein Problem im USEEVENTS Umfeld. Kannst du vielleicht mal die
XVideoTextureSyncToVBlank und auf Null setzen und sehen ob die
Drops dann auch bei 50Hz abnehmen/weg sind?

- sparkie

Alles anzeigen

Hi,

nach 25 Minuten kann man sagen, keine Bessserung mit den beiden Nullen.

die settings-rc ist im Anhang dabei.

Gruß
Wolfgang

Zitat

Original von wbreu
jepp ist definiert, sonst geht gar nix...

Hast du die Chance, deine libxcb zu aktualisieren?

Ich kenne mich mit Debian nicht so aus, aber ich glaube bei Lenny ist noch die buggy libxcb 1.1 aktuell. Alles ab 1.1.93 ist wohl bugfrei und du bräuchtest die Synchronisierung nicht mehr.

Grüße,
Matthias

Naja,

mediavdr1:~# apt-get -s install libxcb1
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libxcb1-dev
The following packages will be upgraded:
  libxcb1 libxcb1-dev
2 upgraded, 0 newly installed, 0 to remove and 110 not upgraded.
Inst libxcb1-dev [1.1-1.1] (1.1-1.2 Debian:5.0.3/stable) []
Inst libxcb1 [1.1-1.1] (1.1-1.2 Debian:5.0.3/stable)
Conf libxcb1 (1.1-1.2 Debian:5.0.3/stable)
Conf libxcb1-dev (1.1-1.2 Debian:5.0.3/stable)

Im Angebot wäre die 1.1 soweit ich das sehe.

Ein upgrade auf einen neueren X-Server würde da schon helfen, aber ob's was bringt?

Gruß
Wolfgang

Die xine-lib Entwickler waren seinerzeit der Meinung, das Locking könnte zu Framedrops führen:

http://www.nvnews.net/vbulletin/showpost.php?p=1896995&postcount=1

Mit meinem entwas schwachbrüstigen Client kann ich das wie gesagt ja auch beobachten. Ich denke, es ist einen Versuch wert.

Grüße,
Matthias

Zitat

Original von Rincewind99
Die xine-lib Entwickler waren seinerzeit der Meinung, das Locking könnte zu Framedrops führen:

http://www.nvnews.net/vbulletin/showpost.php?p=1896995&postcount=1

Mit meinem entwas schwachbrüstigen Client kann ich das wie gesagt ja auch beobachten. Ich denke, es ist einen Versuch wert.

Grüße,
Matthias

Alles anzeigen

Hi,

wenn ich mir das changelog von debian zur libxcb ansehe, finde ich da nix, was mich weiterbringt.

Erst in sqeeze ist ein Verweis auf die 1.1.93er-Version, das würde ein distupgrade bedeuten, ich weiß nicht, das ist immer sehr gefährlich.

Mal eine Sicherund machen.

Hast du nähere Info's welcher Bug da genau gemeint ist?

Hier ne schöne Übersicht der verfügbaren Versionen der libxcb1 mit Änderungsbeschreibung, wenn man im entsprechenden Bereich auf die libxcb1 klickt.

http://packages.debian.org/search?suite=default&section=all&arch=any&searchon=sourcenames&keywords=libxcb

Gruß
Wolfgang

Im oben schon erwähnten Thread

http://www.nvnews.net/vbulletin/showthread.php?t=125885

werden auch Bugreports referenziert. Reinhard Nissl hat auch in dem Thread geschrieben. Vielleicht kann er ja noch was dazu sagen.

Der vorletzte Post sagt aber klar:

Zitat

I can confirm that the guarding is not needed with libxcb-1.1.93+ libx11-1.1.99.
So this really looks like an xcb bug.

Grüße,
Matthias

Hallo,

ich hatte schon im Juni wegen des LOCKDISPLAY ein paar Pakete auf meinem lenny upgegraded.
siehe integration von vdpau in vdr

seitdem sind installiert:

ii libxcb1 1.3-2 X C Binding
ii libxcb1-dev 1.3-2 X C Binding, development files

ii libx11-6 2:1.2.1-1 X11 client-side library
ii libx11-data 2:1.2.1-1 X11 client-side library
ii libx11-dev 2:1.2.1-1 X11 client-side library (development headers)

läuft seither sehr gut auch ohne LOCKDISPLAY.

Gruß, tomas

Hi,
wo grad das Thema kommt:
Könnte man nicht echt zumindest schaltbar einbauen, dass die völlig unterforderte CPU, die bei den meisten VDPAU-Usern n Dual-Core von AMD/Intel ist und damit viel Power über hat, dafür einspannen teilweise? Um framedrops zu eliminieren? ok bei Atom und den PCI-Varianten wirds wohl nicht viel bringen)...

Gibts eigentlich schon ne xine-lib mit FFMpeg-MT? Damit schafft n Mittelklasse AMD x2 1080p in Software...

mfG,
Stefan

Zitat

Originally posted by durchflieger
Deine Feststellung hier ist sehr interresant!

weitere interessante Infos zum Thema "VDPAU-Frametiming" habe ich noch hier gefunden:
http://www.nvnews.net/vbulleti…php?p=2094226#post2094226

Zitat

Tatsächlich ist es zur Zeit ja so, das bei vdpau die Framedrops doch sehr gut wahrnehmbar sind. Das liegt meines erachtens auch an der derzeitigen Implementierung in der xine-lib. Wenn es zu einem frame drop log-Eintrag kommt dann verwirft die xine-lib ein ganzes frame.

wobei ich oben eigentlich nicht die Framedrops gemeint habe, die in den Logs sichtbar werden. Da ist klar, dass die (zumindest mit der derzeitigen Implementierung) zu sichtbaren Stoerungen fuehren. Ich meinte die Asynchronitaet zwischen der Anlieferung der Frames durch die xine-lib an den Xserver und dessen voellig freilaufendes Videotiming. Es erfolgt zwar im Xserver ein Sync2Vblank durch Warten oder Doublebuffering (ich weiss gar nicht was mit VDPAU zum Einsatz kommt) um Tearing zu vermeiden.
Aber es ist noch lange nicht sichergestellt, dass wirklich jedes 50p Frame ueberhaupt auf den Schirm kommt. Oder dass nicht evtl. Frames fuer die Dauer eines Halbbildes zulange auf dem Schirm verweilen. Dieses Problem hatten wir ja seinerzeit durch unsere FRC Patches geloest.

Die Ungenauigkeit, die hierbei auftritt, betrifft aber nur immer maximal 1 Halbbild und diese ist wohl praktisch kaum wahrnehmbar. Das wollte ich oben eigentlich ausdruecken.

Umso besser wenn man wie in deinen folgenden Ausfuehrungen beschrieben sogar xine-lib Framedrops auf blosse Halbbildverluste reduzieren koennte!

Zitat

Bei interlaced video heisst das, es werden gleich zwei Halbbilder verworfen was bei der derzeitigen Implementierung dazu führt, das gleich zwei ganze Vollbilder verworfen werden.
Erschwerend kommt noch hinzu, dass die beiden Halbbilder auch nicht den deinterlacer passieren und damit beim Einsatz von temporalen deinterlacing die Kette der Halbbilder unterbrochen wird. (Beim temporalen deinterlacing wertet der Algorithmus der deinterlacer ja auch zukünftige und vergangene Halbbilder aus).

das klingt sehr plausibel und laesst noch viel Spielraum fuer weitere Optimierungen. Gut zu wisssen, obwohl VDPAU ja bereits jetzt sehr ordentlich funktioniert.

Zitat

Meine Idee ist jetzt, die Ausgabe in der xine-lib so umzukrempeln, das bei einem notwendigen frame drop bei interlaced video trotzdem beide Halbbilder zum frame deinterlaced werden, aber nur ein Halbbild angezeigt wird.

das waere natuerlich super wenn das ginge. Mich wundert nur immer wieder, dass gerade solche zentralen Themen nicht schon laengst angegangen wurden. Weil diese Problematik gibts doch eigentlich solange wie die xine-lib selbst.

Zitat

Bezüglich der video output loop gibt es noch weiteres Verbesserungspotential. Zur Zeit passiert das deinterlacing, osd blending, scaling und Anwendung der video filter (sharpness etc.) ja hier. Und das alles muss "just in time" passieren da es nur minimale Pufferung von einem frame gibt. Da ist dann nicht viel Toleranz zumal der video output thread auch noch maßgebliche Zeit in den sleeps verbrät um die Zeit bis zur nächsten frame Ausgabe zu überbrücken.

ich muss mir das am Wochenende auch mal genauer anschauen. Das sind alles sehr gute Ansatzpunkte.

- sparkie

Hi zusammen,

durchflieger, sparkie,

danke für euere Mühe, und die ausführlichen Erläuterungen!

tomas

Auch dir Danke für den Tip mit der libxcb, ich habe jetzt mal ein upgrade der Pakete gemacht. Mal sehen wie es geht.., Kompiliert hat es schon mal mit dem geänderten Parameter in der xine-vdpau-Source, laufen tut's auch.

Gruß
Wolfgang

Zitat

Original von durchflieger
Als weiterer Aspekt wäre noch zu nennen, dass auch in der xine-lib die vdpau presentation queue mit der frame rate befüllt wird, die im video stream festgelegt ist (wobei die konkrete Taktung durch die xine-lib Uhr bestimmt wird). Das vdpau entnimmt aber frames mit der Taktung des vsync der wiederum vom eingestellten video mode abhängig ist und der Genauigkeit der Uhr auf der Graka.

Wenn ich das richtig verstehe, ist xine ja prinzipiell in der Lage, auch mit externer Taktung umzugehen (SCR Plugin). Es gibt eine Implementierung für dxr3. Die Frage ist aber wieder, wie man an den Grafikkartentakt kommt. Ich glaube die XBMC Entwickler lösen das mittels OpenGL.

Wenn ich ein bisschen besser C könnte, würde ich da gerne mithelfen. Bin aber leider nur in der Java Welt fit.

Viele Grüße,
Matthias

Zitat

Original von Rincewind99

Wenn ich das richtig verstehe, ist xine ja prinzipiell in der Lage, auch mit externer Taktung umzugehen (SCR Plugin). Es gibt eine Implementierung für dxr3. Die Frage ist aber wieder, wie man an den Grafikkartentakt kommt. Ich glaube die XBMC Entwickler lösen das mittels OpenGL.

Wenn ich ein bisschen besser C könnte, würde ich da gerne mithelfen. Bin aber leider nur in der Java Welt fit.

Viele Grüße,
Matthias

Alles anzeigen

Hallo Matthias,

auch dir Danke für den Tip mit der libxcb, irgendwie wäre ich da nie drauf gekommen, dass das wirklich so einen Einfluß hat/haben könnte.

Gruß
Wolfgang

Zitat

Original von wbreu
auch dir Danke für den Tip mit der libxcb, irgendwie wäre ich da nie drauf gekommen, dass das wirklich so einen Einfluß hat/haben könnte.

Hi Wolfgang,

gern geschehen. Wie siehts denn aus. Hat es geholfen?

Grüße,
Matthias