DFAtmo der Treiber für Atmolight Controller für VDR, xbmc und xinelib basierte video player

    DANKE DANKE DANKE!!!!


    Filter Delay tut's wie s... sehr gut!!!


    :cool1


    Schade das ich das mit den GIT nicht hingekriegt habe, sonst hätt ich schon viel früher geniessen können.


    Gute Arbeit. Danke!!!

    Client1 YaVDR0.5 Zotac ITX-F ATOM330 ION, 2*1GB DDR2, 8GB Boot SSD, MS-Tech MC1200, Alphacool 240x128, Quattro Atmolight


    Server1 YaVDR0.5 Athlon LE1600, DigitalDevices Cine S2,8GB Boot SSD, 1TB WD GreenCaviar


    Experimental: Banana Pi Client Sunxi-vdpau, Raspberry Client rpihddevice

    Einmal editiert, zuletzt von Jarvelin ()

    Hallo,


    auf vdr-developers.org steht die pre 0.8 Version bereit. Wird diese gegen eine xine-lib mit dem neuen df-xine-lib-extensions Patch gebaut dann funktioniert das atmo plugin auch mit weiteren video output Treibern wie zb. der xv Treiber.


    Gruss
    durchflieger

    Zitat

    Original von durchflieger
    auf vdr-developers.org steht die pre 0.8 Version bereit. Wird diese gegen eine xine-lib mit dem neuen df-xine-lib-extensions Patch gebaut dann funktioniert das atmo plugin auch mit weiteren video output Treibern wie zb. der xv Treiber.


    Sehr schön. Vielen dank dafür.
    Wird diese Woche noch an meinem xv-vdr ausgetestet.

    Hallo durchflieger,


    wie bereits angedroht eine Fehlermeldung. Wenn Du minutenweise in einer Aufnahme schnell hin und her springst, friert der komplette VDR nach spätestens 15 bis 20 Sprüngen ein. Das gleiche passiert fast immer, wenn du auf eine Schnittmarke springst und diese versuchst etwas nach links oder rechts zu verschieben.


    Im "Normalbetrieb" - egal ob live oder playback - läuft das Atmolight stundenlang ohne Probleme. Die oben geschilderte Problematik tritt nur auf, wenn der vdr mit xineliboutput wie folgt gestartet wird: "xineliboutput --local=sxfe --video=xv --remote=37890 --post atmo:driver=df10ch". Ohne den "--post atmo..." Parameter tritt der Fehler nicht auf. Die eingesetzte xine-lib habe ich heute Mittag aus dem git repo gezogen. Der Controller hängt an einem Hub, welches mit externer Spannungsquelle versorgt wird.


    Auf der Konsole wird u. a. das folgende protokolliert(ich war minutenweise in einer Aufnahme am Springen):
    atmo: output driver opened
    atmo: configure channels top 2, bottom 0, left 2, right 2, center 0, topLeft 1, topRight 1, bottomLeft 1, bottomRight 1
    atmo: max/avg transmit latency: 7147/3573 [us]
    atmo: grab thread running
    atmo: output thread running
    prebuffer=14400 pts
    atmo: output thread waiting for new ticket
    atmo: grab thread waiting for new ticket
    prebuffer=14400 pts
    atmo: output thread got new ticket
    atmo: grab thread got new ticket
    atmo: output thread terminated
    prebuffer=2000 pts
    prebuffer=14400 pts
    prebuffer=14400 pts
    atmo: grab thread terminated
    atmo: max/avg transmit latency: 7328/5450 [us]
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: max/avg transmit latency: 7843/6646 [us]
    prebuffer=14400 pts
    prebuffer=2000 pts
    prebuffer=14400 pts
    prebuffer=14400 pts
    atmo: max/avg transmit latency: 8150/7398 [us]
    atmo: output thread terminated
    atmo: grab thread terminated
    atmo: grab thread running
    atmo: output thread running
    atmo: max/avg transmit latency: 8261/7916 [us]
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: max/avg transmit latency: 9217/8271 [us]
    atmo: max/avg transmit latency: 9314/8351 [us]
    atmo: max/avg transmit latency: 13644/10719 [us]
    atmo: max/avg transmit latency: 17861/12757 [us]
    atmo: max/avg transmit latency: 19189/13223 [us]
    200 Bilder angezeigt, 5 Bilder übersprungen, 0 Bilder verworfen
    video_out: Verwerfe Bild mit pts 2579434, weil es zu alt ist (Unterschied: 3775).
    video_out: Verwerfe Bild mit pts 2874634, weil es zu alt ist (Unterschied: 3931).
    200 Bilder angezeigt, 0 Bilder übersprungen, 2 Bilder verworfen
    atmo: output thread terminated
    atmo: grab thread terminated
    prebuffer=14400 pts
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: output thread terminated
    atmo: grab thread running
    atmo: output thread running
    atmo: grab thread terminated
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: DF10CH[5,22]: submitting USB control transfer message failed: Resource busy
    atmo: output thread terminated
    atmo: grab thread running
    atmo: output thread running
    atmo: grab thread terminated
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: grab thread terminated


    ---> eingefroren



    Gruß
    Jürgen

    Hallo Jürgen,


    sieht so aus als springt dein vdr zu schnell für das atmo plugin.
    Habe ich auch schon bemerkt bei meinen Tests mit dem xv Treiber
    dass der flotter ist als mit vdpau Treiber.
    Allerdings verwende ich das vdr-sxfe auf einem eigenen Client und
    das scheint doch noch endscheidend langsamer zu sein als das locale Frontend.
    Ich bekomme das Problem bei mir nicht nachvollzogen.
    So viel zur Theorie. Probiere bitte mal den aktuellen git Stand des atmo plugin ob
    das jetzt besser bei dir geht.


    Gruss durchflieger

    Hallo durchflieger,


    das neue commit des xine-lib-atmolight Post-Plugins scheint zu funktionieren. Ich habe es nun innerhalb 20 Minuten andauernder Versuche nicht mehr geschafft den Fehler zu reproduzieren. Mit der alten Version konnte ich den Fehler jedes mal binnen höchstens 10 Sekunden provozieren.


    Ich muß ehrlich zugeben, Hut ab vor Deiner Leistung. Du konntest den Fehler lokal bei Dir nicht nachvollziehen und hast mit dem Fix, so wie es momentan aussieht, auf Anhieb einen Volltreffer gelandet. Danke!



    Gruß
    Jürgen

    Hallo durchflieger,


    ich habe die neue Version gezogen, installiert und die letzte halbe Stunde getestet. Vor- und Zurückspringen in den Aufnahmen funktioniert ohne Probleme, ebenso das Verschieben von Schnittmarken.


    Jedoch ist mir noch eine Kleinigkeit aufgefallen. Man nehme eine "frische" Aufnahme und lasse noad über die selbige laufen zwecks Markieren der Werbeblöcke. Wenn Du nun in die Aufnahme gehst und der VDR versucht diese von der ersten Markierung an abzuspielen passiert zuerst einmal nicht viel. Das Playback wird gestartet und aus deinem vorherigen Live Bild wird ein Standbild. Drückst Du keine Taste an der FB, bleibt die Kiste in dem beschriebenen Zustand (4 Minuten gewartet). Andernfalls kannst Du nach ca. 5 bis 10 Sekunden versuchen die Pause Taste zu drücken und dann läuft das Playback ab. Frage mich bitte nicht womit das zusammenhängt, ich habe nicht den blassesten Hauches eines Schimmers einer Ahnung.... Die Version des atmo-Plugins von gestern zeigt das gleiche Verhalten und ohne atmo-Plugin tritt dieser Effekt nicht auf.


    Im übrigen hier dann noch die Meldungen der Konsole:


    atmo: DF10CH[5,23]: device opened
    atmo: output driver opened
    atmo: configure channels top 2, bottom 0, left 2, right 2, center 0, topLeft 1, topRight 1, bottomLeft 1, bottomRight 1
    atmo: max/avg transmit latency: 7329/3664 [us]
    atmo: grab thread running
    atmo: output thread running
    prebuffer=14400 pts
    atmo: output thread waiting for new ticket
    atmo: grab thread waiting for new ticket
    prebuffer=14400 pts
    atmo: output thread got new ticket
    atmo: grab thread got new ticket
    atmo: output thread terminated
    atmo: grab thread terminated
    prebuffer=2000 pts
    prebuffer=14400 pts
    prebuffer=14400 pts
    atmo: max/avg transmit latency: 8001/5832 [us]
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    prebuffer=14400 pts
    atmo: grab thread terminated
    atmo: max/avg transmit latency: 10547/8825 [us]
    atmo: output thread terminated
    prebuffer=2000 pts
    prebuffer=14400 pts
    prebuffer=14400 pts
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: max/avg transmit latency: 14006/10650 [us]
    atmo: max/avg transmit latency: 14505/11378 [us]
    atmo: max/avg transmit latency: 17021/12466 [us]
    atmo: max/avg transmit latency: 19036/13283 [us]
    200 Bilder angezeigt, 0 Bilder übersprungen, 3 Bilder verworfen
    video_out: Verwerfe Bild mit pts 4141227, weil es zu alt ist (Unterschied: 4147).
    200 Bilder angezeigt, 0 Bilder übersprungen, 1 Bilder verworfen
    prebuffer=14400 pts
    atmo: output thread terminated
    atmo: timeout while waiting for thread stop!
    atmo: grab thread terminated
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17



    Gruß
    Jürgen

    Hallo Jürgen,


    bitte teste doch noch einmal den aktuellen git-Stand des atmo plugin. Ich habe das thread handling
    nochmals vollständig überarbeitet. Springen in Aufnahmen und umschalten der Kanäle sollte jetzt
    noch weniger von dem Plugin ausgebremst werden.
    Weiterhin hoffe ich dass damit auch dein letztes gemeldetes Problem behoben wird.


    Gruss
    durchflieger

    Hallo durchflieger,


    ich habe die neue Version des atmo plugins nun rund eine Stunde lang getestet, sprich gequält. Mir ist es in dieser Zeit nicht mehr gelungen, auch nur einen der beiden Fehler zu reproduzieren. In den Aufnahmen springen bzw. Starten des playbacks auf einer Markierung usw. scheinen nun perfekt zu laufen. Werde es aber noch etwas weiter testen und Dich auf dem Laufenden halten.


    Gruß
    Jürgen

    Hallo,


    auf vdr-developer.org steht die neue Version 0.8 zum Download bereit.
    Auszug aus der HISTORY:


    Code
    Added support for df-xine-lib-extensions patch. Now this plugin can also be used with other xine output drivers (e.g. xv)
thanks to the new frame grabbing support of the df-xine-lib-extensions patch for these output drivers.
Support for (old) vdpau-extensions-patch has been dropped. Now df-xine-lib-extensions patch >= v21 is required!
Fix and optimize handling of grab and output thread. Now the delay on video port open/close action that is caused by the
plugin should be lesser than in previous versions resulting in (for vdr) faster channel switching and jumping within recordings.


    Gruss
    durchflieger

    Hallo,


    das native xine Atmolight plugin Projekt wird jetzt abgelöst von meinem neuen Projekt DFAtmo.
    Die Namensänderung war notwendig da DFAtmo neben der xinelib jetzt auch XBMC unterstützt. :)


    Aber auch das xinelib plugin hat im DFAtmo ein wenig Funktionalität zugelegt:
    Der Treiber für den "classic" Controller (der jetzt in "serial" umbenannt wurde) kennt neue Optionen
    in seinem "driver" Parameter. Mit der "proto:" Option kann die Bytesequenz, die zum Controller gesendet
    wird, frei definiert werden. Damit kann eine beliebige Zuordnung von Area/Farbe zum Controllerkanal vorgenommen
    werden. Das dürfte hier einigen Usern zugute kommen, die bisher Hand an den Sourcecode legen mussten.


    Weitere Informationen findet ihr im README.
    Bezugsquelle ist:
    https://github.com/durchflieger/DFAtmo


    Gruss
    durchflieger

    Hallo Durchflieger,


    vielen Dank für das Update!


    Atmo Unterstützung für XBMC war schon lange ein Wunsch von mir...


    Daumen hoch!!!


    LG

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

    durchflieger


    Wäre es möglich bzw. sinnvoll (wegen lag etc.) DFAtmo so zu erweitern um als "Client" für OLA (Open Light Architecture) zu fungieren?
    Durch den Einsatz von OLA und den DMX512 Standard hat man ein breites Spektrum an unterstützter Hardware.


    Damit wären z.B. In Kombination mit dem folgenden Controller 16 Separate RGB Kanäle realisierbar.


    Was hälst Du davon?



    Gruß
    tec

    Für den von dir genannten Controller benötigt man doch zusätzlich noch einen USB/DMX Konverter.
    Die Auswahl an Atmolight-Controllerhardware die einfach per RS232/USB angeschlossen wird ist dagegen mittlerweile auch schon recht ordentlich.
    Einen OLA output driver für DFAtmo zu realisieren sollte mit überschaubaren Aufwand machbar sein. Es gibt da ja offenbar ein C++ Interface.


    Gruss
    durchflieger

    Zitat von durchflieger

    Für den von dir genannten Controller benötigt man doch zusätzlich noch einen USB/DMX Konverte

    Genau, und der sollte auch möglichst "buffered" sein und über eine galvanische Trennung zwischen den beiden Schnittstellen verfügen.


    Da meine Beleuchtung etwas größer ausfallen wird als ein reines "Atmo-Light" hinterm TV (komplettes Wohnzimmer) ist DMX512 dafür bestens geeignet und im Zusammenspiel mit dem "Licht-Server" OLA auch sehr flexibel und reich an Möglichkeiten was die Steuerung angeht.
    Da kam mir sofort die Idee DFAtmo als Input für bestimmte Kanäle zu nutzen und der indirekten Beleuchtung hinterm TV etwas mehr Leben einzuhauchen.
    AtmoWin z.B. hat DMX512 als Ausgabegerät implementiert. Dort wird jedoch über eine serielle Schnittstelle direkt ein DMX Demuxer/Dekoder angesprochen.


    Könntest Du dir vorstellen das irgendwann auf deine TODO-Liste zu setzen und mit der OLA Client API ein weiteres Outputdevice in DFAtmo zu integrieren?



    Gruß
    tec

    Der Aufwand eine OLA Testumgebung zu erstellen und der Test selber ist mir zu hoch. Die DFAtmo output driver Schnittstelle ist sehr einfach gehalten.
    Falls du selber über ein paar C/C++ Kenntnisse verfügst denke ich kannst du es selber realisieren. Für Fragen diesbezüglich helfe ich dir dann gerne
    weiter.


    Gruss
    durchflieger

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden