[ANNOUNCE] Atmolight - Release 0.0.2

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

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,

Zitat

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??

Zitat

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.

Zitat

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

Zitat

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%.

Zitat

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.

diff -Nur atmo-0 (Kopie).0.2/thread.c atmo-0.0.2/thread.c
--- atmo-0 (Kopie).0.2/thread.c 2006-09-17 19:33:59.000000000 +0200
+++ atmo-0.0.2/thread.c 2006-09-17 20:09:06.000000000 +0200
@@ -324,22 +324,11 @@
   {
     t.Set(0);


-    switch (AtmoSetup.FilterMode)
-    {
-      case 0:
-           ApplyMeanFilter(); // apply the filter
-      break;
-
-      case 1:
-           ApplyPercentFilter();
-      break;
-    }
-
     OutputColors(); // write filter_output to the device


-    if (t.Elapsed() < 18) // wait 20ms
+    if (t.Elapsed() < 100) // wait 100ms
     {
-      cCondWait::SleepMs(20 - t.Elapsed());
+      cCondWait::SleepMs(100 - t.Elapsed());
     }
   }
 }
@@ -365,6 +354,17 @@


        if (AtmoSetup.atmo_on)
        {
+        switch (AtmoSetup.FilterMode)
+        {
+          case 0:
+                ApplyMeanFilter(); // apply the filter
+          break;
+    
+          case 1:
+                ApplyPercentFilter();
+          break;
+        }
+
                switch (nMode)
                {
                        case live_picture_hsv: // live mode
@@ -547,16 +547,18 @@
   {
     t.Set(0);


-    // read picture and Calculate
-    ColorChannels = CalcColors();
-
-    // send result to filter and output
-    FilterThread->PutColorPacket(ColorChannels);
+    if (AtmoSetup.atmo_on)
+    {
+      // read picture and Calculate
+      ColorChannels = CalcColors();


+      // send result to filter and output
+      FilterThread->PutColorPacket(ColorChannels);
+    }
     //esyslog("%d",t.Elapsed()); // print duration
-    if (t.Elapsed() < 20) // if Atmolight is switched off wait 20ms to avoid 100% CPU usage
+    if (t.Elapsed() < 100) // if Atmolight is switched off wait 20ms to avoid 100% CPU usage
     {
-      cCondWait::SleepMs(20);
+      cCondWait::SleepMs(100 - t.Elapsed());
     }
   }
 }

Hallo,

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

Zitat

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:

Zitat

@@ -547,16 +547,18 @@
{
t.Set(0);

- // read picture and Calculate
- ColorChannels = CalcColors();
-
- // send result to filter and output
- FilterThread->PutColorPacket(ColorChannels);
+ if (AtmoSetup.atmo_on)
+ {
+ // read picture and Calculate
+ ColorChannels = CalcColors();

+ // send result to filter and output
+ FilterThread->PutColorPacket(ColorChannels);
+ }
//esyslog("%d",t.Elapsed()); // print duration
- if (t.Elapsed() < 20) // if Atmolight is switched off wait 20ms to avoid 100% CPU usage
+ if (t.Elapsed() < 100) // if Atmolight is switched off wait 20ms to avoid 100% CPU usage
{
- cCondWait::SleepMs(20);
+ cCondWait::SleepMs(100 - t.Elapsed());
}
}
}

Alles anzeigen

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%

Originalzustand
cAtmoThread: 20ms, cAtmoFilterThread: 20ms (mit CalcColors, PutColorPacket)


 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5994 vdr       16   0  151m  21m 8732 S 46.5  9.0   0:04.96 vdr
 5643 root      17   2  1600  508  376 R  0.3  0.2   0:00.92 auos


cAtmoThread: 20ms, cAtmoFilterThread: 20ms (CalcColors, PutColorPacket auskommentiert)
 5809 vdr       16   0  150m  19m 5252 S  2.7  8.1   0:04.32 vdr
 5643 root      17   2  1600  508  376 D  0.3  0.2   0:00.49 auos


cAtmoThread: 100ms, cAtmoFilterThread: 20ms (mit CalcColors, PutColorPacket)


 6502 vdr       16   0  151m  21m 8732 S 10.3  9.1   0:03.73 vdr
 5643 root      17   2  1600  508  376 R  0.3  0.2   0:01.99 auos

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)))

Hallo,

Zitat

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

Wunderbar ! Aus meinem Kopf gestrichen!

Zitat

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?

Zitat

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...

Zitat

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

Zitat

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

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

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

Gruss
Eberhard

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