[ANNOUNCE] Atmolight - Release 0.1.0

  • Guten Abend,


    es gibt wieder eine neue Version des Atmolight-Plugins:


    Download hier.


    Neu hinzugekommen ist die Unterstützung des Softdevice-Plugins als
    Input-Device. Dazu wird zum aktuellen Zeitpunkt die CVS-Version des
    Softdevice-Plugins benötigt. Großer Dank fürs Testen geht hierbei an
    DKVT.


    Mit dieser Version ist für mich die Entwicklung erstmal abgeschlossen.
    Sprich: ich habe keine weiteren Punkte mehr auf der TODO-Liste.
    Ich warte somit auf Anregungen und Ideen von euch.


    Bei Fragen, Problemen, etc. bitte hier posten.


    Viel Spaß beim Testen
    Samael

  • Hallo,


    schnell OT, aber irgendwie passend, da das ATMo ja nun auch ohne FF Karte läuft.


    Wenn es jetzt Leute geben sollte, die nun Interesse an den Bauteilen/LED Leisten usw. haben, die BITTE ich noch ein wenig zu warten, da die erste Bestellung bereits läuft.


    Wenn diese erste Bestellung abhehandelt wurde, können wir gerne weitere planen. Ich habe jetzt bereits schon anfragen wegen einer weiteren Bestellung.
    Die wird auf alle Fälle kommen...


    Danke !!! ;)



    Gruß
    Papsi

    Vice President Logistics and Materials Handling of the first 40" TFT Sammelbestellung and Atmolight I + II + III

  • Samael


    GEIL!! danke. werde es gleich testen. und DANKE dass du auch fuer leute proggst die andere loesungen einsetzen als du selbst!!!


    servus ize|man


    ps. getestet hab ich noch nicht .... frau schaut gerade 'rosamunde p.' ;)

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300

  • hi Sameal,


    deine arbeit kann ich noch nicht so recht loben, da ich die teile erst noch erhalten werde und dann erst testen werde. bin mir aber sicher das es berauschend sein wird. Dein angagement zu dem thema ist aber echt Klasse !
    ich hatte schonmal wegen der kompatibilität zu avards in einem anderen thread nachgefragt.


    für mich ist das avards mittlerweile ein richtig nützliches tool geworden, allerdings kann ich mir das auch beim atmo vorstellen. vorallem weil ich jetzt richtig geld investiert habe um darüber klarheit zu bekommen
    hier mal meine idee doch eventl. mit beiden leben zu können:


    Da atmo schon als plugin vorhanden ist könnte ich mich vorstellen den avards-teil mit in das atmo-plugin aufzunehmen. Dann müsste atmo alle 10sec (oder auch länger/kürzer) das video-device für avards freigeben um eine auswertung der schwarzbereiche zu machen. so etwas ähnliches ist ja bereits schon für die 16:9 fernseher im plugin vorgesehen. Lieg ich da mit meiner vorstellung völlig daneben oder wäre das ein denkbarer ansatz.


    gruß caspar

    DIGN HV5, Gigabyte K8VT800, AMD Venice 3200+ (25W Gesamt Leistungsaufnahme im idle), 900 GB LVM Volume (../video.01),
    1 x DVB-S Nexus-S 2.3 (mod), PCI-CI V1.6, AC-Light 3.03,1 x FuSi DVB-S 1.3, Kernel 2.6.18-6-amd64, vdr-1.6.0-8 (tobi), PSone

  • Hallo caspar,


    Quote

    Dann müsste atmo alle 10sec (oder auch länger/kürzer) das video-device für avards freigeben um eine auswertung der schwarzbereiche zu machen.


    Hmm, und in der Zeit bleibt dann die Farbe vom atmolight unverändert?


    Quote

    so etwas ähnliches ist ja bereits schon für die 16:9 fernseher im plugin vorgesehen.


    Das stimmt so nicht ganz: Mit dem widescreen-Mode kann man Teile aus
    der Berechnung "rausnehmen", die auf einem Fernseher, der "per Hand"
    in den Widescreen-Modus geschaltet wurde, gar nicht angezeigt werden.


    Gruß,
    Daniel

  • korrekt, in der zeit müsste die farbe unverändert bleiben.
    ich weiß jetzt nicht genau, wie lange avards dafür braucht die schwarzbalken erkennung durchzuführen aber ich vermute mal im millisekunden-bereich. die frage wäre wie oft das atmo-plugin eine abfrage des video-devices durchführt und ob der periodische zugriff
    einer anderen routine das ganze verhalten des atmo-effektes somit in mitleidenschaft ziehen würde ?!
    caspar

    DIGN HV5, Gigabyte K8VT800, AMD Venice 3200+ (25W Gesamt Leistungsaufnahme im idle), 900 GB LVM Volume (../video.01),
    1 x DVB-S Nexus-S 2.3 (mod), PCI-CI V1.6, AC-Light 3.03,1 x FuSi DVB-S 1.3, Kernel 2.6.18-6-amd64, vdr-1.6.0-8 (tobi), PSone

  • Hallo caspar,


    Quote

    korrekt, in der zeit müsste die farbe unverändert bleiben.


    das halte ich für keine gute Idee.


    Quote

    die frage wäre wie oft das atmo-plugin eine abfrage des video-devices durchführt


    Jedes Halbbild, das entspricht 20ms.


    Quote

    ob der periodische zugriff einer anderen routine das ganze verhalten des atmo-effektes somit in mitleidenschaft ziehen würde


    Ja, würde es. Das würde z.B. das Zeitverhalten eines Filters durcheinander bringen.


    Quote

    könnte ich mich vorstellen den avards-teil mit in das atmo-plugin aufzunehmen


    Das könnte ich mir auch. Ein Problem ist bloß, daß wir mit Bildern
    von der FF-Karte rechnen, die 64x48 Pixel groß sind. AVARDS
    nimmt die volle Größe.


    Quote

    Dann müsste atmo alle 10sec (oder auch länger/kürzer) das video-device für avards freigeben


    Das wird man kaum synchronisiert bekommen.


    Quote

    um eine auswertung der schwarzbereiche zu machen


    Die Auswertung könnte man natürlich auf das verkleinerte Bild anwenden.
    Da sehe ich ein weiteres Problem.
    Die AVARDS-Funktionalität besteht eigentlich nur aus einer Hauptschleife.
    Es gibt keine einzelne Funktion, die die Auswertung macht, die man so
    ohne größere Probleme übernehmen könnte.
    Da setzt dann auch noch ein Problem auf: Man könnte natürlich
    diese Funktionalität "ausbauen". Aber da in der Quelldatei nicht
    ein einziger Kommentar vorhanden ist, geht meine Lust den Code zu
    analysieren gegen Null. Vielleicht kann der AVARDS-Entwickler die
    Erkennungsroutine ja mal auslagern und die ganze Geschichte
    kommentieren. Dann läßt sich bestimmt darüber reden.


    Grüße Samael

  • hi,


    ok, ich werde mal versuchen mit dem author vom AVARDS (Habichthugo) kontakt aufzunehmen. ggf findet ihr ja einen Nenner. wäre ne super sache !
    danke und gruß
    caspar

    DIGN HV5, Gigabyte K8VT800, AMD Venice 3200+ (25W Gesamt Leistungsaufnahme im idle), 900 GB LVM Volume (../video.01),
    1 x DVB-S Nexus-S 2.3 (mod), PCI-CI V1.6, AC-Light 3.03,1 x FuSi DVB-S 1.3, Kernel 2.6.18-6-amd64, vdr-1.6.0-8 (tobi), PSone


  • Die avards sind - zugegeben - mit heißer Nadel gestrickt. Ein paar Kommentare reinzuschreiben und die Funktionalität geeignet auszulagern ist sicher nicht das Problem. Allerdings habe ich mein ursprüngliches Bestreben, das in sauberen C(++) Code (bzw. Klassen) zu fassen aufgegeben, da es mir wohl nicht mit vertretbarem Aufwand möglich ist, zu einer geeigneten Entwicklungsumgebung zu gelangen...


    Speziell mit uns zwei Beiden (Samael) wird das wohl nix werden, denn der angeschlagene Umgangston, insbesondere implizit und (an anderer Stelle) explizit formulierte Deklassierungen, ist für meinen Geschmack keine Basis für eine konstruktive Zusammenarbeit.


    @caspar/All
    Es gibt mehrere Lösungsmöglichkeiten. Eine davon würde die avards prinzipiell vom Framebuffer der FF entkoppelt. Das habe ich im avards-Thread schon einmal andiskutiert. Dazu müsste man den MPEG-Stream selbst dekodieren, wobei eine I-Frame-Dekodierung - noch dazu monochrom (s/w) - für die avards-Zwecke ausreichend wäre, d.h. aus Performance-Sicht sollte es gehen. Dazu müssten die avards als VDR-Plugin laufen (um an den Stream zu gelangen). Diese Vorgehensweise hätte zusätzlich den Vorteil, dass die avards an ein OSD-freies kämen, also ein aufpoppendes Menü die Formaterkennung nicht beeinflusst. Allerdings müsste die FF dann im Transfermodus laufen, was sich wohl u.a. nachteilig auf die Zapp-Geschwindikeit auswirkt...Für diesen Ansatz braucht's primär 'nen Experten für MPEG-Decoding...
    Ein zweiter Ansatz ist schlicht, die Restriktion des Treibers aufzuheben, nur einem Prozess den (direkten) Zugriff auf den Framebuffer zu gewähren. Hardwaremäßig ist nur ein Scaler vorhanden, d.h. ein solcher Treiber müsste das Bildformat (Auflösung, Farbtiefe etc.) entweder fest vorgeben oder das Bild intern in maximaler Auflösung handeln und nach Anforderung der Prozesse softscalen. Auch letzteres sollte mit recht bescheidener Rechenleistung gehen, wäre der 'rund um glücklich Ansatz', d.h. es würden auch noch Sachen wie fbtv, VDR-Einzelbild-Speicherung etc. unabhängig voneinander laufen. jetzt bräucht's halt nur einen Treiberentwickler, der sich da ran setzt...
    Eine überschaubarere, rein VDR-interne, Lösung wäre, eine Klasse zu schreiben, die das (wie o.g.) handelt. Alle VDR-internen Bildverarbeiter holen sich das benötigte Bild dort ab, im einfachsten Fall in der maximalen Auflösung von 720x576(RGB/24Bit). Müsste halt nur jemand machen und sich alle anderen dran halten, u.a. also mit kls abgestimmt werden...
    Also: Wer das angehen will (caspar) darf (avards-seitig) mit meiner vollen Unterstützung rechnen, erkennbare Nachhaltigkeit des Bestrebens und vernünftiger Umgangston vorausgesetzt. Mit tiefbrett-LINUX-Coding lasst mich aber bitte in Ruhe. :unsch

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • hi,


    habichthugo/samael:
    danke für eure statements zu dem thema. für mich ist das ganze ne nummer zu hoch, d.h das ich da selber leider nicht aktiv werden kann.
    ich dachte aber ich könnte hier den startschuss für ein kleines projekt bringen.
    das das ganze nicht ganz trivial ist habe ich fast schon geahnt.
    da bleibt nur zur warten bis es vielleicht mal eine lösung gibt, die wie habichthugo beschrieben hat eine Art FF-Device-Server ist bei dem sich verschiedenste clients die Infos abholen können (kann ich mir mit meinem bescheidenem wissen am ehesten vorstellen)


    gruß
    caspar

    DIGN HV5, Gigabyte K8VT800, AMD Venice 3200+ (25W Gesamt Leistungsaufnahme im idle), 900 GB LVM Volume (../video.01),
    1 x DVB-S Nexus-S 2.3 (mod), PCI-CI V1.6, AC-Light 3.03,1 x FuSi DVB-S 1.3, Kernel 2.6.18-6-amd64, vdr-1.6.0-8 (tobi), PSone

  • Hallo,


    ich habe in meinem VDR 2 FF-Karten wobei die 2. Karte die Primäre ist. Aus diversen Gründen geht das bei mir nicht anders.


    Was kann ich tun, damit das Atmolight-Plugin diese Karte als Input-Device nimmt?


    Gruß,
    Thilo

  • Hallo Thilo,


    Du kannst in der Datei "inputffdvb.c" die Zeile 42 wie folgt ändern:


    Quote

    if ((fd=open("/dev/video1",O_RDWR)) == -1)


    /dev/video0 oder auch /dev/video ist die 1. Karte,
    /dev/video1 die 2. usw.


    Falls weitere Atmolight-Benutzer eine solche Konstellation haben sollten,
    so könnte ich die Auswahl der Karte für FFDVB-Input-Device einstellbar
    machen und würde ich das in eine 0.1.1-Version packen. Interesse?


    Viele Grüße
    Samael

  • Samael
    Diese Info dümpelt meines Wissens auch irgend wo im VDR-Basis-Code rum, bräuchte man also nicht extra parametrieren. Guck ma in der Ecke cDvbDevice::GrabImage()...

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • habichthugo
    Ja, nicht ganz. Aber exzellente Idee. Und die Ecke GrabImage() war der
    richtige Ansatz um die Lösung im VDR-Code zu finden.
    Man besorgt sich einfach die Nummer des primären Devices:
    "cDevice:: PrimaryDevice()->DeviceNumber()".
    Muß ich jetzt nur noch einbauen...


    Vielen Dank. Das macht das alles gleich universeller.


    Samael

  • Quote

    Original von Samael


    Falls weitere Atmolight-Benutzer eine solche Konstellation haben sollten,
    so könnte ich die Auswahl der Karte für FFDVB-Input-Device einstellbar
    machen und würde ich das in eine 0.1.1-Version packen. Interesse?


    Viele Grüße
    Samael


    Hallo Samael,


    danke für die schnelle Antwort.


    Ich persönlich hätte großes Interesse an einer Auswahl der DVB-Karten in der Plugin-Version 0.1.1.


    Danke im Vorraus!


    Thilo

  • Hallo Thilo,


    ich denke mal, daß die automatische Auswahl des primären Devices
    als Input-Device ausreichend ist. Oder möchtest Du explizit auswählen können?


    Mal sehen, wann ich Zeit finde. Aber groß sollte der Aufwand nicht sein.


    Samael

  • Hallo Samael,


    mir persönlich würde die Angabe als Startparameter im Sinne von FFDVB1 oder FFDVB2 schon reichen.


    Obwohl, wenn ich ehrlich bin - als Nutzer von LinVDR würde mir eine Auswahlmöglichkeit über das OSD am besten gefallen. Da ich aber weiß daß Du davon nichts hälst, bin ich auch mit jeder anderen Auswahlmöglichkeit zufrieden.


    Gruß,


    Thilo

  • Quote

    Originally posted by plautze
    Hallo
    Wollte mal nachfragen ob die Benutzung einer PVR 250 bzw 350 oder einer DXR3 für das Atmo Plugin geplant bzw. möglich ist?
    Grüße Wolle


    Sobald das graben des Screens generel geht, sollte das auch mit einer Dxr3 kein Problem sein... werde mir bei der nächsten Sammelbestellung auch was mitbestellen.

  • Quote

    Original von Austrian Coder


    Sobald das graben des Screens generel geht, sollte das auch mit einer Dxr3 kein Problem sein... werde mir bei der nächsten Sammelbestellung auch was mitbestellen.


    An das dekodierte Bild kommt man bei der dxr3 nicht ran, das ist hardwareseitig nicht möglich...

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...