Atmolight... Ein paar Fragen bezüglich des grabbing

[EDIT] Titel geändert da ich die Hardware jetzt hab [/EDIT]

Hallo Portal,

Bevor ich die Hardware zusammenstelle habe ich erst mal ein wenig mit Boblight auf meinem VDR getestet, habe irgendwo gelesen es sei recht Resourcenhungrig. Ich habe vor das Atmolight auch unter XBMC zu verwenden.

Was ich gemacht hab:

- Boblight compiliert und installiert.
- Die boblight.conf eingespielt.
- Die Ausgabe Testweise aud "/dev/tty12" umgelenkt

Dann habe ich den Boblight Daemon gestartet und "boblight-X11". Alles klar soweit. Auf Konsole 12 sehe ich Lustige Zeichen. Das ganze scheint soweit zu funktionieren. VDR mittels Xine läuft Flüssig, XBMC ist etwas Träge bei der Bedienung, normale Divx Filme und SD Kontent läuft. Leider Ruckelt sich HD zutode (jede halbe Sekunde hängt es kurz - scheinbar entsprechend der eingestellten Capturezeit von 0,5 sek.).
Dann habe ich Boblight-X11 -x ausprobiert und siehe da es läuft ohne Zucken.

Jetzt meine Fragean die Boblight Nutzer:

Mit -x benutzt man ja eine andere Capture Methode und dabei steht "Slow!" Wird der Boblight Farbwechsel dadurch sehr Träge oder ist das im Rahmen?

Hat das schonmal jemand probiert? Kann es mal jemand für micht ausprobieren?

Gibt es noch weitere Methoden für Atmolight mit XBMC (Ich hab nur einen speziellen XBMC Branch gefunden - aber ich nutze den TV Branch von XBMC)?

Bin gespannt

Gruß
Atech

Rechner ist ein P4 mit 2,8GHZ, 1Gig Ram, NVIDIA 8400 PCI (!), CPU Auslastung von Boblight:

- X11 ohne -x Option: unter 1% (Gesammtlast VDR-Xine: 50%, XBMC: 30%)
- X11 mit -x Option: dauerhaft 2% (Gesammtlast VDR-Xine: 52%, XBMC: 32%)

Also nichts Weltbewegendes...

Muss mich korrigieren, der XServer benötigt mehr Rechenpower. Diese steigt mit der angegebenen pixeln in:

-g grab n pixels on n lines
default is 100 for XShmGetImage and 16 for XGetImage

-x use XGetImage instead of XShmGetImage (slow!)

Bezieht sich das "Slow!" von "-x" lediglich auf die Prozessorlast? Sind 16 Pixel schon ausreichend um ein angenehmes Atmolight zu bekommen? Ich könnte so bis 25 gehen und -x aktivieren. Dann ist die GEsammtprozessorlast nicht so hoch.

Gruß
Atech

Schieeeb

Hi,

erstmal Danke für deine Antwort. Also wenn ich dich richtig verstehe ist keines der Methoden wirklich gut aber die Plugins für VDR bzw. der XBMC Branch ist besser als Boblight . Mir schien das am einfachsten zu sein.

Ich habe immer nur die Pixel "manipuliert" nicht die Zeit. Ist die Option -x denn diesbezüglich ausrechend oder müsste ich da noch etwas abändern (sind ja jeweils 0,5 Sek. richtig)? Was ist ein guter Wert für die Zeit? Und was ist an Boblight "schlechter"?

Sorry viele Fragen aber ich hab nicht besonders viel konkretes dazu gefunden.

Gruß
Atech

Hi,

Danke für deine Erläuterung

Dann werde ich das ganze nochmal überenken. Ich hatte gehofft mit boblight-x11 die ganzen Problematiken bezüglich VDR-atmolight-Plugin und speziellem XBMC Branch zu umgehen. Das ganze muss ich ja auch erstmal compiliert bekommen und dann wirds wirklich wieder so ein Bastelding welches eher schlecht als Recht läuft

Trotzdem werde ich mich mal an drangeben wenn ich etwas Zeit hab

Gruß
Atech

Hi Leute,

ich hab jetzt alles da und soweit auch installiert. Funktioniert nun mit Boblight und XBMC. Nach einigem herumkonfigurieren sieht das ganze auch schon ganz nett aus.

Zuerst habe ich mit Atmowin unter (wer hätte es gedacht) Windows getestet und irgendwie finde ich die Farben unter Windows etwas treffender und außerdem scheint das Grabbing insgesammt schneller zu sein.

Bei Linux ergeben sich nun einige Probleme, vielleicht können mir andere Atmolight Besitzer etwas helfen:

Zunächst ist da das VDR Plugin "atmo" welches ich für die Benutzung mit xine gepatcht habe. Leider Habe ich nach dem Einschalten im VDR Menü nur noch Ruckeln. Das Menü lässt sich wie gewohnt Navigieren aber das Bild ist eine einzige Slideshow - unabhängig von HD oder SD Bild. Die CPU Auslastung ist noch im relativ normalen Bereich - liegt das evtl. einfach an der Hardware (CPU, Graka - siehe Signatur)? Oder gibt es eine Einstellung in Xine die das beeinflussen kann?

Dann wollte ich die direkte Xine Anbindung von durchflieger verwenden. Leider benötigen diese den VDPAU durrchflieger Patch. Dieser ist aber mit meiner Hardware Lösung nicht zu gebrauchen. Xine stürtzt beim Umschalten ab oder auch einfach im Menü oder im laufenden Bild. Sobald ich den Patch wieder entferne funktioniert alles. Vielleicht ist die PCI Grafikkarte dafür ungeeignet. Sicher bin ich da nicht.

Boblight funktioniert leider mit Xine-VDPAU nicht Wahrscheinlich benutzt das nicht direkt den XServer zur Ausgabe. Oder hab ich evtl. eine Einstellung übersehen?

Viele Fragen, vielleicht hat jemandähnliche Probleme schonmal gehabt oder einfach nur eine Idee....

Gruß
Atech

Schieb

Hi durchflieger,

ich benutze Archlinux mit dem sog. "Archvdr". Die Packete werden von Edgar Hucek zur verfügung gestellt. Man Kompiliert diese selber anhand von sogenannten PKGBUILD Dateien. Diese sind schnell editiert und angepasst. In der Regel belass ich sie aber wie sie sind.

Aktuelle Konfiguration:

xine-lib-1.2 11590 mit:
- silence_option_warning.patch
- http://durchflieger.dachsweb.d…v16/xine-lib-1.2-r11590-- vdpau-extensions-v16-stream-start-v100614.diff.gz
- ffmpeg_vaapi-patch

vdr-xine 0.9.3 mit

- 01_debian.dpatch
- vdr-xine-0.9.3-1.7.12.diff
- http://durchflieger.dachsweb.d…-extensions-v13.2.diff.gz)

xine-ui-cvs 2978 mit

- crash_fix_prutal.patch

nvidia 195.30 und VDR 1.7.16

Ich habe auch schon xineloibout mit deinen Patchen getestet aber leider auch nur mit Abstürtzen und Ruckeln. Wenn ich sie entferne funktioniert es. Eigentlich dachte ich die Verbesserungen bezüglich des OSD Ruckelns würden es bei mir zum laufen bewegen aber leider nicht.

So wie ich es in deinem Thread zum nativen Xine Plugin gelesen habe sind deinen VDPAU PAtches ja erforderlich für das native atmo-xine Plugin.

Falls du dir die Patches oder PKGBUILDS mal anschauen möchtest hier der Link:

http://sourceforge.net/apps/tr…vdr/browser/trunk/archvdr

Wenn ich in irgendeiner Form crashlogs benötigst musst du nur kurz erklären wie ich sie erstellen kann. In den "normalen"logs kann ich nichts erkennen (außer buffer overflows und broken pipe).

Schonmal vielen Dank für deine Hilfe

Gruß
Atech

Hi durchflieger,

hier sind die logs von xine und xinelibout. Es ist zur Zeit des Logs noch kein Atmo plugin in irgeneiner Form aktiv.

Sowohl vdr-xine mit xine-ui als auch xineliboutput zeigen garkein Bild außer dem jeweiligen "no-signal" Logo. Daraufhin stürtzen beide Programme ab. VDR-xine konnte ich schonmal ein Bild entlocken, aber dann schmiert es beim Umschalten ab.
Wenn ich deine patches herausnehme funktionieren beide Plugins

Da deine vdpau-patches ja Vorraussetzung für das native xine-atmolight Plugin sind habe ich das noch nicht getestet. Lediglich das vdr-plugin atmo habe ich ausprobiert. Dieses aktiv zeigt xine nur noch Ruckeln. Bedienung des VDR Menüs und Umschalten ist aber möglich. Da die CPU Last nicht uber 50% hinausgeht schätze ich es iegt an der gesammt Rechnerperformance.

Mal gespannt was du zu den logs sagtst...

Gruß
Atech

Danke für deione Hilfe

Ich werde wenn etwas Zeit ist mal yaVDR installieren und damit mal Testen. Mal sehen ob der Fehler da überhaupt auftritt...

Gruß
Atech

Hallo,

nach einigen Versuchen mit der cvs version von Boblight will ich mal wieder Berichten:

Über die Einstellungen der boblight.so (mittels boblight-X11 -o interpolation=on ... etc.) kann man auch die Geschwindigkeit regeln. Mit "speed=50" habe ich das Flackern der LEDs (trat je nach Bild auf) in den Griff bekommen. Das Licht wirkt recht dynamisch, wenn auch nicht so schnell wie mit Atmowin. Insgesammt aber wesentlich besser als vorher mit der 2009er Version und vorallem nicht Resourcenhungrig. Das Atmolight braucht somit rund 9 Watt zusätzlich zum normalen Verbrauch (9W = zusätliche Rechenpower + Atmolight + LED Streifen).

Leider ist boblight mit xine und dem Videotreiber VDPAU nicht verwendbar. Boblight "sieht" das Xine Bild nicht. Im Gegenzug funktioniert die XBMC-VDPAU Ausgabe.

Wird bei Xine der Xserver Umgangen, bzw. wie wird die Ausgabe bei den Systemen organisiert? Sicher schwierig aber vielleicht weiss jemand Bescheid

Ich halt noch immer an meinen Modis (Dynamisch, Weich, etc.) fest. Allerdinsg habe ich den Eindruck, dass sich nicht besonders viel Änderungen mit den Optionen erreichen lassen.

Gruß
Atech