Vdpau Grundlagen
(→Zulus VDR-Extension-Patch-Version 72) |
(→Mein Favorit (Stand 24.08.2009)) |
||
| Zeile 149: | Zeile 149: | ||
Positiv: | Positiv: | ||
| − | * sehr stabil ab r273 von xine-vdpau aus | + | * sehr stabil ab r273 von xine-vdpau aus {{wikipedia|svn}}-Projektarchiv |
* Autocropping = automatisches Aufziehen des Bildes (Letterbox-Automatik) | * Autocropping = automatisches Aufziehen des Bildes (Letterbox-Automatik) | ||
* schnelles Umschaltverhalten (bei PES-Buffers = 900) und sehr gute Tonerkennung auch bei PassThrough bei HD-Sendern | * schnelles Umschaltverhalten (bei PES-Buffers = 900) und sehr gute Tonerkennung auch bei PassThrough bei HD-Sendern | ||
Version vom 4. Oktober 2009, 11:41 Uhr
Wbreu hat im August 2009 im VDR-Portal [1] eine hervorragende Zusammenfassung geschrieben, die sehr viele Fragen zum Thema VDPAU und Xine* in Verbindung mit VDR erklären.
Diese Zusammenfassung befindet sich noch im Aufbau.
Los geht’s in der Regel mit der Auswahl der passenden Hardware
Mainboard mit Onboard-Grafikkarte
Mainboardauswahl
Bei der Auswahl des Mainboards trifft man schon eine wichtige Entscheidung => Intel oder AMD. Auf ION-Systeme gehe ich hier nicht ein, da diese System in meinen Augen noch zu viele Einschränkungen für einen vollwertigen VDR mitbringen bzw. eben zu wenige PCI/PCI-Express-Steckplätze mitbringen oder auch keine LPT- oder seriellen Schnittstellen haben.
Grundsätzlich ist es im Moment so, dass Intel-Mainboards im Gegensatz zu AMD-Mainboards unproblematischer in Verbindung mit VDPAU laufen. Hintergrund ist, dass die Intel-Mainboards beim Heruntertakten nur die CPU heruntertakten und nicht den Bustakt oder/und den Speichertakt.
Die AMD-CPUs der K8-Reihe (z.B. AMD-BE-Serie, Sempron 1640, usw.) haben die Eigenschaft, beim Heruntertakten sowohl den Bustakt als auch den Speichertakt herunterzutakten. Somit gibt es jede Menge Framedrops => Bildverluste (Mikroruckler), teilweise schon bei SD-Content (= 720x576 interlaced). Bei HD]-Content ( 1920x1080 interlaced) sieht man das dann noch ausgeprägter. Umgehen kann man das in dem man den CPU-Takt auf mindestens 2000 MHz hält (Siehe AMD-Thread in den Referenzlinks).
Seit kurzem gibt es neue AMD-CPUs der K10-Reihe, die haben auch bei gesenktem CPU-Takt die oben genannten Eigenschaften nicht. Beispiel sind der AMD Sempron 140 (Boxed, OPGA, "Sargas") oder auch der AMD Athlon II X2 240 (OPGA, "Regor"). Das sind zwar beide AM3-CPUs, aber auch in vielen AM2+-Boards sind diese CPUs lauffähig. Der User gda [2] hat eine solche Sempron-140-CPU im Einsatz und auch schon positives berichtet.
Grundsätzlich haben die Onboard-Lösungen alle auch das Problem, dass der mitgelieferte Chipsatz-Kühler passiv ist. Dadurch wird der Chipsatz, in dem auch die GPU (Grafikkarte) sitzt, sehr heiß, ca. 65 bis 75 Grad. Ich empfehle jedem sich gleich nach einem leisen Lüfter umzusehen, der den Kühlkörper anbläst. Ab ca. 75 Grad kann es dann zu Bildstörungen/Ruckler/Grüne Punkte kommen, da die GPU automatisch den Powerlevel (Takt der GPU) heruntersetzt.
Dual-Channel RAM
wichtig für den Speicherdurchsatz (auch der Grafikkarte) mindestens 2 Module á 1024 MB, um der Grafikkarte 512 MB zuweisen zu können (per Bioseinstellung). Speichertakt der Module sollte mindestens 800 MHz sein ( = passende Busgeschwindigkeit).
Mainboard-Chipsatzbezeichnungen
- AMD => 8200 und 8300
- Intel => 9300 und 9400
Referenzlinks zu passenden Systemen
Älteres Mainboard mit zusätzlicher PCI-Express-Grafikkarte
Beste Wahl erscheint mir hier eine Grafikkarte mit 9500erGT-Chip.
Schafft problemlos bei HD-Content erweitertes Deinterlacing mit höchstem Deinterlacer => temporal_spatial, dazu mehr bei der Software.
Die 9400erGT haben zuwenig Streamprozessoren und auch Shaderprozessoren um das erweiterte Deinterlacing von xine-vdapu bei HD-Content ( 1920x1080 interlaced) zu schaffen.
Auch hier gilt das oben erwähnte Temperaturproblem der GPU, deshalb passive Karten unbedingt von leisem Lüfter anblasen lassen.
CPU-Auswahl zum Mainboard
Intel
Jede Core2Duo-CPU oder vergleichbar. Auch Intel Celeron 440 (35 Watt).
Empfehlung ganz klar eine Dual-Core-Cpu => OSD-Aufbau schneller und auch das Konverten und Kompilieren lässt den VDR in Ruhe.
Geheimtip ist hier der 7200er, der läuft bei mir mit 0,95 Volt in dem Gigabyte E7AUM-DS2H bei vollem CPU-Takt mit 2,53 GHz. Das Board bietet die Möglichkeit die CPU via Bios zu untertakten!
AMD
Siehe Auswahl des Mainboards
Softwareauswahl und deren momentane Fallstricke
Beispielgrundkonfiguration (BS und Grundtreiber)
- Debian – Lenny von der Netinstall
- eigengebauter Kernel: 2.6.30.2 mit SMP-Unterstützung
- Nvidia-Treiber: 185.18.36
VDR-Versions-Auswahl
Im Moment ist es so, dass es da nicht so einfach ist, die für sich passende VDR-Version zu finden. Hintergrund ist die im Moment laufende Integration des neuen Aufzeichungs-Formates „ts“ in den VDR. Betroffene VDR-Versionen ab 1.7.2. Durch diese gravierende Änderung laufen eben viele Gooddies mit dem VDR nicht mehr. Beispiele:
- Livebuffer-patch => wurde via Patch (Zulus Extension-Patch) dem VDR einverleibt, geht seit VDR 1.7.7 nicht mehr
- noad-Skripte => Schneiden und Schnittmarken, Springen in Aufnahmen usw.
- Plugins: Auch hier ist es so, dass etliche wichtige Plugins erst nach und nach an das neue Aufzeichnungsverfahren angepasst werden müssen.
Beispiel => xineliboutput mit diversen Problemen, z.B Ton auf HD-Sendern, richtige Puffergröße usw.
Kurzum, in meinen Augen ist nach wie vor die beste Wahl für einen HD-VDR mit xineliboutput und vdpau die VDR-Version 1.7.0.
Patches für den VDR-1.7.0 um eine gute Basis zu haben
Zulus VDR-Extension-Patch-Version 72
Den VDR Extensions Patch v.72 gibt es im VDR-Portal oder hier
Dieser Patch stellt viele zusätzliche Funktionen/Addons und Notwendigkeiten zur Verfügung um auch andere Plugins und Gooddies mit dem VDR zum Laufen zu Bewegen.
Der Patch beinhaltet bereits den HD-OSD-Patch (OSD kann bis auf 1920x1080 übers Setup aufgezogen werden). Passender Thread mit Bildern.
Wichtig ist hier, dass die DVB-S/-S2-User den vdr-1.7.0-ext_h264-s2ng-speedup.diff einspielen,um die entsprechenden Anpassungen für h264 zu haben.
Wie man Patches einspielt und mit ihnen umgeht, das schenke ich mir hier und auch in den folgenden Passagen.
Grundsätzlich braucht man also:
- vdr-1.7.0_extensions.diff
- vdr-1.7.0-ext_h264-s2ng-speedup.diff
Bitte die beiliegende README unbedingt lesen => wichtige Tips zur Make.config!
DVB-C-User brauchen grundsätzlich keinen Patch, um HD mit dem VDR nutzen zu können, aber ich empfehle diesen Benutzern trotzdem gleich den extp72 einzuspielen.
xine-lib, xineliboutput-plugin oder xine-plugin, na was denn jetzt?
Grundsätzliches
Das Thema ist nicht einfach, da man viele Begrifflichkeiten und Bezeichnungen dazulernt. Zudem sind viele wichtige Parameter für die Plugins in separaten Configdateien auf dem System.
Links für Grundinformationen:
Ich persönlich nutze nur das xineliboutput-Plugin und werde nachfolgend nur auf diese Ausgabemöglichkeit ein bisschen tiefer eingehen. Mit dem xine-Plugin selbst habe ich mich noch nicht beschäftigt.
Welche xinelib-version will ich nutzen?
Die xine-lib ist die Basis für das Ausgabeplugin xineliboutput.
Dabei gibt es im Moment in Verbindung mit vdpau zwei Möglichkeiten, die den weiteren Weg ( was brauche ich dann noch?) festlegen.
xinelib-1.1.x
Erstere ist die im xine-vdpau-cvs-Zweig schon enthaltene xine-lib-1.1.16. Diese Version hat einen etwas älteren Softwarestand, aber ist für die Entwickler von xine-vdpau von jeher schon die Basis für die Entwicklung von xine-vdpau. Die xine-lib-1.1.16 ist eine stabile Version.
Das heisst, wer den xine-vdapu-cvs-Zweig benutzt, braucht sich um die xinelib-Installation nicht kümmern, da die bei der Installation von xine-vdpau miterledigt wird.
Beispielhafte Erläuterung der Installation & Konfiguration
xinelib-1.2
Zweite Möglichkeit ist die cvs-Version der xinelib, also die xinelib-1.2. Diese Version ist die Entwicklerversion der xinelib. Hierbei ändert sich fast täglich der Softwarestand, sodass es immer wieder dazu kommen kann, dass sich xinelib-1.2 auf dem eigenen System nicht kompilieren lässt. Allerdings muß man auch sagen, dass diese lib sehr viele neuere Features mitbringt, die man nicht nur wegen vdpau braucht.
xine-lib-1.2 auf hg.debian.org
und den entsprechenden xine-vdpau-Patch dazu von hier:
Ok, was soll das jetzt? Je nach dem für was man sich entscheidet, erreicht man den selben Stand mit vdpau, aber man hat einen unterschiedlichen Stand der xinelib als Basis für das Ausgabe-Plugin. Deshalb ist es wichtig, dass man sich, wenn man im VDR-Portal postet, eine vernünftige Signatur anlegt, die den jeweiligen Zweig beschreibt. Denn wie man sieht, ist vdpau dann eben nicht vdpau wegen der unterschiedlichen Basis der xinelib-1.2 oder eben der xinelib-1.1.
Welche xineliboutput-Versionen gibt es, welche ist zu empfehlen?
Auch hier ist es so, dass man zwischen zwei Wegen wählen kann => eine stabile Version des Ausgabeplugins = xineliboutput-1.0.4 oder der Entwicklerversion = vdr-xineliboutput aus dem cvs.
Hier verhält es sich wie bei der xinelib, die cvs-Version kennzeichnet die Entwicklerversion des Plugins und hat etliche Neuerungen drinnen, die speziell mit xine-vdpau/VDR/HD abgestimmt sind.
Neueste Features sind HD-OSD, spezielles HD-Buffer und einige Bugbereinigungen. Die cvs-Version und auch die 1.0.4er-Version laufen grundsätzlich mit den beiden xinelib-vdpau-Zweigen, haben aber den einen oder anderen Nebeneffekt, dazu später mehr.
Grundsätzliche Empfehlung
Mein Favorit (Stand 24.08.2009)
- xine-vdpau aus dem cvs (mit Patches von Durchflieger in Version 9 = xine-vdpau-r279-crop-v9.diff.gz)
mit
- xineliboutput-1.0.4 ( mit Patch von Durchflieger in Version 8 = xineliboutput-1.0.4-vdpau-support-v8.diff.gz)
Patches vom User Durchflieger, siehe hier:
Positiv:
- sehr stabil ab r273 von xine-vdpau aus svn-Projektarchiv
- Autocropping = automatisches Aufziehen des Bildes (Letterbox-Automatik)
- schnelles Umschaltverhalten (bei PES-Buffers = 900) und sehr gute Tonerkennung auch bei PassThrough bei HD-Sendern
- Schneiden und Springen in Aufnahmen geht sehr schnell und sicher
- kein Tonerkennungsproblem bei HD-Sendern
Negativ:
- Neuerungen und Bugfixes die nach dem eingesetzten Entwicklerstand der xinelib-1.1.16 eingeflossen sind, können nicht genutzt werden.
- Wiedergabe von VDR-Aufzeichnungen im h264-PES-Format bei lokalem Frontend fehlerhaft. Abspielen über => Medien (xineliboutput hat einen eingebauten Medienplayer) geht einwandfrei.
Weiterer Zweig
xinelib-1.2 mit (vdpau-Patch = xine-lib-1.2-vdpau-r278.diff.bz2 , sowie Patch von Durchflieger in Version 9 = xine-vdpau-xine-lib-1.2-r278-crop-v9.diff.gz)
mit
xineliboutput-cvs ( mit Patch von Durchflieger in Version 8 = xineliboutput-head-vdpau-support-v8.diff.gz)
Positiv:
- HD-OSD-Erkennung via Plugin
- Automatische Video-Pufferanpassung
Negativ:
- die cvs-Version von xineliboutput hat im Moment ein ausgeprägtes Problem mit der Tonerkennung auf diversen HD-Sendern (ZDF HD, ARD HD, ) Dies äussert sich durch Bildruckler und Tonaussetzer/kein Ton für ca. 25 Sekunden.
Zusammenhang => xineliboutput versucht das Bild und den Ton synchron zu halten, deshalb kommt es in der Zeit der korrekten Tonformaterkennung zu vemehrten Framedrops, und das bedeutet Bildruckler und gleichzeitg kein Ton. An dem Problem wird sehr intensiv gearbteitet, ne Lösung steht in Aussicht.
Startmöglichkeiten des xineliboutput-Plugins und deren Auswirkungen
als lokale Variante
d.h über die RunVDR gleichzeitig mit dem VDR
\"-Pxineliboutput --local=sxfe --video=vdpau --display=:0 -p --post tvtime:method=use_vo_driver --audio=alsa:hw:0,3 -f\
Wichtig hierbei ist, da die Ausgabeparameter fürs Deinterlacing bereits mit dem Plugin-Aufruf mitgibt, dass man übers OSD im Setup zu xineliboutput keine zusätzlichen Parameter ändert (Punkt Deinterlacing = TvTime).
Vorteile:
- einige Pluginparameter können zusätzlich übers OSD gesetzt werden
Nachteile:
- VDR wird beim Beenden komplett beendet, d.h. auch bei einem inzwischen seltenen Absturz des Plugins
als Remote Variante
d.h. über seperates Startaufruf, z.B über Skript.
RunVDR:
xineliboutput --local=none –remote=37890
und seperater Aufruf, via skript, z.b start-vdrsxfe:
/usr/local/bin/vdr-sxfe -f --display=:0 "xvdr+tcp://127.0.0.1:37890" --video=vdpau --post=tvtime:method=uses_vo_driver --audio=alsa:hw:0,3 --buffers=2500 --fullscreen --reconnect >/var/log/xinelib.log 2>&1
Ich lasse alles was über die jeweilige Konsole des VDR's ausgegeben wird in ein seperates log laufen, da sieht man dann ganz gut wenn man umschaltet, was mit vdpau passiert. Minipatch dazu:
--- xine_frontend.c.org 2009-02-07 07:00:06.000000000 +0100
+++ xine_frontend.c 2009-02-07 07:00:10.000000000 +0100
@@ -481,6 +481,8 @@
if(this->xine)
this->fe.xine_exit(this_gen);
+
+ setlinebuf(stdout);
this->stream = NULL;
this->video_port = NULL;
Der Patch funktioniert sowohl mit lokalem Startaufruf, als auch mit Remote-Aufruf.
Vorteile:
- Frontend kann auch auf einem anderen Rechner im Netzwerk aufgerufen werden
- sehr stabil
- VDR (inkl. Aufnahmen) laufen auch bei Absturz des Plugins weiter
Nachteile:
- vom VDR getrennter Aufruf notwendig
Wichtige Parameter des xineliboutput-Plugins für vdpau und wo finde ich die
Wichtig dabei ist, das man Änderungen an der ./config und ./config_xineliboutput bei gestopptem VDR macht. Ansonsten werden die Änderungen überschrieben.
xineliboutput-1.0.4
zu finden meist in meist in /root/.xine/config_xineliboutput bzw. ~/.xine/config_xineliboutput
1. HD-Deinterlacing für chipsätze 8200/8300/9300/9400: Erläuterung: Bei SD-Inhalten nimmt xine-vdpau grundsätzlich den besten Deinterlacer => temporal_spatial. Bei HD-Content (= Anixe HD, Astra HD, in 1920x1080interlaced ausgestrahlt) bestimmt man den Deinterlacer mit diesem Paramter. Die onboard-Lösungen sind hardwaretechnisch nicht in der Lage höhere Dieinterlacer-Stufen zu schaffen, => Framedrops/Ruckler. Allerdings bringt der Bob-Deinterlacer mit xine-vdpau schon ein klasse Bild.
....
# vdpau: HD deinterlace method
# { bob half temporal half temporal_spatial temporal temporal_spatial }, default: 3
video.output.vdpau_deinterlace_method:bob
....
2. Parameter für Progressives Material
.... # vdpau: disable deinterlacing when progressive_frame flag is set # bool, default: 0 video.output.vdpau_honor_progressive:1 ....
3. Parameter durch DF-Patch, da xine-vdpau bei SD diese Parameter nicht regeln kann:
....
# vdpau: restrict enabling video properties for SD video only
# { none noise sharpness noise+sharpness }, default: 0
video.output.vdpau_sd_only_properties:noise+sharpness
....
4. Parameter um das Deinterlacing auf der GPU zu entlasten.
... # vdpau: disable advanced deinterlacers chroma filter # bool, default: 0 #video.output.vdpau_skip_chroma_deinterlace:0 ...
5. Anzahl Audiopuffer
.... # Anzahl der Audiopuffer # numeric, default: 230 #engine.buffers.audio_num_buffers:230 ....
6. Anzahl Videopuffer => bei Version 1.0.4 unbedingt per Hand setzen:
... # number of video buffers # numeric, default: 500 engine.buffers.video_num_buffers:2500 ....
7. Anzahl Videobilder zum Analysieren welcher Content (HD oder SD, usw.)
.... # Standardanzahl von Videobildern # numeric, default: 15 engine.buffers.video_num_frames:22 ....
xineliboutput-cvs (/etc/vdr/plugins/xineliboutput/config)
Hier stehen dann die neueren Paramter von der cvs-Version die in der 1.0.4 nicht vorhanden sind. Ansonsten siehe 2.4.6.1
Wichtige Parameter des xineliboutput-Plugins für die Video-Ausgabe und wo finde ich die
xineliboutput-1.0.4
meist in /root/.xine/config_xineliboutput
xineliboutput-cvs
/etc/vdr/plugins/xineliboutput/config
Häufig gestellte Fragen
Wie erkenne ich ob vdpau als Ausgabemethode genutzt wird?
Verlässlichste Methode ist das Loggen der Start-Konsole des VDR bzw. des Remote-Frontends (siehe obigen Patch fürs Logging), darin sollten dann solche Meldungen auftauchen:
vo_vdpau: vdpau API version : 0 vo_vdpau: vdpau implementation description : NVIDIA VDPAU Driver Shared Library 185.18.31 Tue Jul 28 16:16:15 PDT 2009 audio_alsa_out : Unterstützte Modi sind 16Bit Stereo (4-Kanal nicht aktiviert in xine Konfiguration) (4.1-Kanal nicht aktiviert in xine Konfiguration) (5-Kanal nicht aktiviert in xine Konfiguration) (5.1-Kanal nicht aktiviert in xine Konfiguration) (a/52 und DTS pass-through nicht aktiviert in xine Konfiguration) xine: Inputplugin gefunden: VDR (Video Disk Recorder) input plugin Input-Cache Plugin deaktiviert xine: Demultiplexer-Plugin gefunden: DVD/VOB demux plugin vdpau_set_property: property=0, value=1 vo_vdpau: deinterlace: temporal_spatial av_offset=0 pts vdpau_set_property: property=8, value=100 vdpau_set_property: property=2, value=0 vo_vdpau: vdpau_update_csc: hue=0,000000, saturation=1,000000, contrast=1,000000, brightness=0,000000, color_standard=0 vdpau_set_property: property=3, value=100
Warum gibts es beim Umschalten oft 1 bis 3 Sekunden Bild-/Tonaussetzer?
Beim Umschalten ist es so, das xine-vdpau erstmal ermitteln muß, was kommt als Videostream an, also SD-Content oder HD-Content. Je nachdem was ankommt und welcher Deinterlacer verwendet wird, kann das bei Datenmengen bis zu 20 MBit schon etwas dauern und es treten eben Framdrops auf. Auch das empfangene Tonformat muß aus dem Stream ermittelt werden und dann gesetzt werden. Hier im Forum wird der Vorgang "Einpendeln genannt. Je nachdem welche Hardware und Deinterlacer man einsetzt, kann das alles eben bis zu 3 Sekunden bei HD-Content dauern. Wenn der bob-Deinterlacer bei HD-Content eingesetzt wird ist das Bild sehr schnell stabil.
Kleiner Logauszug beim Umschalten, hier sehr schnell ( kleiner 1 sec.) von SD auf HD mit 1280x720:
.... vdpau_h264_reset dpb_free_all, used: 0 prebuffer=14400 pts dpb_free_all, used: 0 vdpau_set_property: property=0, value=0 vo_vdpau: deinterlace: none prebuffer=14400 pts video_out: Verwerfe Bild mit pts -4963052515, weil es zu alt ist (Unterschied: 4980652625). prebuffer=14400 pts prebuffer=14400 pts video: synced early vdpau_set_property: property=0, value=1 vo_vdpau: deinterlace: temporal_spatial Allocate 2 reference frames Create decoder: vdp_device: 1, profile: 7, res: 1280x720 ....
Kleiner Logauszug beim Umschalten, hier schnell ( kleiner 2 sec.) von HD mit 1280x720 auf HD 1920x1080:
.... vdpau_h264_reset dpb_free_all, used: 0 dpb_free_all, used: 0 vdpau_set_property: property=0, value=0 vo_vdpau: deinterlace: none prebuffer=14400 pts prebuffer=14400 pts video: synced early vdpau_set_property: property=0, value=1 vo_vdpau: deinterlace: temporal_spatial buf underrun 1!! Allocate 4 reference frames Create decoder: vdp_device: 1, profile: 8, res: 1920x1080 FLUSH draw pts: 4016907546 FLUSH draw pts: 4016911146 FLUSH draw pts: 4016914746 FLUSH draw pts: 4016902146 FLUSH draw pts: 4016921946 FLUSH draw pts: 4016925546 FLUSH draw pts: 4016929146 FLUSH draw pts: 4016932746 FLUSH draw pts: 4016947146 vo_vdpau: deinterlace: temporal_spatial vo_vdpau: enabled features: inverse_telecine=1 vo_vdpau: disable noise reduction. vo_vdpau: disable sharpness. vo_vdpau: vdpau_update_csc: hue=0.000000, saturation=1.000000, contrast=1.000000, brightness=0.000000, color_standard=1 vo_vdpau: skip_chroma = 0 video_out: Verwerfe Bild mit pts 17932105, weil es zu alt ist (Unterschied: 16201). video_out: Verwerfe Bild mit pts 17919505, weil es zu alt ist (Unterschied: 28801). video_out: Verwerfe Bild mit pts 17924185, weil es zu alt ist (Unterschied: 24121). video_out: Verwerfe Bild mit pts 17928829, weil es zu alt ist (Unterschied: 19477). video_out: Verwerfe Bild mit pts 17933438, weil es zu alt ist (Unterschied: 14868). video_out: Verwerfe Bild mit pts 17938013, weil es zu alt ist (Unterschied: 10293). FLUSH draw pts: 4016936346 FLUSH draw pts: 4016939946 FLUSH draw pts: 4016943546 FLUSH draw pts: 4016950746 FLUSH draw pts: 4016954346 FLUSH draw pts: 4016957946 FLUSH draw pts: 4016961546 FLUSH draw pts: 4016965146 FLUSH draw pts: 4016968746 FLUSH draw pts: 4016972346 FLUSH draw pts: 4016975946 FLUSH draw pts: 4016979546 FLUSH draw pts: 4016983146 FLUSH draw pts: 4016990346 video_out: Verwerfe Bild mit pts 17942916, weil es zu alt ist (Unterschied: 5492). 200 Bilder angezeigt, 0 Bilder übersprungen, 8 Bilder verworfen ....
Tips zur Einrichtung des X-Servers, hier speziell xorg.conf:
Wichtige Modelines in der xorg.conf:
...
Section "Monitor"
Identifier "Monitor"
VendorName "Unknown"
ModelName "FUS LSL 3230T"
HorizSync 15.0 - 82.0
VertRefresh 29.0 - 86.0
Option "UseDisplayDevice" "DFP-0"
Option "ExactModeTimingsDVI" "True"
Option "UseEDIDFreqs" "False"
# 1920x1080p @ 50Hz (EIA/CEA-861B)
ModeLine "1920x1080@50" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
# 1920x1080p @ 60Hz (EIA/CEA-861B)
ModeLine "1920x1080@60" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
# 1920x1080p @ 24Hz (EIA/CEA-861B)
ModeLine "1920x1080@24" 74.250 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync
# 1920x1080p @ 23.976Hz (EIA/CEA-861B)
ModeLine "1920x1080@23.976" 74.175 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync
# 1920x1080i @ 50Hz (EIA/CEA-861B)
# Modeline "1920x1080@50i" 74.250 1920 2448 2492 2640 1080 1085 1095 1125 +hsync +vsync Interlace
# Modeline "1920x1080@50i" 74.184 1920 2408 2496 2640 1080 1084 1094 1124 -hsync -vsync interlace
# Modeline "1920x1080@50i" 74.25 1920 2440 2456 2640 1080 1083 1085 1125 +hsync +vsync interlace
# Modeline "1920x1080@50i" 74.25 1920 2448 2492 2640 1080 1084 1094 1124 +hsync +vsync interlace
ModeLine "1920x1080@50i" 74.200 1920 1964 2052 2200 1080 1084 1088 1125 +hsync -vsync interlace
# 1920x1080i @ 60Hz (EIA/CEA-861B)
Modeline "1920x1080@60i" 74.250 1920 2008 2052 2200 1080 1085 1095 1125 +hsync +vsync Interlace
# 1920x1080p @ 59.94Hz (EIA/CEA-861B)
ModeLine "1920x1080@59.94" 148.350 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
# 1920x1080i @ 59.94Hz (EIA/CEA-861B)
Modeline "1920x1080@59.94i" 74.175 1920 2008 2052 2200 1080 1085 1095 1125 +hsync +vsync Interlace
# 1920x1080p @ 25Hz (EIA/CEA-861B)
ModeLine "1920x1080@25" 74.250 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
# 1920x1080p @ 29.97Hz (EIA/CEA-861B)
ModeLine "1920x1080@29.97" 74.175 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
# 1920x1080p @ 30Hz (EIA/CEA-861B)
ModeLine "1920x1080@30" 74.250 1920 2008 2052 2200 1080 1084 1089 1125 +hsync
"1920x1080" 20.048 1920 2448 2492 2640 1080 1085 1095 1125 interlace +hsync +vsync
EndSection
.....
Diese Modelines sind für alle gängigen Video-Formate in Verbindung mit dem Nvidia-Treiber nutzbar. Man sollte darauf achten, dass das verwendete Display mit einem 50 Hz-Mode angesprochen wird, also 50 Hz interlaced oder 50 Hz Progressive.
Das verhindert in meinen Augen sehr oft Bildhänger und leichte Ruckler.
Tearing (= Trennung des Bildes durch eine waagrechte Linie) vermeiden
- kein Compositting aktiv, auch kein compiz oder sonstiges
... Section "Extensions" Option "Composite" "Disable" EndSection ...
