So nun hoffentlich der finale Artikel zum Thema Ruckler während des HD Playbacks. Nachdem ich mir sogar ein neues Board (AMD FUsion zum Test) geholt hatte , musste ich leider feststellen, dass das Thema alles andere als einfach zu Debuggen ist.
Nach nunmehr mehreren Monaten des Suchens hab ich den letzten Verursacher von Bildrucklern gefunden. Am ende liefen nicht mal H264 Videos im Baseline-Profile ordentlich Ruckelfrei. Da hab ich in meiner Verzweifelung (und Hoffnung) mal das HDMI Kabel getauscht. Zum Glück hatte ich kein Ersatz und fand den Input-Converter DVI-HDMI meines TVs nicht. Folglich musste ich auf das “gute alte” VGA-Kabel ausweichen. Sowohl Board als auch TV hatten den Anschluss noch. Und siehe da, ruckelfreies H264 in allen Lebenslagen! Kein störendes Bildstottern oder Fragmente. Alles so wie es sein soll.
Da ich nicht glauben wollte, dass das Kabel defekt war oder gar ein genereles Problem mit HDMI vorliegt, hab ich mich mal auf die Suche nach “Bildverbesserern” auf Seitens des TVs gemacht. Ich wurde fündig. Ein bisschen vergraben wendet mein TV allerhand Algorithmen auf das Eingangssignal an. Allerdings nur auf das HDMI Signal. Standardmäßig waren die Einstellung wohl zu viel für die kleine CPU des TVs. So dass es statt zu Verbesserungen zu Fragmenten und Stottern kam. Sehr brauchbar.
Fazit: Wer ein modernes Display mit HDMI Input betreibt, kann nicht davon ausgehen, dass sein Eingangssignal auch ohne Veränderung ausgegeben wird. Kommt es zu Rucklern, Fragmenten oder anderen sporadischen Bildfehlern, einfach mal nachschauen ob nicht irgendwo ein Bilderverbesserer wie “Rauschunterdrückung”,”Bewegungsglättung” oder gar “Upscaler” sein Unwesen treibt.
Nach meinen ersten Maßnahmen gegen MicroRuckler hat es ein wenig gedauert bis ich den letzten Verursacher gefunden hatte. Das Problem war, dass die Ruckler nur sporadisch ab und zu auftraten. Mal 30 Minuten lang gar nicht, dann wieder im 5 Minuten Takt.
Als Verursacher hat sich das PerformanceManagement der NVidia-Karte herausgestellt. Die Taktet die Karte runter, sobald wenig Leistung gebraucht wird. Scheinbar dauert das Justieren zu lange, so dass es zu FrameDrops kommen kann.
Zur Behebung hab ich folgendes in die ‘/etc/X11/xorg.conf’ eingepflegt:
Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" Option "NoLogo" "True" Option "NvAGP" "1" Option "RenderAccel" "true" Option "TripleBuffer" "True" Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1" EndSection
Die Vorletzte Zeile aktiviert den TripleBuffer, so werden 3 statt zwei Bilder vorgehalten. In 2D Anwendungen (Videodarstellung) ist der Performanceverlust und Speicherverbrauch verkraftbar gegenüber der ruckelfreiem Abspielen.
Der letzte Befehl erzwingt vom NVidia-Treiber, dass die Grafikkarte immer mit maximaler Leistung arbeitet.
Sollte es immer noch zu leichten Ruckler kommen, kann man den Treiber nochmals mittels nvidia-settings dazu zwingen, endlich in den PerformanceMode zu gehen…:
nvidia-settings -a '[gpu:0]/GPUPowerMizerMode=1'
Wenn man durch die Foren schaut, stolpert man immer mal wieder über das Problem, dass einige Nutzer Micro-Ruckler bekommen wenn sie 720p oder 1080p Quellen abspielen. Ich gehörte auch zu dieser Problemgruppe und will hier kurz beschreiben wie man das Problem angehen kann.
Als erstes muss man die Mikro-Ruckler erst mal eindeutig einer “Quelle” zuordnen. Es gibt sehr viele Möglichkeiten, wie Mikro-Ruckler zu Stande kommen können:
- Kodierfehler – die Ruckler z.B. tretet nur bei einem Film auf.
- Frame-Drops – Das passiert wenn ein Bildwiederholfrequenz der Quelle höher ist als die Abspielfrequenz.
- Falsche Timings bei der Ansteuerung des Bildschirms.
- “andere Störenfriede”…
In meinem Fall konnte ich Kodierfehler ausschließen. Alle Filme wiesen sporadisches extrem kurzes Ruckeln auf. Einige Leute haben es nicht mal war genommen, mich hat es hingegen schon genervt (besonders wenn man weiß auf was man achten muss).
Um der Fehlerquelle einzugrenzen hab ich mir einige Naturaufnahmen mit langen ruhigen Schwenks in FullHD ausgesucht, dazu noch Batman – The Dark Knight wegen den starken Hell-Dunkel Kontrasten.
Als erstes hab ich die Timings wie in diesem Beitrag beschrieben korrigiert: Fixing the 24p issue.
Das hat die Ruckler zwar reduziert, aber sie waren immer noch vorhanden, das hat mich jedoch auf eine zweite Fährte gelockt. In dem Beitrag wird beschrieben wie man die Timings korrigiert und XBMC auf die Wiederholfrequenz der Quelle anpasst (Option). Durch test wurde mit ziemlich schnell klar, dass in meinen Fall nicht die Wiederholfrequenz das Problem darstellten, sondern die Timings. Eine Änderung von 60Hz auf 50Hz oder gar 24Hz hatte faktisch keinen Einfluss. Was jedoch auffällig war: sobald ich VSync abgeschaltet hatte, waren die Ruckler weg, aber die Bildfehler beim abspielen einer Testsequenz enorm. VSync musste also aktiviert bleiben. Ein kurze Suche im Internet hat mich auf die Composite-Extension aufmerksam gemacht.
Ich hab die automatische Anpassung abgeschaltet und in der xorg.conf nur einen Bild-Modus hinterlegt. Zusätzlich habe ich die Composite-Extension abgeschaltet.
Section "Extensions" Option "Composite" "disable" EndSection
Nach einem Neustart kommt es nun zu keinen Mikrorucklern mehr.
Nach langem hin und her mit Andy haben wir den Fehler/Änderung in den Interfaces zwischen XBox und “normalem” XBMC gefunden.
Ich hab ein Addon-Zip bereit gestellt: plugin.video.mediathek
Sollte sich was ändern werde ich es hier Veröffentlichen
Update – 19.09.2011 : BR Alpha hinzugefügt
Update – 20.09.2011: ARTE wieder ans Laufen gebracht.
Update – 30.09.2011: BayernFS wieder ans Laufen gebracht
Update – 18.10.2011: WDR gepatched
Update – 20.11.2011: WDR gepatched, ZDF HD Inhalte hinzugefügt, ORF aktualisiert
Update – 17.02.2012: KIKA (Without Kikaninchen) und NDR hinzugefügt. 3SAT gepatched
Wie jeder mitbekommen hat, ist die Entwicklungsphase von XBMC Dharma abgeschlossen und es wird sich dem Eden-Release zugewandt. Mit diesem Wechsel geht ein lang ersehnter Wunsch der Entwickler einher, endlich die Interne PythonEngine gegen eine externe (vom Betriebssystem bereitgestellte) Engine zu tauschen. Vorteil: viele neue Features. Nachteil: Addons für Eden sind nicht unbedingt Dharma tauglich und umgekehrt.
Bei meinem Addons gilt das noch und so hab ich sie einfach auf Eden umgelabelt. Ab heute wird es aber für die Dharma-Versionen meiner PLugins maximal noch Fehlerbehebungen geben, keine neue Features.
Mein eigenes TestRepository stellt nur die Eden-Versionen bereit. Die Dharma-Versionen können über die offiziellen Kanäle bezogen werden.
Nutzt man den VDR in Zusammenarbeit mit XBMC läuft man auf kleinere Probleme. Zum Beispiel nervt der automatische Spendersuchlauf ein wenig. Er kann sehr hilfreich sein, kann aber unnütz sein, wenn man z.b. die update-zeiten gering halten will.
Standartmäßig merkt sich VDR alle Kanäle die er über ein Update (tune in ein neues Band) mitbekommt. Das kann man abschalten. Dazu braucht es neben der channels.conf eine setup.conf. Dort trägt man den Parameter “UpdateChannels” ein.
UpdateChannels = 0
Möglichkeiten:
- 0 – Kein automatischer Sendersuchlauf
- 1 Update der Kanal-Namen
- 2 Update der PIDs
- 3 Update von Kanal-Namen und PIDs
- 4 Update von Kanal-Namen, PIDs und neu gefundenen Kanälen
- 5 Update von Kanal-Namen, PIDs sowie neu gefundenen Kanälen und Transpondern (Standard)
Quelle: Benutzerhandbuch-VDR
Gestern wurde nun endlich XBMC-Dharma released. Das bedeutet das nun endlich der PVR-Testing Branch sterben kann. Für alle die mit XBMC – TV schauen wollen wird es dann wesentlich einfacher. Da sie nicht mehr auf alternative Launchpad-Quellen oder gar Eigencompilierung angewiesen sind. Zu mindestens was XBMC betrifft.
Die Entwickler von XBMC beschreiten dabei den gleichen Weg, den die ganzen “großen” PVR-Lösungen auch beschritten haben. Es gibt eine Trennung von Wiedergabe (frontend) und Empfang (backend) des TV-Programms. XBMC Dient dabei nur als Frontend. Eine direkte Unterstützung von TV-Karten oder Video-Recording-Devices gibt es nicht. Dafür ist die PVR-Frontend-Schnittstelle modular gehalten. So das man über Plugins fast jedes erdenkliche Backend anbinden kann. Diese Plugins benötigen jedoch Änderungen im XBMC-Code, so dass es nicht reicht einfach nur das Plugin scharf zu schalten. Es benötigt einen XBMC Build aus den PVR Testing Branch.
Aktuell werden im PVR-Testing fünf Backend-Plugins angeboten. Unterstützt werden jedoch nur drei Backends. Hier eien kurze gegenüberstellung der verfügbraren Technologien:
- MediaPortal – TVServer: Das ding läuft außer Konkurenz. Da es Windows-Only ist, konnte und will ich es nicht testen. Für WIndows-User die eine Konsole scheuen sicherlich die beste Wahl.
- MythTv: Eine der ältestens und wohl umfangreichsten MediaPC-Lösungen. Auf der “Haben”-Seite verbucht MythTv einem enormen Funktionsumfang und eine große Community. Für meinen Geschmack ist das Backend aber zu aufgeblasen. Das Backend bietet den vollen Funktionsumfang einer MediaPortal – Lösung. Alles Dinge die man nicht braucht, wenn man XBMC dafür nutzen will. Hinzu kommt, dass das Plugin momentan “gebrochen” ist. Soll heißen: das Plugin spricht nur mit einer alten version von MythTv und auch dort alles andere als stabil!.
- VDR: Das VDR Backend kann gleich mit zwei Plugins angesprochen werden. VNSI oder StreamDev. Für beides muss auf VDR Seite jeweils ein Plugin mitcompiliert und aktiviert werden. Wo wir schon beim großen Negativ-Faktor. Man darf/muss alles selber machen. Es gibt noch keine gut gepflegten Packetquellen die VSNI bieten. Ausnahme das PPA des TeamVDR. Allerdings wird dort nur für Karmic angeboten (da kann man tricksen) und sie setzten beim VDR noch auf 1.7.14. Wenn man einen neueren VDR benötigt muss man sich an diese Anleitung halten und den VDR selber bauen. Danach hat man jedoch ein sehr schlankes und robustes backend mit sehr aktiver Entwickler-Community.
- HTS – TVHeadend: Dieses Backend ist zwischen MythTv und VDR angesiedelt. Mit dem Launchpad-Archive von Lars Op den Kamp hat man eine einfache Installationsart und dazu noch eine unkoplizierte Pflege des Systems. Das Backend liefert gleich einen eigenenes Web-AdministrationsInterface mit (Achtung: Passwörter werden im Klartext gespeichert) samt eigenem Webserver mit. Mit diesem kann man sofort loslegen und alles einrichten. Hat man den VLC installiert kann man auch gleich ohne jegdliches Frontend mal schnell die Streams abrufen.
Aktuell nutze ich TVHeadend. Das Umschalten (Zappen) zwischen den Sendern geht etwas langsamer als bei VNSI, das liegt wohl an dem verwendeten Streaming-Protokoll. Dafür ist das Plugin etwas ausgereifter und die Administration ist komfortabler. Zudem gibt es unter beim Bundle VDR-VNSI-XBMC noch einige kleinere Probleme bei der wiedergabe mancher Sender. Ich habe aber keinen Zweifel das VDR hier nachziehen wird.
Seit ca einer Woche bin ich dabei meine Addons in das offizielle Addon-Repo zu bekommen. Dennoch (wegen der langen Integrationszeiten) werde ich mein Entwicklungs-repo weiter pflegen.
Leider hab ich mir beim erstellen meiner bisherigen Addons einen kleinen Foupa geleistet: großbuchstaben verwendet. Deshalb müssen interessierte sowohl das Mediathek als auch das PodCatcher-addon erst deinstallieren und dann wieder installieren.
Änderungen:
- Mediathek: kleinere Bugfixes, optische Aufhübschung usw
- PodCatcher: Verbesserung der Performance (XML ersetzt durch ‘pickle’), bessere Menüführung.
Seit nunmehr zwei Monaten schraube ich an einem MediaPC/HTPC auf basis LucidLync, XBMC und VDR. Es gibt zwar einen Haufen spezialisierter Distributionen wie mythTV, yaVDR, GeexBox usw. Oder man kauf gleich eine spezielle Box beim Hardwarehändler seiner Wahl. Ich hab mich für den Eigenbau entschieden. Beginnen möchte ich mit der Hardware. Verbaut habe ich folgendes:
- Asus AT3IONT: Atom 330: Ein lüfterloses “all in one” Motherboard mit einem PCI-E Port. Einziger negativpunkt: Der RAM-Controller kann nur mit 32Bit adressieren. Soll heißen, man hat zwar einen 64 Bit Chip, kann 4GB stecken, es werden aber nur 3GB angesprochen (auch mit PAX)
- Lian Li PC-C39B: Zu diesem Chassis hab ich eine gespaltene “Meinung”. Auf der einen Seite ist das Chassis qualitativ hochwertig verarbeitet, sieht schick aus und das Design ist LianLi-typisch gut durchdacht. Auf so engen Raum hab ich noch nie so frei Hardware einbauen können., ohne mir dabei die Finger zu verbiegen. Der Haken an dem Chassis ist die mitgelieferte Fernbedienung. Es handelt sich dabei um eine RF-Fernbedienung (TSBX-2404). Was an sich genial ist, da man keine Sichtverbindung zum Empfänger braucht. Es braucht auch keinen LIRC, da der Receiver Tastencodes sendet, dummerweise auch welche mit 2Byte, die der XServer nicht verarbeiten kann. Richtig doof kommt aber der Verbauort. Man merkt, dass das Case früher mit einer IR Fernbedienung ausgeliefert wurde. Es wurde eine kleines Acryl-Fenster auf der Front vorgesehen, wohinter der Receiver montiert ist. Blöd nur, dass RF-Signale sich für Acryl nicht interessieren. Schon eher für ein vollständig geschlossenes Alu-Case. Mann nennt so was in der Physic auch Faradayscher Käfig. Die Folge: die Reichweite sinkt auf unter 2 Meter, ist lagebedingt und es macht keinen Spaß das Gerät zu bedienen.
- IR – Adapter: Als Ersatz für den verbauten RF – Controller hab ich mir einen RC6 IR-Controler verbaut.
- Logitech Harmony One: Eine teure Fernbedienung. Logitech halt. Aber Logitech Like richtig schick, richtig praktisch. Über Umwege (Concordance) auch unter Linux programmierbar.
- Thermaltake Litepower 350W. Sehr leises Netzteil nicht zu hören.
- CZ Agility2 E 2,5″ SSD 60 GB: Will SSDs haben 3 Vorteile: sie sind Lautlos, extrem schnell (diese hier 250MB/s read), brauchen kaum Strom. Letzteres ist bei Festrechner uninteressant. Der Rest macht die Dinger echt praktisch. Booten in 3 Sek (nach BIOS) und absolut keine Geräuschkulisse
- Seagate ST3250311SV 250GB: für Mitschnitte oder lokalen Cache (dazu später mehr) braucht es etwas mehr Platz.
Als Distribution kommt Ubuntu 10.04 Lucid Lynx zum Einsatz. Allerdings mit Einschränkungen. Anfangs versuchte ich mein Glück mit dem NetbookRemix. Es stellte sich jedoch bald herraus, dass einfach sehr viel mit installiert wird, was man auf einem HTPC einfach stört, ihn bremst oder anderweitig unbrauchbar ist. Zu nennen währe da der Auto-Mount sammt Notification. Dieser brachte immer XBMC in den Background. Alles in allen war es einfacher, alles komplett selber aufzusetzen als den UNR abzuspecken. Ich hab mit der Alternate-InstallCD ein reines KonsolenSystem installiert (im BootMenu F4 drücken und dann “Nur Konsole”). Dieses System ist innerhalb von einer Sekunde einsatzbereit (Login-Prompt). Als erstes brauch man den NoDM. Das ist eine “Display-Manager” der zum Ziel hat, kein DisplayManager zu haben 
Kurz es gibt keinen Loginsreen. Es wird einfach eine Default-Session mit einem vordefinierten Nutzer gestartet und doe .xsession datei ausgeführt. Alles ohne Passwort. Bei der Installation wird gleich der XServer mitinstalliert und man hat eine “grafische Oberfläche” . Nun noch den NVidia-Treiber installiert (kostet beim boot ca 1 Sek). Anschließend nach dieser Anleitung XMBC und VDR installiert.
Danach noch HAL, LIRC und DBUS nachinstallieren und schon hat man ein Funktionierendes MediaCenter mit XBMC und VDR. Und man muss gestehen XBMC ist ein extrem schicker Eyecandy…
Ein hinweis noch, sollte XBMC den HTPC nicht herrunter fahren könne, muss man sich noch dieses Kniffes betätigen damit das auch funktioniert.
Seit einiger Zeit ist es sehr ruhig in diesem Blog. Der Grund: bei meinem Arbeitgeber brummt es wieder und ich muss Überstunden schieben und zu Hause hält mich die Arbeit an einigen XBMC-Plugins vom Bloggen ab.
Heute ist es nun so weit, ich veröffentliche meine arbeiten in meinem Repository: repository.raptor2101.zip
Enthalten sind bis jetzt:
- PodCatcher: Ein Plugin zum hören von Podcastes. Verwaltung erfolgt über OPML. Mit “was wurde gehört” verwaltung.
- gamestar: Zugriff auf das VideoPortal von gamestar.de
- Mediathek: Zugriff auf die VideoPortale möglichst vieler öffentlich Rechlicher (zur zeit implementiert ARTE,ZDF,ARD)
