[atmocontroller] Betrieb unter Windows

    Hm, das evtl. Hardwaresupport aussetzt scheint eine recht logische Erklärung zu sein. Allerdings sollte dann nach Beenden vom WMP auch der "Software"-Modus beendet werden, und zurück auf Hardware geschaltet werden, oder nicht? Aber das ist ja wohl nicht der Fall: man muss das Bitmap Target neu initzialisieren, ansonsten bleibt die hohe Last bestehen.


    Die hohe Last ist ja auch da, wenn man zuerst den WMP aufmacht, und dann AtmoWinA. Es wird also das Handling von sowohl bereits geöffneten, als auch von neuen Bitmaps beeinflusst.


    Mir scheint es eher ein Prioritätsproblem zu sein. Hier kann man lesen:

    Zitat


    My guess is that the hogging video, being the first video being played, gets priority to the hardware. Subsequent videos played have to use software rendering, which enables Windows GDI to capture a copy of the frame being played.


    Sprich: vielleicht sollte man andere Methoden (evtl. DirectX oder Windows Media API dafür nutzen: Beispielcode gibt es hier.


    Dort steht auch, das GDI (BitBlt) keine gute Performance liefert. Über DirectX wird direkt der Grafikartenbuffer ausgelesen (evtl. funtkioniert AtmoWin dann auch mit Overlay?), und die Windows Media API soll wohl sehr effizient sein. Also Igor: viel Spass beim testen... ;)


    Nochwas: der "Bug" tritt nicht mehr so deutlich auf, wenn man die Hardwarebeschleunigung deaktiviert. Steht auch in der o.g. Quelle.

    Zitat

    For example, disabling hardware acceleration (Desktop properties | Settings | Advanced | Troubleshoot) might drastically improve the overall quality and performance of the capture application.

    Matthiaz
    ja - andere Wege suchen - mach ich gerne mit...
    hab mir gerade mal ein wenig von dem Reingezogen


    http://sourceforge.net/projects/taksi


    nicht ganz ohne was die machen um sich einzuklinken... befürchte aber dass was dort gemacht wird unter späteren Windows Versionen vielleicht sogar 64-Bit Windows nicht mehr geht - weil die Leute den Code (Einsprungpunkt) von Funktionen manipulieren - um sich einzuklinken... ganz schön komplex was da läuft...


    Würde ja vorschlagen... ich mach AtmoWin erstmal fertig wohl wissentlich mit dem Bug das wir ein Overlay Problem haben - d.h. Setup Dialog für den Filter etc., Dialog für den "Hardware Weisabgleich".


    Danach können wir uns nochmal dem InputFilter Problem widmen - oder von mir aus auch mehrere Leute gleichzeitig ihre eigene Variante von CAtmoInput implementieren...
    Will mich jetzt nich zu sehr an dem Problem verzetteln....


    es gibt denke ich mal folgende Ansätze:
    [list=1]
    [*]DirectShow-Filter schreiben wo wir das Bild vor der Ausgabe auf den Bildschirm abgreifen
    [*]VideoLan Player Modul / Plugin
    [*]Hack ala Taksi für OpenGL und Direct 3D
    [/list=1]


    Igor

    Hi,


    Zitat


    Zitat:
    Wichtig ist nur, dass der Filter und die Ausgabe getrennt vom
    Calc mit einer festen Frequenz laufen!


    richtig. - allerdings macht es nicht viel Sinn wenn die Ausgabe Frequenz viel höher liegt - als die "Capture Frequenz" und somit das gleiche ColorPaket mehrfach durch die "Mangel" gedreht wird? -- also müsste man versuchen den Takt des OutputThreads irgendwie an den Capture Thread zu binden.... --> z.B. über ein Event? (CreateEvent(...), WaitForSingleObject(...) -- construct - was der Capture Thread auslöst wenn er ein Frame hat -- ?


    Da wage ich zu wiedersprechen :) Die Theorie der digitalen Filter verlangt eine feste Verarbeitungsfrequenz um reproduzierbare Ergebnisse zu erlangen. Im konkreten Fall heisst das, man könne die Frequenz mit der der Bildpuffer abgefragt wird ohne weiteres ändern (zB um CPU zu sparen) und sogar unregelmäßig dem Filter Daten füttern, und dieser muss trotzdem immer gleich schön faden. Wenn er alle 40ms läuft, reicht das locker, dann kannst du auch nur alle 500ms Daten geben, fadet immernoch sauber, logisch. Die Sprungerkennung geht dann natürlich nicht mehr.


    Wenn du den Takt vom Datenerfassen im Bereich um 50ms festlegen kannst und der auch nciht vom Benutzer geändert werden darf, dann kannst du auch alles koppeln.


    Grüße,
    Simon


    Ein Hack sollte nicht die erste Wahl sein; Taksi halte ich nicht für den richtigen Weg.
    Ein Plugin kann man evtl. später nachliefern, ist aber auch nicht wirklich notwendig, wie ich finde. Der momentane Filter funktioniert bei bereits bei allem (bis auf Overlay). Es ist zudem flexibel einsetzbarz.B. bei WinAmp Visualisierung, Spielen, etc. Die CPU-Last ist auch (normalerweise) sehr gering, daher ist eigentlich gar kein Bedarf für ein Plugin.


    Ich denke, dass man einmal den DirectX bzw. Windows API Ansatz testen sollte. Der DirectX Ansatz sollte doch auch eigentlich sehr flott umsetzbar sein, oder nicht?

    Matthiaz
    so hab mir das mal durchgelesen...


    der DirectX weg der dort beschrieben ist geht am Ende nur für DirectX Surfaces (Buffer) die man selbst erzeugt hat - um das DirectX Surface einer anderen Anwendung zu capturen benötigt es wieder einen Hack ala Taksi ;)


    die GDI Variante ist ja wie gehabt... kennen wir schon...


    Bleibt noch die Variante mit dem WM Encoder... die könnte interessant sein - kann aber auch nur wieder nicht Overlays Capturen...


    So nun bin ich wieder an dem Punkt -- bei VideoLan kann man zwar die Ausgabe via OpenGL erzwingen so das unser GDI Capture funktioniert dafür wird dann aber alles mögliche für die Ausgabe in Software gemacht Skalierung etc... -- während das bei der normalen Ausgabe via Overlay in Hardware erledigt wird und somit meine CPU im HTPC schön kühl bleibt... für den Fall wäre dann dei Variante Plugin (Module/ DSFilter) wieder besser - da man die Ausgabe weiterhin auf dem schnellsten und CPU schonensten Weg belassen könnte - nicht auf gut Glück Bilder capturen müssen - sondern genau die Frames bekommt die ausgegeben werden...


    Mein Hintergedanke ist folgender:
    * es gibt weiterhin die AtmoWin.exe im TrayIcon
    die wenn kein Player läuft via GDI Capture für Unterhaltung sorgen...
    hat aber eine Remote API (RPC) die es anderer Software erlaubt entweder:
    a) - die AtmoWinX.exe temporär komplett abzuschalten (effekt = keiner, verbindung zur seriellen Schnittstelle schliessen)


    b) es erlaubt das vorberechnete Bild (64x48 ) als RGB oder HSV... an die Exe zu senden... wo es dann weiter verarbeitet wird ... im Prinzip als Alternativer Input für die Klasse CAtmoLive View ...


    - dann gibt es z.B. für VideoLan ein passendes Plugin


    was wenn wir uns für obige Variante a) entscheiden
    -- beim Start kriegt AtmoWinX.exe den "Switch Off" Befehl
    -- das Plugin übernimmt die Serielle Schnittstelle (ich denk mal hierfür kann man einfach den Source aus AtmoWinA.exe nehmen - einschliesslich der Klassen für den Zugriff auf die Konfiguration....)
    -- beim Ende kriegt AtmoWinX.exe den "Switch On" Befehl und übernimmt die Hardwaresteuerung wieder...


    was wenn wir uns für obige Variante b) entscheiden
    -- wird vom Plugin an AtmoWin der Befehl geschickt - im LiveView Thread den AtmoInput durch einen zu ersetzen der via Name Pipe? oder ähnlicher Konstruktion - fertige Pixeldaten zugereicht bekommt ...
    -- am ende wenn das Plugin entladen (oder der Player) beendet wird - schaltet ein weiter Aufruf AtmoWin wieder in den GDI Modus...


    ist nicht gerade einfach aber denk mal ein gangbarer Weg... für bestmögliche Ergebnisse... Hätte sogar den Vorteil das ein Video was im Fenster auf dem Desktop läuft ein korrektes AtmoWin Ergebnis hätte..:-)


    ich würde Variante b) bevorzugen - da man nicht soviel Code in andere Umgebungen kopieren / compilieren müsste - so das auch Brücken zwischen verschiedenen Programmiersprachen schlagbar wären... und auch die Arbeitsteilung wäre besser - da ich bedenken hätte direkt in einem DirectShowFilter oder VLC Modul - die komplette Atmo Berechnung durchzuführen...
    Ausserdem lädt diese Schnittstelle auch wieder andere ein - z.B. wie wärs mit einem Plugin für Winamp ... was hübsche Farben passend zur Musik rendert? ... ohne das ein Grafik Plugin laufen muss?


    samc

    Zitat

    Da wage ich zu wiedersprechen :) Die Theorie der digitalen Filter verlangt eine feste Verarbeitungsfrequenz um reproduzierbare Ergebnisse zu erlangen. Im konkreten Fall heisst das, man könne die Frequenz mit der der Bildpuffer abgefragt wird ohne weiteres ändern (zB um CPU zu sparen) und sogar unregelmäßig dem Filter Daten füttern, und dieser muss trotzdem immer gleich schön faden. Wenn er alle 40ms läuft, reicht das locker, dann kannst du auch nur alle 500ms Daten geben, fadet immernoch sauber, logisch. Die Sprungerkennung geht dann natürlich nicht mehr.


    Ok - da geb ich dir recht - also würde ich es auch gerne in zwei Threads belassen ... -> damit ich vielleicht obige Idee (b) realisieren kann -



    Igor

    Zitat

    Original von Igor
    Matthiaz
    so hab mir das mal durchgelesen...


    der DirectX weg der dort beschrieben ist geht am Ende nur für DirectX Surfaces (Buffer) die man selbst erzeugt hat - um das DirectX Surface einer anderen Anwendung zu capturen benötigt es wieder einen Hack ala Taksi ;)


    Vielleicht verstehe ich das vorgehen da falsch, aber wird nicht mit dem Befehl "GetFrontBufferData()" der Front Buffer ausgelesen:

    Zitat

    By accessing the front buffer from our DirectX application, we can capture the contents of the screen at that moment.


    Also nichts mit Hack...


    Variante b) von Dir hört sich nach einer sehr guten Idee an, aber auch nach einiger Programmierarbeit...


    Es ist jetzt wohl auch am sinnvollsten, wenn Du erstmal diesen Schönheitsfehler übersiehst, und die GUI usw. fertig machst. Dann kann man evtl. parallel an Lösungsansätzen arbeiten.

    Matthiaz


    ja im Text liesst sich das mit DirectX ganz gut - aber unten hat dann jemand kongreter nachgefragt und diese Antwort erhalten:


    oder? lies ma selbst


    oder auch hier


    Außerdem soll die DirectX Methode auch nicht gerade schnell sein -


    Zitat

    However, a point worth noting when using this technique for screen capture is the caution mentioned in the documentation: The GetFrontBufferData() is a slow operation by design, and should not be considered for use in performance-critical applications. Thus, the GDI approach is preferable over the DirectX approach in such cases.


    Zitat

    Variante b) von Dir hört sich nach einer sehr guten Idee an, aber auch nach einiger Programmierarbeit..


    ist nur ne Frage des Blickpunktes ;) für mich werd ich das auf jeden Fall mal probieren ... sollte ichs für gut genug halt um dort einige Prozentpunkte an CPU Last zu sparen - werd ich das schon weiter verfolgen... und Schnittstellen kann man nie genug haben... davon lebt Software schliesslich :)


    Zitat

    Es ist jetzt wohl auch am sinnvollsten, wenn Du erstmal diesen Schönheitsfehler übersiehst, und die GUI usw. fertig machst. Dann kann man evtl. parallel an Lösungsansätzen arbeiten.


    Ja - werd ich auch machen - hab noch ne kleine Idee wie ich das GDI ein wenig schneller bekomme ... wenn ich die GDI GetPixel Methode verwende - kann ich ja in der Mitte der 64x48 Pixel Grafik - einige Pixel einfach weglassen und mit schwarz füllen ... da diese sowieso nur mit geringer Priorität ins Endergebnis eingehen - und so an die 1000 GetPixel Aufruf einsparen... ohne das Ergebnis extrem zu verfälschen... wieder ein define mehr zum probieren.
    Es wird auch bei zwei Threads bleiben einer der die Screenshots macht, und einer der daraus die Ausgabe berechnet... so dass wir uns erstmal nix verbauen...


    Dann mach ich erstmal noch die Sache mit den Multimonitor Support wieder gangbar, außerdem will ich noch einen Parameter Overscan einführen - oder Border (je nachdem wie man es bezeichnen will) -- damit ein bestimmter Rand um das Ausgabebild nicht mit ins Atmowin eingerechnet wird --> speziell für Anwender die TV Out benutzen und so einen Teil des Bildes an den Overscan des TV verlieren...


    und natürlich alle Parameter der Filter etc. so wie bei Atmo von VDR auch...


    und zuletzt noch die Konfiguration des Hardweissabgleichs - für die neue Firmware des Atmo Controllers... naja sind ja nur ein paar Schieberegler und nicht viel mehr dazu.... dürfte ja leicht sein...


    und den Weisabgleich in die Spassfunktionen einbauen


    ...dürfte für diese Woche eigentlich reichen mit Arbeit??



    Igor

    Zitat

    Original von Igor
    ...dürfte für diese Woche eigentlich reichen mit Arbeit??
    Igor


    Jap, dürfte es. ;)


    Zum DirectX: der Beispielcode erstellt ein Video mit extremer Last (~100%). Wie es aussieht, wenn man nur in den Speicher liest habe ich nicht ausprobiert. Das Zitat:

    Zitat

    How to capture non-topmost directx window?
    In other words, we cannot capture other process's directx surfaces (which are not being display on the screen at present). The surfaces can be captured only from within the application (if we have the Direct3D device handle, that is).


    bezieht sich darauf, VERBORGENE Fenster zu samplen. Sprich: Vollbild Fernsehen, willst aber nur den Desktop haben -> das geht nicht. Aber einen Screenshot vom Bildschirm zu machen, so wie der Benutzer ihn sieht geht ohne Hacks oder sonstiges. Ist halt nur die Frage, wie die Performance ist. Beim GDI haben Sie ja auch geschrieben, dass es nicht das Performancewunder ist... ;)

    Matthiaz


    Zitat

    The surfaces can be captured only from within the application (if we have the Direct3D device handle, that is).


    und wie bekomme ich diese Direct3D device handle? - wenn es zu einem anderem Prozess gehört? -- ich steh heut irgendwie daneben...


    Also mein Vorschlag ... Hilferuf.... probier doch mal jemand ne Routine zu schreiben die mittels direct draw nen Screenshot zieht - und das ca. 20-25mal je Sekunde ohne die CPU übermäßig dabei auszulasten.


    Was auch noch ein interessantes Feld sein könnte? GDI+ vielleicht gibts da noch Methode die Schneller sind? oder weniger von Overlays etc. beeinflusst werden? ....



    Igor

    Hi,


    ich habe ehrlich gesagt keine Ahnung von DirectX und GDI-Routinen und will meinen Beitrag auch eher unter die Kategorie "Brainstorming zum Hilferuf" verstanden wissen. Zwei Ideen kommen mir in den Sinn:


    [list=1]
    [*]Kann man die Skalierung auf 64*48 Pixel nicht durch die GraKa direkt machen lassen, in dem man ein den aktuellen Bildschriminhalt auf einen zweiten (virtuellen) Monitor mit 64x48-Auflösung klont und diesen zur Berechnung der Atmo-Farbwerte heranzieht.


    [*]Eventuell wäre es bei der Video-Geschichte sinnvoll, die Pixel-Daten direkt vom (ffdshow-)Decoder zu verwenden, in dem man per avisynth irgendwelche Auswertungen an AtmoWin schickt? Ist es denn möglich, avisynth-Ergebnisse an externe Programme zu übergeben?
    [/list=1]


    Beste Grüße
    DefCon_Drei

    DefCon_Drei


    Ich auch nicht :) ;D


    Zitat

    Kann man die Skalierung auf 64*48 Pixel nicht durch die GraKa direkt machen lassen, in dem man ein den aktuellen Bildschriminhalt auf einen zweiten (virtuellen) Monitor mit 64x48-Auflösung klont und diesen zur Berechnung der Atmo-Farbwerte heranzieht.


    klingt gut... nur wie macht man das ... wie klont man sich via Programmcode nen Monitor? - ohne gleich nen Grafiktreiber zu schreiben...



    Zitat

    Eventuell wäre es bei der Video-Geschichte sinnvoll, die Pixel-Daten direkt vom (ffdshow-)Decoder zu verwenden, in dem man per avisynth irgendwelche Auswertungen an AtmoWin schickt? Ist es denn möglich, avisynth-Ergebnisse an externe Programme zu übergeben?


    naja - ob das mit avisynth geht weiss ich nicht -- aber das war eigentlich der Ansatz wo ich mehr Chancen sehe - unter Windows verwenden viele Abspielprogramm die Schnittstellen rund um DirectShow - die Verarbeitungskette vom lesen der Videodatei, Dekodierung, Ausgabe - kann man durch sogenannte DirectShowFilter erweitern - sowas hätte ich versucht zu bauen... um die Frames direkt nach der Dekodierung vor dem Scaler und der Ausgabe abzugreifen...


    Für den beliebten Videolanplayer - gibt es auch eigene Schnittstelle (sogenannte Module) die gleiches bewirken könnten.


    Allerdings bleiben dann immer noch viele Programm aussen vor... z.B Spiele ... und bestimmt auch so manche DVD Playersoftware? (befürchte ich)


    ---- so ich bin jetzt furchtbar müde :gaehn :gaehn :gaehn
    hab aber noch ein paar Fragen an die Profis - da ich jetzt den Einstellungsdialog für die Filter und die Ausgabe baue -- soll dieser ja den Benutzer auch soweit möglich davon abhalten totalen Müll einzustellen - da ich mir aber der Funktionsweise er Filterung etc. noch nicht ganz sicher bin - wüsste ich gerne was für die einzelnen Werte für Min Max Werte sinnvolle Grenzen darstellen?




    so das letzte Build für heute in meinem Debug Ordner - Auswahl des Monitors sollte gehen - wer hat mehr als einen und kann es mal probieren?


    die Einstellung Widescreen sollte funktionieren - d.h. schwarze Balken oben und unten ausblenden...


    auch der Filtermode sollte sich ändern lassen...


    [EDIT]
    Thema CPU Last -- habe gerade noch was merkwürdiges festgestellt - hab mich gewundert warum meine AtmoWinA.exe 5% Last produziert hatte... ...seltsam es lag am Triallian? Instant Messanger? ... langsam zweifle ich... als ich den beendet hatte gings sofort wieder flott weiter... mit 0% CPU Last durch AtmoWin ??
    [/EDIT]


    [EDIT 2]
    Fehler? - mir ist gerade aufgefallen das beim Testfilm abspielen die Farben auf den falschen Kanälen herauskommen - d.h. wenn das Video unten rot ist kommt rot oben raus? --- mmh kann man das Screencopy so verblödet programmieren das die kopierte Bitmap verkehrt herum rauskommt? und dauert deswegen der Zugriff darauf so lange???
    [/EDIT2]


    Igor

    Hi,


    min und max-Werte sind in menu.c vorgegeben:

    Zitat


    Add(new cMenuEditIntItem(tr(" Edge weighting"), &AtmoSetup.EdgeWeighting, 1, 30));
    Add(new cMenuEditIntItem(tr(" Brightness [%]"), &AtmoSetup.BrightCorrect, 50, 300));
    Add(new cMenuEditIntItem(tr(" Darkness limit"), &AtmoSetup.DarknessLimit, 0, 10));
    Add(new cMenuEditIntItem(tr(" Hue windowing"), &AtmoSetup.HueWinSize, 0, 5));


    Die beiden Zahlen am Ende der Aufrufe geben min- und max-Werte an!


    Die Voreinstellung kannst du dir so aussuchen, wies dir gefällt. Hab mal versucht zu fragen, welche Werte die User einstellen, kam aber irgendwie nix dabei raus...


    Ich habe die unteren drei Werte aus deinem Zitat höher eingestellt...


    Grüße.
    Simon

    samc
    Danke...
    kannst ja mal deine Werte posten... vielleicht nehm ich sie da gleich mal als default... *g*


    Ok...in die Menus.c hatte ich noch nicht geguckt ... ups...erwischt...*g* da stehe ja für alle Werte die Grenzen... damit kann ich ja morgen dann weitermachen....



    Igor

    Der Wichtel
    aja - hab meinen Code gerade nochmal gepatcht - kann es sein das es bei Windows zwei Arten von Bitmaps git? welche wo Zeile 0 unten ist und welche wo Zeile 0 oben ist? ...


    das mit dem 2. Moni bzw. TV ist auch ne Idee ob das korrekt erkannt wird - die Möglichkeit hab ich nicht... zum Testen... hab den Code erstmal im grossen und ganzen aus dem alten AtmoWin übernommen... und hoffe drauf das er richtig ist.


    Danke für deinen Zwischentest...


    und gute Nacht...


    Igor

    Zitat

    Original von Igor
    das mit dem 2. Moni bzw. TV ist auch ne Idee ob das korrekt erkannt wird - die Möglichkeit hab ich nicht... zum Testen... hab den Code erstmal im grossen und ganzen aus dem alten AtmoWin übernommen... und hoffe drauf das er richtig ist.


    Multimonitor wird korrekt erkannt. Ob die Ausgabe stimmt, kann ich nachher mal prüfen.

    Matthiaz
    gut zu wissen - das ich den Code beim "umkopieren" nicht kaputt bekommen habe...


    Ich hab mich noch ein wenig mit dem Problem Screencapture befasst und bin dabei über diese Arbeit gestolpert - dort wird das Windows GDI Treiber zusammenspiel für den Bau eines Fernsteuerungssystems (Terminal Server)- inkl Treibers für ein Mirrordevice beschrieben... klingt eigentlich ganz eingängig.....


    Igor

    @BetaBeta Testers...*g*


    es gibt neues Futter... der Setupdialog - kann jetzt auch die restlichen Parameter der Filter einstellen ... der Button [anwenden & testen] für LiveView - ist nur noch erforderlich wenn derzeit nicht er Ausgabemodus [Live ...] aktiv ist - wenn dieser aktiv ist - wirken die Parameteränderungen nahezu sofort.


    Beim Wechsel des Quellbildschirms kann es aber zu einem mehr oder weniger heftigen flackern der LED's kommen... da ich dafür den Effekt Thread neu starten muss...


    Auch das wechseln der Bildschirmauflösung bei aktiver Livewiedergabe sollte funktionieren.



    Igor

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden