[ANNOUNCE] Atmolight - Release 0.0.2

  • Hallo,


    endlich ist es wieder soweit, es gibt eine neue Version des
    Atmolight-Plugins.


    Hier downzuloaden: atmo-0.0.2.tgz


    Änderungsauflistung befindet sich in der History-Datei.


    Bei Fragen, Anregungen, etc. bitte hier posten.


    Schönes Wochenende und viel Spaß beim Testen
    Samael


    EDIT: Diesen Thread bitte NUR zur Diskussion der Software verwenden.
    Es soll hier nicht um irgendwelche Sets gehen. Das wird schon hier besprochen.

    Für Heilige gibts 'nen Heiligenschein - für Fernseher das Solarstorm.

    The post was edited 1 time, last by Samael ().

  • Moin,


    hat sich eigentlich auch schon jemand gefunden, der fertige Atmolight-Sets anbietet? Glaube nicht, dass ich mit meiner Grobmotorik ein ordentliches Ergebnis bekommen würde...


    Robsta


    Hardware: Antec Fusion Remote Black, Asus P5N7A-VM, E5200, Mystique SaTiX-S2 Dual V2, Stereo-Atmo
    TV: Samsung UE32B6000, BenQ W1070
    Software: yaVDR


  • Hallo Samael,


    na wunderbar!


    Habs schon installier und ausprobiert...funktioniert alles wunderbar, auch das Speichern der Einstellung beim restart klappt jetzt, super.
    Ein paar kleine Kritikpunkte hab ich freilich schon (hab ich glaub sogar selber verbockt...)


    Einige Default-Werte sollten in meinen Augen anders gesetzt sein:


    setup.c:


    GammaMode = 1; // gamma Mode 0=uniform 1=channel specific


    sollte sein:


    GammaMode = 0; // gamma Mode 0=off 1=uniform 2=channel specific


    da im Moment wohl jeder mit der passenden Ansteuerplatine arbeiten wird und die hat die Gammakorrektur ja fest eingebaut. So wird das Gamma nochmal mit 2.0 korrigiert und dann kommt fast nix mehr raus.


    DarkLimit = 1;
    Das DarkLimit sollte wohl auch nicht auf 0 stehen sonst ist es ja abgeschaltet und das wär schade :-)


    Die Korrekturen kann aber ja auch jeder User selber im OSD einstellen.


    Sonst ist alles wunderbar und schön aufgeräumt! :-)


    Ach ja, für diejenigen, die schon mit den Entwicklerversionen gearbeitet haben schreib ichs nochmal deutlich:
    Der Name hat sich offenbar von atmolight in atmo geändert. Deshalb sollte die .ko entsprechend heißen und die Konfigurationsdatei plugin.atmo.conf.


    Grüße,
    Simon

  • Hi,


    hier eine neue Version des Patch um die Ausgaberoutinen in seperate Module umzuordnen und um die Koppelung per über Socket an das "Atmo over USB" erweitern.
    Falls die Kommunikation gestört sein sollte, wird automatisch in den Modus "Atmo - OFF" gewechselt, um unnötigen Kommunikation, CPU Last bzw. der Stromverbrauch reduziert wird...





    Was mir aber beim Plugin negativ auffällt, ist die erzeugte enorme CPU Last .
    Die hier im Mittel bei 50% bis 60% liegt.


    Was mir unverständlich warum alle 20ms ein Screenshot gemacht werden muss.
    Bei PAL mit 25fps kommt nur alle 40ms ein Frame, und ich bilde mir ein das der AV7110 nur I-Frames als Screenshot abspeichern kann, welches nur alle 0,5 Sekunden verfügbar sind.


    Was auch auffällt, das die CPU Last bei "Atmo - OFF" hier auch bei 50% bleibt, weil der Filterthread weiterläuft.


    Falls gewünscht kann ich auch dazu einen Patch anbieten !?
    Andreas

  • Hallo,


    Quote


    Was mir aber beim Plugin negativ auffällt, ist die erzeugte enorme CPU Last .
    Die hier im Mittel bei 50% bis 60% liegt.


    Auf welchem System denn??


    Quote


    Was mir unverständlich warum alle 20ms ein Screenshot gemacht werden muss.
    Bei PAL mit 25fps kommt nur alle 40ms ein Frame, und ich bilde mir ein das der AV7110 nur I-Frames als Screenshot abspeichern kann, welches nur alle 0,5 Sekunden verfügbar sind.


    Korrekt, tatsächlich wird die Berechnung bei jedem Vollbild durchgeführt (alle 40ms durhgeführt, der sleep(20ms) wird nur aktiv, wenn /dev/video0 nicht geöffnet werden kann.


    Der Filter läuft alle 20ms, damit die Überblendungen sanft werden.


    Quote


    Was auch auffällt, das die CPU Last bei "Atmo - OFF" hier auch bei 50% bleibt, weil der Filterthread weiterläuft.


    Die Berechnung läuft weiter, korrekt. Wenn man mal jemand was machen möchte, dann wäre es in meinen Augen sinnvoller die Berechnung mathematisch zu optimieren.


    Grüße,
    Simon

  • Quote

    Original von samc
    Auf welchem System denn??


    Ich denke ein VIA EPIA 10000 mit 1GHz, ist nicht total schwachbrüstig.
    Den die normale Last des VDR liegt bei 9%.


    Quote

    Original von samc
    Die Berechnung läuft weiter, korrekt. Wenn man mal jemand was machen möchte, dann wäre es in meinen Augen sinnvoller die Berechnung mathematisch zu optimieren.


    Ich denke sowohl als auch, meiner Meinung nach sollte bei "OFF" keine Screenshot geholt werden, und der Filter muss dann auch nicht ausgeführt werden.
    Weitere Optimierungen sind aber immer gut. :]



    Folgender einfacher Patch mit der Vergrößerung der Pause von 20ms auf 100ms reduziert die Last auf 19%, optisch kann ich keinen Unterschied erkennen.


    Und bei "OFF" sinken die Last auf die bisherigen Werten, ohne Plugin.


  • Hallo,


    ich habs hier auf einem geode nx laufen, bei 800MhZ hat der 10% Last.


    Quote


    Folgender einfacher Patch mit der Vergrößerung der Pause von 20ms auf 100ms reduziert die Last auf 19%, optisch kann ich keinen Unterschied erkennen.


    Dein Patch ändert ja nur die Frequenz des Filters, nicht die der Berechnung, da diese fest nach jedem Vollbild ausgeführt wird.


    Dein Problem liegt also offenbar NICHT in der Berechnung an sich sonder wohl am Verschicken der Datenpakete an sich!
    Die hohe CPU Last hat dann aber nichts mit der 0.0.2 Version zu tun sonder kommt erst von deinem Communications Patch...da verbrauchst du wohl irgendwo Rechenlast, schau doch mal :-)


    EDIT:
    muss mich korrigieren, lass es doch mal ohne diesen Teil laufen:


    Grüße,
    Simon

  • Auf deinen Hinweis habe ich nochmal Last gegengeprüft.


    So die aktuelle Aufnahme ist beendet, und einen rebuild stand somit nichts mehr im weg.


    Die Last der Kommunikation ist geprüft, und die kann ich guten Gewissens als Ursache ausschliessen.


    Das Testen der verschieden Kombinationen hat als Ursache das Capturen und die Verarbeiten des Screenshot ausgemacht.


    Im Originalzustand sind es 47%,
    ohne CalcColors, PutColorPacket sinkt die Last auf 3% (vorhin bei 9% lief ein Timer)
    Wenn ich den Capture-Thread auf 100ms reduziere sinkt die Last auf erträgliche 10%





    Als Fazit würde ich folgende Änderungen für sinnvoll halten.


    1.) der Intervall des Capturen-Thread sollte einstellbar sein.
    2a.) Außerhalb des Livemode sollte kein Screenshot geholt werden
    2b.) das /dev/video sollte bei Inaktivität freigegeben werden, damit vdradmin, xxv bzw. das Screenshot-Plugin wieder nutzbar sind.




    PS : Um beim Kommunikationstest keiner Selbsttauschung zu erliegt, hatte ich auch die Sendewiederholsperre auskommentiert (0 != memcmp(last_colors,colors,sizeof(last_colors)))

  • Guten Abend,


    Quote

    Habs schon installier und ausprobiert...funktioniert alles wunderbar, auch das Speichern der Einstellung beim restart klappt jetzt, super.


    Freut mich zu hören.


    Quote

    Einige Default-Werte sollten in meinen Augen anders gesetzt sein:


    Werde ich übernehmen. Ich mach also gleich für mich eine 0.0.3-pre1 auf ;D.


    Quote

    Der Name hat sich offenbar von atmolight in atmo geändert.


    Eigentlich wollte ich das schon atmolight nennen, aber aus Schreibfaulheit habe ich in der 0.0.1 bei internen Bezeichnern nur atmo geschrieben und irgendwo in den Zwischenversionen hat auch jemand die atmolight.c/.h in atmo.c/.h umbenannt. Da sollten wir uns mal die Karten legen, ob nun atmolight oder nur atmo.


    Quote

    hier eine neue Version des Patch um die Ausgaberoutinen in seperate Module umzuordnen und um die Koppelung per über Socket an das "Atmo over USB" erweitern.


    So eine Aufteilung ist für 0.0.3 geplant. Da habe ich vor Bildquelle, Berechnung und Ausgabe zu modularisieren, so daß diese 3 Sachen einfach erweitert werden können.


    Quote

    Falls die Kommunikation gestört sein sollte, wird automatisch in den Modus "Atmo - OFF" gewechselt, um unnötigen Kommunikation, CPU Last bzw. der Stromverbrauch reduziert wird...


    Nein, niemals. Ein kleiner Holpler auf der Leitung und dann alles ausmachen? Vor allem weil das Licht weiter leuchtet, aber im Hauptmenü "Atmolight einschalten" steht? Was soll der einfache Benutzer dann denken? Der wird das Ding als Bug melden!
    Der Vorschlag widerspricht allen Regeln robuster Software.
    Man kann sich höchstens überlegen, nach 100 oder wieviel auch immer fehlgeschlagenen Versuchen eine Meldung auf dem OSD ausgeben.


    Quote

    Was auch auffällt, das die CPU Last bei "Atmo - OFF" hier auch bei 50% bleibt, weil der Filterthread weiterläuft.


    Ja, richtig. Die Filterei und die Ausgabe sind ja eigentlich auch 2 unterschiedliche Sachen. "Atmo - Off" heißt eigentlich nur, daß die Beleuchtung aus ist. Um es korrekt zu halten muß der Filter ständig und regelmäßig mit Werten versorgt werden. Wenn der Filter auch ausgeschaltet wird, dann rechnet der nach dem Einschalten mit Werten von irgendwann weiter. Aber eigentlich fällt das wohl nicht auf. Ich denke da nochmal drüber nach, ob ich das so lasse oder den Filter mit ausmache.


    Quote

    Folgender einfacher Patch mit der Vergrößerung der Pause von 20ms auf 100ms reduziert die Last auf 19%, ...


    In der ursprünglichen Version hatte ich das mal parametrierbar. Vielleicht bau ich das wieder ein.


    Ansonsten habe ich vor, in der 0.0.3 die CCFL-Unterstützung rauszuschmeißen. Wer etwas dagegen hat, soll es hier mitteilen oder für immer schweigen ;).


    Grüße Samael

  • Hallo,


    Quote


    Werde ich übernehmen. Ich mach also gleich für mich eine 0.0.3-pre1 auf zuzwinker .


    Wunderbar ! Aus meinem Kopf gestrichen! :-)


    Quote


    Eigentlich wollte ich das schon atmolight nennen, aber aus Schreibfaulheit habe ich in der 0.0.1 bei internen Bezeichnern nur atmo geschrieben und irgendwo in den Zwischenversionen hat auch jemand die atmolight.c/.h in atmo.c/.h umbenannt. Da sollten wir uns mal die Karten legen, ob nun atmolight oder nur atmo.


    Also ich hätte grundsätzlich "atmolight" sinnvoller empfunden, da man ja doch immer wieder das "light" als Begriff mitbenutzt. Aber wenns das nächste mal wieder anders heißt dann kennt sich wohl keiner mehr aus...also warum nicht einfach so lassen wies ist und ruhig von "atmolight" sprechen, "atmo" quasi als Abkürzung nutzen?


    Quote


    Nein, niemals. Ein kleiner Holpler auf der Leitung und dann alles ausmachen? Vor allem weil das Licht weiter leuchtet, aber im Hauptmenü "Atmolight einschalten" steht? Was soll der einfache Benutzer dann denken? Der wird das Ding als Bug melden!
    Der Vorschlag widerspricht allen Regeln robuster Software.
    Man kann sich höchstens überlegen, nach 100 oder wieviel auch immer fehlgeschlagenen Versuchen eine Meldung auf dem OSD ausgeben.


    Hmm, ja kann man schon machen, aber kann mir jemand erklären, wozu das gut sein soll ?!
    Abgesehen davon ist die Kommunikation zur Ansteuerplatine unidirektional, der Rechner bekommt gar nicht mit ob die angeschlossen ist.
    Ich zB hab vor das atmolight an die Stromversorgung meines 40" zu koppeln. Würd mich eher nerven, jedesmal nach dem Einschalten des Displays neu auf "Atmolight eischalten" gehen zu müssen...


    Quote


    Ja, richtig. Die Filterei und die Ausgabe sind ja eigentlich auch 2 unterschiedliche Sachen. "Atmo - Off" heißt eigentlich nur, daß die Beleuchtung aus ist. Um es korrekt zu halten muß der Filter ständig und regelmäßig mit Werten versorgt werden. Wenn der Filter auch ausgeschaltet wird, dann rechnet der nach dem Einschalten mit Werten von irgendwann weiter. Aber eigentlich fällt das wohl nicht auf. Ich denke da nochmal drüber nach, ob ich das so lasse oder den Filter mit ausmache.


    Den Filter anzuhalten sollte gar nie notwendig sein, der darf fast keine CPU Last erzeugen.
    Um CPU-Last zu sparen müss alleine das "CalcColors" ausgesetzt werden.
    Wird die Ausgabe wieder eingeschaltet muss lediglich der Filter mit dem ersten berechneten Wert neu initialisert werden, genauso wie bei einem "jump". Kann man bestimmt ganz ganz einfach lösen.


    Die Idee das /dev/video0 freizugeben finde ich interessant, müsste sich auch machen lassen, oder?


    Um im Betrieb Rechenzeit zu sparen wäre es mein ich am sinnvolsten nich eine Zeit in ms zu warten zwischen den Berechnungen sondern jedes 2., 3., 4. usw. Vollbild zu verwenden. So kann keine Inteferenz zwischen der Bildfrequenz und der Berechnungsfreq. entstehen.
    Solange der Filter alle 20ms läuft verliert man so nur ein bischen Reaktionsgeschwindigkeit.


    Wie ich aber schon gesagt habe wäre is sicher sinnvoller, das Problem erstmal von einer anderen Seite anzupacken:
    auf einem C3 1GHz 60%, auf einem Geode(Athlon) 800MHz 10%
    -> daraus folgere ich einfach mal, es liegt daran, dass die Berechnung im Moment mit (double) !! durchgeführt wird.
    Das ist auf jeden Fall unnötig. Bin da kein Fachmann, aber denke man kann die Berechnung auch mit int/long int durchführen. Mein Vorschlag: die ursprüngliche Genauigkeit der Bilddaten von 0..255 auf 0..1024 oder 0..512 aufblasen. Zum Speichern der Werte jeweils int verwenden, die Variablen in denen addiert wird dann eben mit long int, damit sie nicht überlaufen (histo build).
    Das sollte doch was bringen oder?


    Grüße,
    Simon

  • Hallo,


    Quote

    also warum nicht einfach so lassen wies ist und ruhig von "atmolight" sprechen, "atmo" quasi als Abkürzung nutzen?


    Klingt gut, machen wir so.


    Quote

    Abgesehen davon ist die Kommunikation zur Ansteuerplatine unidirektional,


    Das kommt auch noch dazu. Es gibt aber einige Übertragungsverfahren,
    da bekommt man Fehler auf dem Bus etc. mit (z.B. CAN).


    Quote

    Die Idee das /dev/video0 freizugeben finde ich interessant, müsste sich auch machen lassen, oder?


    Ich denk schon, werde ich mir mal ansehen.


    Quote

    aber denke man kann die Berechnung auch mit int/long int durchführen


    Das sollte garantiert machbar sein. Guck ich auch mal.


    Ansonsten könnte man mal überlegen, statt /dev/video0 sich das Bild wie im
    "Picture in Picture"-Plugin über ffmpeg zu besorgen. Kostet zwar
    Rechenleistung (keine Ahnung wie viel, weiß jemand genaueres?), ist aber, denke ich, machbar.


    Grüße Samael

  • Quote

    Ansonsten könnte man mal überlegen, statt /dev/video0 sich das Bild wie im
    "Picture in Picture"-Plugin über ffmpeg zu besorgen. Kostet zwar
    Rechenleistung (keine Ahnung wie viel, weiß jemand genaueres?), ist aber, denke ich, machbar.


    Würde es dann vielleicht auch mit ner dxr3 funktionieren? *Hoff*


    :o)


    ThoBu

  • Quote

    Würde es dann vielleicht auch mit ner dxr3 funktionieren? *Hoff*


    Denke schon, zumindest ist das der Plan. Aber ich glaube das erst, wenn
    wir das eingebaut haben und mir das jemand glaubhaft bestätigt hat.


    Samael

  • Hi Samael,


    evtl. solltest Du auch das Thema "Plugin Kommandozeilen Parameter" bei der 0.0.3 beruecksichtigen. Es wird sicherlich auch LinVDR User unter den Atmolight Freunden geben, die sonst immer Workarounds einbauen muessen.


    Siehe auch Parameter an Plugin übergeben


    Gruss
    Eberhard

    VDR1: Humax iCord HD :evil:


    VDR2: easyVDR 0.6 / Silverstone LC20 / AMD Geode NX 1750 PC-Chips M811 / TT Prem 2300 mod + CI / Nova-S SE / PSOne TFT / ATRIC IR


    VDR3: Mahlzeit 3.3pre4 / Activy300 / DVB-S FSC 1.3 + CI

  • Hallo Eberhard,


    Quote

    evtl. solltest Du auch das Thema "Plugin Kommandozeilen Parameter" bei der 0.0.3 beruecksichtigen.


    das muß ich mir wirklich mehrmals überlegen, ob ich das mitmache.
    Meiner Meinung nach gehören Verzeichnis-, Device-, etc.-Angaben nämlich schon in die Kommandozeile. Wenn man das Plugin dort einträgt, ist es ein einfaches dort auch einen Parameter zu übergeben.
    Stell Dir mal vor, jemand hat den VDR für sich und seine Familie (Vater, Mutter, 3 Kinder, Oma und 4 Katzen) "perfekt" eingerichtet, alle Verzeichnisse im OSD mit den Tasten "rauf" und "runter" stundenlang eingerichtet und nun verläuft sich der Rest der Familie in der Menüstruktur des VDR und ändert zufällig ungewollt an den Verzeichnissangaben rum. Nicht nur das dann evtl. ein Plugin irgendwelche Daten nicht findet, es evtl. wild auf der Platte in Verzeichnisse schreibt, die wirklich für was anderes gedacht sind, nein, es kann sogar passieren, daß das Plugin dann nicht starten will und der VDR sich beendet. Und die nächste Aufnahme ist im A****.
    Ich gebe Dir schließlich auch nicht mein Root-Passwort, damit Du irgendwelche Einstellungen bei mir (vielleicht sogar ungewollt) ändern kannst.


    Und nur, weil irgendwelche Leute, die eine Distribution rausbringen, so eine Meinung vertreten (KLS vertritt da bestimmt eine andere, sonst hätte er die Möglichkeit nicht eingebaut), werde ich meine bestimmt nicht ändern.


    Man kann gerne versuchen, mich eines Besseren zu belehren
    Samael

  • Hallo Samael,


    eieiei, einen "Glaubenskrieg" wollte ich nun nicht vom Zaun brechen. Da kann man geteilter Meinung sein - ist nur 'ne Frage des Errorhandlings.


    Beim Atmolight sprechen wir von 3 Parametern (evtl. nur noch von 2, wenn CCFL 'rausfliegt) und die koennte man doch locker mit Defaultwerten belegen. Wenn Commandline Options trotzdem uebergeben werden, dann kann man die Defaults ueberschreiben. Dann waere auch den LinVDRlern schon eine Huerde aus dem Weg geraeumt ;)


    Und im Setup eine IP-Adresse bzw. eine Schnittstelle einstellbar zu machen, halte ich nicht fuer kritsch.


    So, es bleibt Dir ueberlassen, den Vorschlag aufzugreifen. Mir ist's egal :D


    Gruss
    Eberhard

    VDR1: Humax iCord HD :evil:


    VDR2: easyVDR 0.6 / Silverstone LC20 / AMD Geode NX 1750 PC-Chips M811 / TT Prem 2300 mod + CI / Nova-S SE / PSOne TFT / ATRIC IR


    VDR3: Mahlzeit 3.3pre4 / Activy300 / DVB-S FSC 1.3 + CI

  • Hallo Eberhard,


    Quote

    eieiei, einen "Glaubenskrieg" wollte ich nun nicht vom Zaun brechen.


    Kein Problem ;).


    Quote

    Beim Atmolight sprechen wir von 3 Parametern (evtl. nur noch von 2, wenn CCFL 'rausfliegt)


    CCFL ist bei meiner 0.0.3-pre1 (meine aktuelle Spielwiese) schon rausgeflogen; damit sind wir bei aktuell einem Parameter.
    Die Anzahl wird aber, denke ich, noch wieder steigen.


    Quote

    koennte man doch locker mit Defaultwerten belegen.


    Hmm, ich werde die ganze Geschichte mal im Hinterkopf behalten.


    Samael

  • Hallo Samael,


    ich frag dich mal gaaanz vorbildlich in diesem Thread :-)



    hast du das mit dem MPEG dekodieren mal ausprobiert? Habs ja auch nicht lassen können und mal den OSDPIP installiert...da lag ich aber bei 100% CPU und 1 Bild in 3 Sekunden...


    Hast du mal bei softdevice weitergesucht? Da gibts doch ein bufferarray mit dem Bild drin, oder hab ich das falsch verstanden?


    Wie siehst aus mit der "modularen" Version aus? (hab bald mein 40" an der Wand hängen, dann hab ich wohl plötzlich gesteigertes Interesse atmolight mit softdevice zu nutzen...wer weiss vielleicht kann ich mal nicht schlafen und will anfangen zu suchen...)


    Viele Grüße,
    Simon

  • Hallo Simon,


    Quote

    ich frag dich mal gaaanz vorbildlich in diesem Thread :-)


    sehr löblich :tup


    Quote

    hast du das mit dem MPEG dekodieren mal ausprobiert?


    Nein, soweit bin ich mit den Plugin-Schnittstellen noch nicht.
    Und dann muß diese ffmpeg-Geschichte auch noch implementiert werden.


    Quote

    Habs ja auch nicht lassen können und mal den OSDPIP installiert...da lag ich aber bei 100% CPU und 1 Bild in 3 Sekunden...


    Ich habs noch nicht ausprobiert. Welche CPU? Außerdem rechnet das OSDPIP
    ja auch noch die OSD-Ausgabe, auch nochmal CPU-Last.


    Quote

    Hast du mal bei softdevice weitergesucht?


    Habe mir eben den Wiki-Eintrag mal durchgelesen. Die verwenden, wenn ich das richtig verstanden habe, auch ffmpeg. Also ein und die selbe Geschichte.


    Quote

    Wie siehst aus mit der "modularen" Version aus?


    Ich hoffe auf ein Release an diesem Wochenende.


    Viele Grüße Samael