Beiträge von afran

Ich habe das Problem nun mit der Holzhammermethode behoben. Statt wie bisher auf Basis von Debian und e-tobi.net-Quellen einen VDR selbst zusammenzustellen, habe ich mich für yaVDR als fertige Distribution entschieden.

Bei yaVDR (0.4.0) war es dabei nötig, im Webinterface die Ausgabe von xine-lib auf xineliboutput mit aktiviertem HUD (experimentell) umzustellen. In der Plugin-Konfiguration von xineliboutput (im VDR selbst) dann noch von Hardware- auf Software-Rendering gewechselt, und schon habe ich ein absolut ruckelfreies und hübsch anzusehendes OSD.

Das einzige, was bleibt, ist ein winziger Mikroruckler (< 50 ms) beim Einblenden des OSD, wobei der vermutlich bedingt durch die beiden Overlays (VDPAU und OpenGL?) nicht vermeidbar ist. Wenn man nicht genau darauf achtet, fällt er aber nicht auf. Beim Wechsel von Menüpunkten und bei sonstigen Aktualisierungen jedenfalls verhält sich das OSD nun wie gewünscht absolut neutral dem darunterliegenden TV-Bild gegenüber: keine Ruckler, kein Lagging, so soll es sein.

Als positiven Nebeneffekt durch yaVDR habe ich jetzt auch XBMC kennengelernt, von dem ich absolut begeistert bin. Tolle Software!

Zitat von johns

Nimm die aktuelle xine-lib aus [patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support da ist es fast weg.

Danke für den Hinweis.

Zitat

Ansonsten gibts genug Threads OSD ruckelt und ION2.

Ist das, was bei den IONs passiert, auf mein System übertragbar? Ich habe ja keine integrierte Nvidia ION-Lösung, sondern eine dedizierte Nvidia-Grafikkarte. Auch ruckelt das TV-Bild nicht bei geöffnetem OSD, sondern nur dann, wenn sich im OSD auch etwas tut. Bleibt das OSD statisch geöffnet, läuft das TV-Bild im Hintergrund wunderbar.

Ich habe einen VDR auf Basis eines Intel Atom-Boards und einer Nvidia-Karte aufgebaut: ASUS AT5NM10-I [1] mit Zotac GeForce GT 430 [2]. Die Ausgabe soll mit VDPAU und xineliboutput-plugin erfolgen, die Karte sitzt im PCI-Slot (nicht PCIe, den hat das Board nicht). Soweit funktioniert das System auf Basis von Debian squeeze und den e-tobi.net-Quellen ganz passabel. Das folgende, schwerwiegende Problem ergibt sich jedoch:

Wann immer sich im OSD etwas tut, z.B. wenn man es aufruft, einen Menüpunkt wechselt oder sich beim Abspielen einer Aufnahme die Sekundenanzeige aktualisiert, gibt es einen spürbaren Hänger von ca. 1/2 Sekunde (halbe Sekunde). Das TV-Bild stockt währenddessen natürlich auch, was das OSD derzeit unbenutzbar macht: nicht einmal die aktuelle Kanal-Info läuft ruckelfrei.

Um das Problem abzugrenzen: Es sind ansonsten keine Ruckler erkennbar, d.h. zum einen keine "Mikroruckler" während der Wiedergabe ohne OSD, zum anderen auch keine Ruckler jeglicher Art, wenn das OSD geöffnet, aber statisch ist. Das OSD erscheint halbtransparent, das klappt soweit also auch.

Ich habe bereits die verschiedenen Parameter für --hud bei vdr-sxfe ausprobiert. Bei normaler Composite-Ausgabe (ohne Angabe von --hud) kommt es zu obigem Phänomen. Bei --hud=xshape ergibt sich das gleiche Problem, aber zusätzlich bleiben weiße Reste im OSD stehen. Bei --hud=opengl ist das OSD an sich in Ordnung, es ist flüssig, sieht super aus und lässt sich ohne Ruckler bedienen. Allerdings verschwindet hier immer das komplette TV-Bild, wenn irgendein OSD aktiv ist! D.h. damit lässt sich leider auch nichts anfangen. (Das gleiche Problem ergibt sich bei Angabe des Paremeters --opengl dauerhaft: kein TV-Bild zu sehen, Ton funktioniert aber.) Eine Verwendung des Plugins xine-lib anstelle von xineliboutput erzeugt leider keine Besserung: hier ruckelt die Ausgabe dauerhaft, solange ein OSD sichtbar ist (ansonsten aber ebenfalls flüssig mit VDPAU).

Weiß jemand, worauf diese Symptome hindeuten könnten? An sich klappt ein ruckelfreies OSD, wie --hud=opengl demonstriert. Auch mit der Konkurrenz-Software mythtv erhalte ich ein ruckelfreies, halbtransparentes OSD bei VDPAU-Ausgabe. Die Hardware selbst sollte also durchaus leistungsfähig genug sein, ein OSD beim VDR zu bewältigen. Ich tippe daher auf ein Software-Problem. Bei Composite-Ausgabe steigt während der Hänger die CPU-Last des Prozesses vdr-sxfe auf Maximum, fällt dann aber sofort wieder ab. Bei --hud=opengl gibt es keine Hänger, dementsprechend sind hier auch keine Auslastungsspitzen vorhanden.

Ein Umstellung der OSD-Ausgabe bei xineliboutput (d.h. Umschalten zwischen software und hardware), ergibt keine Besserung. Lediglich ein starkes Reduzieren der OSD-Auflösung lindert das Problem, behebt es aber nicht endgültig. Selbst auf PAL-Auflösung sind noch deutliche Ruckler zu bemerken (vllt. 100 ms bei jeder Aktualisierung), und das Menü ist auf dem 1920x1080-Fernseher schon nicht mehr wirklich ansehnlich. Wenn sich die Composite-Ausgabe nicht realisieren lässt, wie verhindere ich bei --hud=opengl, dass das TV-Bild immer verschwindet, sobald ein OSD auftaucht?

Ich bin über jeden Hinweis dankbar!

afran.

[1] http://geizhals.at/deutschland/495821
[2] http://geizhals.at/deutschland/652586

EDIT: Inzwischen habe ich das Problem mit einem Distributionswechsel umgangen. Details siehe Beitrag 5.

Danke an vdr_rossi und SHF für den Hinweis auf den Full TS-Mod!

Ich habe mir zwischenzeitlich eine TT DVB-S rev. 2.3 besorgt und den Mod ausgeführt (Karte von eBay, Komponenten von Farnell). Meine Lötkenntnisse waren glücklicherweise noch nicht soweit eingeschlafen und auch mein Löt-Equipment war noch tauglich, so dass der Mod problemlos geklappt hat.

Damit habe ich nun zumindest die weiteren Symptome (träges Interface, Fehler im OSD etc. bei aktiver Aufnahme auf der FF-Karte) beseitigen können. Insofern bin ich in der Beziehung nun richtig happy.

Was bleibt ist die fehlende komfortable Anpassbarkeit des VDR in Bezug auf Auswahl des Aufnahme-Devices. Ist da evtl. in den kommenden Versionen etwas geplant, d.h. dass die gesamte Auswahl (sind ja doch ein paar Aspekte mit verschiedenen Prioritäten, die da im Quellcode abgearbeitet werden, bevor die endgültige Auswahl auf ein Device fällt) per OSD oder Konfig angepasst werden kann?

Ein händischer Hack mit Neukompilieren aus den Debian-Quellen scheitert leider daran, dass anschließend meine VDR-Binary nicht mehr kompatibel zu den installierten Plugins ist; was mich etwas irritiert, da ich die Debian-Quellen (apt-get source ...) verwendet habe: da sollte doch eine binärkompatible Binary rauskommen, oder? (Ich verwende das VDR-Repository von e-tobi.net.)

Nun, wenn jemandem noch etwas dazu einfällt, kann er das ja hier kundtun. Ansonsten ist der Fall nun nicht mehr so kritisch, da zumindest der VDR nach dem Full TS-Mod noch bedienbar bleibt, wenn die Auswahl auf die FF-Karte fällt (was in 99 % der Fälle der Fall ist; HD-Aufnahmen kommen bei mir quasi nicht vor).

Zitat

Originally posted by vdr_rossi

Ein Full TS Mod würde da auch helfen.

Würde dieser Mod hier etwas bringen? Es kommt nicht zu Datenverlusten oder Bildaussetzern, nur das OSD und/oder LIRC reagieren während einer Aufnahme auf der FF-Karte vergleichsweise träge. Das ist nicht der Fall, wenn die Aufnahme über die USB-Karte läuft (bei Aufnahme von DVB-S2-Kanälen).

Zitat

Originally posted by gda
Warum dann nicht VGA2SCART einsetzen? VGA haben doch die meisten Karten.

Du meinst, über die normale Grafikkarte? Ich habe leider nur onboard-Grafik (Intel-Chipsatz) ohne Hardware-Decoder, und im einzigen PCI-Slot (kein AGP o.ä.) sitzt schon die FF-Karte, sprich Nachrüsten ist nicht ohne Weiteres möglich.

Ich habe folgenden Aufbau: eine Full-Featured-PCI-Karte (TechnoTrend DVB-S rev. 1.6) sowie eine USB-2.0-Karte (TechnoTrend TT-connect S2-3650 CI). Die TV-Ausgabe erfolgt dabei ausschließlich über die Full-Featured-Karte (DVB-S) mittels Plugin "dvbsddevice"; die DVB-S2-USB-Karte soll mittelfristig mal Bestandteil eines neuen VDRs werden, dient aktuell aber primär der Aufnahme von DVB-S-Sendungen bei gleichzeitigem Live-TV-Betrieb (nicht HD).

Nun ist es jedoch so, dass bei einer (DVB-S-)Aufnahme die TV-Wiedergabe kurz unterbrochen wird: VDR entschließt sich, die DVB-S2-USB-Karte freizuhalten und lässt die Aufnahme über die DVB-S-Karte laufen – dies macht zunächst auch Sinn, da die DVB-S2-Karte "flexibler" ist und sowohl DVB-S2- als auch DVB-S-Aufnahmen ausführen kann; sie wird also für etwaige weitere Aufnahmen freigehalten.

In meiner Konfiguration ist dies jedoch sehr störend: die TV-Wiedergabe wird unterbrochen, außerdem wird durch die dann höhere System-Belastung (Stream von USB- auf FF-Karte/Wiedergabe, und Stream von FF-Karte auf Festplatte/Aufnahme) der VDR vergleichsweise träge (spürbare Verzögerungen bei Fernbedienungseingaben, per LIRC mit seriellem home-brew Empfänger).

Meine Frage lautet: gibt es eine Einstellungsmöglichkeit, mit der ich den VDR anweisen kann, die DVB-S2-Karte nicht freizuhalten? D.h. die FF-Karte soll als "primary DVB device" möglichst nicht unterbrochen werden, auch wenn dadurch Flexibilität bei DVB-S2-Aufnahmen verloren gehen würde. In meinem Fall ist es sowieso so, dass ich zwar DVB-S2 aufnehmen, aber mit der FF-Karte nicht wiedergeben kann, d.h. 99 % aller Aufnahmen werden nicht HD/DVB-S2 sein.

Wenn es eine solche Option (noch) nicht gibt, wie hoch wäre der Aufwand, das einzuprogrammieren bzw. zu patchen? Ich kenne die Code-Basis des VDR leider nicht wirklich gut, daher kann das vielleicht jemand anderes besser beurteilen. Ein fertiger Patch wäre natürlich noch besser!

Viele Grüße!

EDIT: Mein VDR ist v. 1.7.16 auf einem Debian squeeze-System mit den Paketquellen von e-tobi.net.

EDIT: Bezeichnungen FF-Karte und TT-Karte klarer formuliert: FF-Karte ist die Full-Featured-Karte mit DVB-S (TT DVB-S rev. 1.6).