[atmocontroller] Betrieb unter Windows

    Hallo @All - ich habe mal wieder eine neue VideoLAN Version kompiliert die ich gerne getestet haben möchte - diese basiert auf VideoLAN 1.1.x die demnächst wohl irgendwan erscheint.


    Folgende Änderungen gibt es:


    - Hardware ist jetzt mit der gleichen Unterstützung wie AtmoWin selbst
    (d.h. DMX, MoMo, Quattro Atmo sind dazu gekommen.)
    - einige Parameter für das Build In Atmo sind jetzt Live änderbar
    (Extras -> Effekte und Filter -> Video Effekte -> AtmoLight)
    (damit kann der Filter sogar bei Bedarf während der Wiedergabe noch aktiviert / deaktiviert werden.)
    (Die Regler funktionieren natürlich nur sinnvoll - wenn das Build In Atmo von VLC aktiv ist.)


    - Zonenlayouts konfigurierbar


    - Channel Assigment konfigurierbar


    - die AtmoCtrlLib.dll muss nicht mehr länger zwingend ins VLC.exe Verzeichnis kopiert werden, wird dem Plugin der Name der AtmoWin.exe mitgeteilt - wird die DLL bei Bedarf aus dem gleichen Ordner geladen (im vlc.exe folder sollte dann möglichst keine dll mehr liegen.)


    http://eldo.gotdns.com/atmowin/vlc-1.1.0-git-win32.exe


    http://eldo.gotdns.com/atmowin/vlc-1.1.0-git-win32.zip



    Igor


    gru
    ok - den patch werde ich dann übernehmen - kann man denke ich so machen - muss ich mir nochmal anschauen... bei Gelegenheit.
    (wäre halt schön wenn man mir solches patches per Mail zuschicken würde und ich erst nicht durch Zufall darüber stolpern würde.)


    gemx
    - hast du noch mehr Änderungen am AtmoWin Code gemacht? - wenn ja bitte die Patches an mich weiterleiten - hab dir ne PM geschickt.

    ed1k
    also das setzen auf Schwarz funktionierte schon länger sobald AtmoWin beendet wurde oder der PC in Standby / Hibernate wechselte - dafür musste man lediglich die Shutdown Color konfiguriert & aktiviert haben - nur das schließen der seriellen Verbindung in diesem Kontext ist etwas neues.
    Was ich auch in meine nächste AtmoWin Version übernehmen werde - weils ja eigentlich ganz logisch und praktisch ist.


    Geht das mit dem Schließen der serielle Verbindung nun auch wirklich - d.h. geht der PC mit der gepatchten AtmoWin.exe sauber in den Standby Betrieb?
    --> für Fragen zu MediaPortal - wendest du Dich vielleicht mal an gemx er hat ein spezielles Plugin für MediaPortal gebaut?


    Igor

    Hallo Igor,


    Zitat

    Original von Igor
    Geht das mit dem Schließen der serielle Verbindung nun auch wirklich - d.h. geht der PC mit der gepatchten AtmoWin.exe sauber in den Standby Betrieb?


    Prinzipiell scheint's zu funktionieren. Hab aber ein komisches Phänomen, wo ich noch nicht weiss, wohin ich es schieben soll:
    - In MP hab ich eingestellt, dass es nach 5 min. (oder auf Knopfdruck) in den Hibernate-Modus gehen soll. (Ist jetzt nur mal zur Info.)
    - Wenn die 5 min. ablaufen bzw. ich auf meiner MCE Poweroff drücke, dann verabschiedet sich mein HTPC (inkl. gepatchter Atmowina.exe) brav in den Hibernate-Modus. :)
    - Wenn ich dann ein wenig später wieder ins Wohzimmer komme, dann läuft der HTPC wieder - was mich wundert, denn ich hatte ihn gar nicht eingeschalten bzw. nix zum Aufnehmen programmiert - und der Bildschirm zeigt, dass er beim "Standby vorbereiten"-Screen hängt! :(
    Ich weiss noch nicht, wo der Standby auf einmal herkommt - also das dauert bei mir noch ein bißchen, dass wirklich zu verifzieren.


    Soweit mal meine Neuigkeiten.
    lg, Jo

    gru
    das ist ja seltsam - ob das wirklich an AtmoWin liegt - wage ich schon fast zu bezweifeln - werde ich mal mit meinem Windows 2000 testen - ob ich da sowas nachvollziehen kann.


    Verwendest du eigentlich Standby "Suspend to Ram" oder "Suspend to disk"?


    Kann es sein das eine andere Komponente in deinem Windows erlaubt wurde das System aufzuwecken? Netzwerkkarte? Fernbedienungsempfänger? oder sowas halt? ggf. auch die Serielle USB Schnittstelle...?


    Igor

    Zitat

    Original von Igor
    Verwendest du eigentlich Standby "Suspend to Ram" oder "Suspend to disk"?


    In MP ist eingestellt Hibernate ("Suspend to disk") und wenn kein MP läuft, dann habe ich in der Energieverwaltung Standby eingestellt ("suspend to ram").
    Daher kommt mir das ganze ja auch umso komischer vor. Evtl. sollte ich das System wirklich mal neu aufsetzen oder auf Win7 upgraden.


    Zitat

    Original von Igor
    Kann es sein das eine andere Komponente in deinem Windows erlaubt wurde das System aufzuwecken? Netzwerkkarte? Fernbedienungsempfänger? oder sowas halt? ggf. auch die Serielle USB Schnittstelle...?


    Die Fernbedienung (MCE Remote inkl. USB Empfänger) darf den Rechner aufwecken.


    Ich glaub auch nicht wirklich daran, dass es an Atmowin liegt. Würde daher eher mal sagen der Patch von gemx ist natürlich Gold wert und den Rest muss ich irgendwie wahrscheinlich selbst hinkriegen (=Neuaufsetzen oder Win7). :schiel
    lg, Jo

    Servus!


    Bin stolzer AtmoLight Besitzer (hinter ner 92" Beamer-Leinwand), kämpfe aber etwas mit der Software...


    Problem: Ich habe ausschliesslich Full-HD Videos (x264). Mein Rechner hat dafür eigentlich auch mehr als genug Leistung.


    Wenn ich nun aber den Mediaplayer von Win7 (64bit) benutze, habe ich sobald AtmoWin arbeitet ein laggen im Bild - trotz sehr geringer CPU-Auslastung.


    Beim Mediaplayer Classic habe ich keinerlei laggen, aber AtmoWin erkennt scheinbar am rechten Rand weiße Pixel, weswegen ich auf den beiden rechten Kanälen ne weiße Überlagerung drin habe.


    Ich verstehe dabei nicht so ganz, warum der normale Mediaplayer laggt. Ein laggen spricht ja eigentlich dafür, dass mein Rechner leistungsmäßig nicht nachkommt, was aber bei 15% Auslastung eher unwahrscheinlich ist! Verringere ich die Bildrate von AtmoWin auf 5 FPS, läufts einigermaßen annehmbar. Aber ne Lösung ist das ja auch nicht...


    Scheinbar hat hier jemand ne Lösung für das Problem gefunden, aber leider nur im MediaPortal, das ich nicht nutze. Könnte aber ein Indiz auf die Ursache bei AtmoWin sein...

    DaOptika
    das ist ein altbekannter Hut - wenn ich mal so sagen darf, der hier im Thread auch schon glaube ich bis zur Gänze erläutert wurde. ;)


    Problem ist und bleibt - das AtmoWin - bei den meisten Playern ohne direkten Support - leider nicht so arbeiten kann wie man es erwartet. Da der DirectShow Filter AtmoDS.dll von allen Playern nicht automatisch geladen wird, sondern nur wenn der Player es erlaubt selbst eigene Filter in die Wiedergabe einzubinden - z.B. bei Media Player Classic gibt es das. (wurde einige Seite früher im Thread mal erläutert wie.)
    Der Normale MediaPlayer lädt den Filter nicht - ergo AtmoWin macht einen Screencapture vom aktuellen Bildschirm - was wiederum z.T. elende langsam ist - warum - frag bitte Microsoft oder wen auch immer es ist einfach so.
    Das was da im mediaPortal gemacht wird - funktioniert leider nur in diesem Kontext und nicht von außen.
    Also bleibt eigentlich nur der Weg - entweder selbst den DSFilter Weiterentwickeln damit er mit dem HD Material zurecht kommt - ich hab leider keinerlei Infos zu den Frameformate aufbau etc. welche da den DS Filter passieren und selbst auch kein geeignetes Testmaterial.


    Oder man verwendet VideoLAN zur Wiedergabe - das ist wohl derzeit der einzige Weg wo auch HD Videos mit AtmoWin bzw. direkt funktionieren könnten?


    Zitat

    Beim Mediaplayer Classic habe ich keinerlei laggen, aber AtmoWin erkennt scheinbar am rechten Rand weiße Pixel, weswegen ich auf den beiden rechten Kanälen ne weiße Überlagerung drin habe.


    mmh keine Ahnung - warum - verwendest du den AtmoDS Filter? oder läuft das ganze via Screencapture? (Screencapture ist wohl der letzte Murks zur Video Wiedergabe - wenn ich das mal ehrlich sagen soll - das ist bestenfalls ne Krückenlösung ;-))



    Igor


    PS.: sollte die Antwort zu angefressen klingen, liegt das einfach daran dass ich den Mist / das Problem schon oft genug gehört habe - es keine wirkliche Lösung gibt - außer es selbst zu programmieren - der code liegt schließlich nicht umsonst zum download da. Und das diese Frage schon X mal hier im Thread mit verschiedenen Geschmacksrichtungen diskutiert wurde.... ;) und man den Thread wohl einfach mal komplett lesen sollte - bevor mans nochmal fragt.

    Ich hab den Thread gelesen - aber hatte bisher den Eindruck, dass das laggen eher was mit der Leistung des Systems zu tun hat.


    Ich benutze beim Mediaplayer Classic das Screencapture-Verfahren und hab selbst bei 50 FPS in AtmoWin nichtmal 50% CPU Auslastung, und da läuft es Performance-mäßig ja auch absolut klasse. Da hab ich keinerlei laggen oder sonstwas! Mit allen Kanälen ausser den Kanälen rechts bin ich ja auch absolut happy, also versteh ich nicht so ganz warum das Screencapturing bei ausreichen Performance ein Problem darstellen sollte. Vor allem macht dann auch Aero und DXVA keine Probleme.


    Umso merkwürdiger find ich es ja, dass der normale Mediaplayer so laggt. Selbst wenn das "Capturen" des Screens lange dauert, sollte das sich ja nicht auf die Wiedergabe des Videos auswirken, es sollte aber nen deutlichen Anstieg der CPU-Last von AtmoWin auslösen (die sich dann sehr wohl auf die Videowiedergabe auswirken könnte). Was aber nicht der Fall ist...


    Im Bezug dazu auch:

    Zitat

    Original von Igor: Also auf die eigentliche Ausgabe des Videos dürfte mein Filter bzw. AtmoWin in keiner Weise Einfluss nehmen - ich reiche die Frames 1 : 1 durch - dass Problem müsste wo anderes zu suchen sein. Igor


    Verwirrt mich halt etwas das Ganze :D

    :) Hab mein Standby-Problem gelöst: War eine falsche Konfiguration des PowerSchedulers in MP. (Da hab ich für meine Tests mal etwas an der Konfig rumgedoktert und dann nicht mehr zurückgestellt :doof)


    Nun funktioniert alles so wie ich es mir vorstelle!
    :welle


    lg, Jo


    Das hört sich ganz danach an als würdest du im MPC den AtmoDS Filter benutzen. Der stellt Atmowin automatisch um, sodass eben nicht mehr über screencapture gearbeitet wird. Das sieht man aber in AtmoWin nicht.
    Das Problem mit dem Filter ist, das er mit HD Material nicht so richtig funktioniert. Habe mir den Mal in einer Debug Variante kompiliert und die gegrabbten Frames anzeigen lassen. Da ist ein Versatz in den Bildern drin, wodurch die Berechnung für die rechte Hälfte falsch ist. Ausserdem "verliert" man die HW-Beschleunigung der Grafikkarte, wenn man den Filter benutzt, da dieser die Frames noch im komprimierten Zustand bekommt. Das dekomprimieren von H.264 usw. findet letzendlich erst später im DS Graphen statt....
    Das könnte ich jetzt noch ewig weiter führen.
    Fakt ist:
    - das Screencapture Verfahren, dass AtmoWin benutzt (BitBlt) ist arg langsam und belastet die CPU (ist Microsoft bedingt)
    - der Filter funktioniert nicht richtig bei HD content und man hat keine HW-Beschleunigung durch die GraKa
    - DirectX Methoden über den BackBuffer funktionieren zwar etwas schneller, liefern aber oft korrupte Frames


    FAZIT:
    Die einzige Möglichkeit, performant das AtmoWin anzusteuern ist, dies in die jeweilige Anwendung zu implementieren und zwar dort, wo der Frame bereits dekodiert vorliegt. Diesen dann am Besten noch im Speicher der GPU zu resizen und über das COM-Interface an AtmoWin zu schicken.
    Das klingt jetzt zwar doof - ist es aber auch :wow


    Es gibt leider keinen anderen Weg. Habe mich jetzt 2 Wochen damit rumgeschlagen. Das ist leider von Microsoft so "verbrochen" worden. Die haben halt bei der Windowsentwicklung einfach nicht an Atmolight gedacht :lol2

    Activy 300 - standard - ohne LCD Display :(
    Kernel 2.6.14, VDR 1.3.42 - Plugins: AdZap, DVD, gnb2vdr, mailbox, mp3, ,mplayer, osdteletext, pilot, vcd, wetter, vdrcd, image, radio, umsadmin, muggle

    Zitat

    Original von gemx
    Das hört sich ganz danach an als würdest du im MPC den AtmoDS Filter benutzen. Der stellt Atmowin automatisch um, sodass eben nicht mehr über screencapture gearbeitet wird.


    Also alles was ich gemacht hab ist: AtmoWin entpacken und starten. Ich habe keinerlei dll's irgendwo hinkopiert, noch hab ich im MPC nen zusätzlichen Filter registriert.
    Als Output benutze ich "EVR" und hab für h264 und VC1 den internen DXVA Filter aktiviert. Die Hardwarebeschleunigung scheint zu funktionieren, sonst wäre die CPU-Last deutlich höher.


    Zitat

    Original von gemx ...wo der Frame bereits dekodiert vorliegt. Diesen dann am Besten noch im Speicher der GPU zu resizen und über das COM-Interface an AtmoWin zu schicken.
    Das klingt jetzt zwar doof - ist es aber auch


    Riecht das nicht quasi nach CUDA?
    Soweit ich weiß lässt sich damit ein sehr performanter Screen-Capture durchführen und das anschließende Resize sowie die Auswertung geht sowieso 20 Mal schneller als mit der CPU...

    gemx


    genau richtig deine Argumentation - warums nicht geht - hab ich sicherlich in der ein oder anderen Variante auch schonmal hier im Thread geschrieben wo das Problem liegt ;)


    Zitat

    Das Problem mit dem Filter ist, das er mit HD Material nicht so richtig funktioniert. Habe mir den Mal in einer Debug Variante kompiliert und die gegrabbten Frames anzeigen lassen. Da ist ein Versatz in den Bildern drin, wodurch die Berechnung für die rechte Hälfte falsch ist.


    Das mit dem Versatz interessiert mich - wenn ich da ein Frame bekomme und mich daran versuche - habe ich wohl das Bildformat falsch interpretiert - es gibt da ja die verschiedensten Geschmackrichtungen wie man YUV Daten (Planar / Packed) transportieren kann - wenn da ein Versatz entsteht - habe ich wohl bei der Extraktion der Bilddaten einen Fehler - nur müsste ich dazu den FOURCC wissen bei dem dies auftritt ... (habe leider nich ausreichend HD Material zum Testen, auch wäre meine CPU wohl zu langsam.)


    Zitat

    Ausserdem "verliert" man die HW-Beschleunigung der Grafikkarte, wenn man den Filter benutzt, da dieser die Frames noch im komprimierten Zustand bekommt. Das dekomprimieren von H.264 usw. findet letzendlich erst später im DS Graphen statt....[/


    exakt - ist leider so die Dekodierung erfolgt z.T. erst in der Grafikkarte - eben wegen der Hardware Beschleunigung.


    naja - Microsoft hat das wohl mit verschuldet - der Content Industrie ist das wohl gerade recht - das keine unkodierten Frames mehr durch den Filtergraphen wandern - von wegen digitalte 1:1 Kopie während der Wiedergabe... ;) durch abgreifen der Frames in einem Filter.



    Das beste AtmoLight könnte man wohl bauen - durch einen Hack im Grafikkartentreiber selbst - wo man direkt an der Quelle der eigentlichen Daten sitzt *g*


    Igor

    Zitat

    Original von Igor
    Das beste AtmoLight könnte man wohl bauen - durch einen Hack im Grafikkartentreiber selbst - wo man direkt an der Quelle der eigentlichen Daten sitzt *g*


    Und ich werf es nochmal in den Raum: CUDA!


    Da gibts ein feines kostenloses SDK direkt von nvidia zum Einbinden in Visual C++ Express 2005. Sind einige Codebeispiele dabei, die betreffenden Threads werden einfach auf die Graka ausgelagert. Das sollte das Problem mit der Hardwarebeschleunigung lösen und würde alle weiteren Filter redundant machen!


    Leider hab ich selbst viel zu wenig Programmier-Erfahrung, sonst würde ich mich da selbst mal dran probieren...

    DaOptika
    das hätte erstmal nichts mit AtmoWin zu tun, mit CUDA könntest du höchstens die Dekodierung der Frames etc. über die Grafikkarte schleusen - d.h. man müsste einen komplett neuen Decoder schreiben - das wird nicht einfach -:)


    Dann hat man aber immer noch das Problem - die Datenmenge die bei einem Full HD Datenstrom für die dekodierten Frames je Sekunde entsteht - müssen erst in komprimierter Form zur Grafikkarte (CUDA) dann in unkodierter Form zurück in den Hauptspeicher - dort durch den AtmoFilter (oder was auch immer) und dann zurück in die Grafikkarte (z.B. als Overlay oder welche Technik auch immer.) - das wird sicherlich deutlich mehr CPU Last erzeugen - als die Variante mit der Hardwarebeschleunigung.


    Was mich interessieren wird - welcher Teil der Ausgabe wird durch DXVA eigentlich beschleunigt? wer macht da was?
    - wie sieht das Datenformat von DXVA aus (struktur?) welche men DirectShow-Filter da passiert?


    - Weiterhin wird man sich mit so einem Codec bei der Content Industrie wohl nicht sehr beliebt machen - da man dann ja vielleicht sogar noch die ganze Digitalen Verschlüsselungskram auf dem HDMI / DVI - umgehen könnte, wenn die Grafikkarte nicht mehr weiß was da genau ausgeben wird -- das ist ja ganz böse dann -- *g*


    Igor

    Hmm ich dachte mir den Weg jetzt eher so:


    Der Player schickt das codierte Bild an die Graka, dort wird das Bild ja sowieso decodiert, ein CUDA-Thread greift das Bild dort direkt ab, ein weiterer kümmert sich um den Resize direkt im Grafikkartenspeicher, ein weiterer CUDA-Thread berechnet nach gewöhnlichem Algorithmus dann den dominanten Farbwert pro Bereich und gibt diesen dann auf die Atmolight-Hardware aus.


    Also quasi eine komplette Verlagerung aller AtmoLight-Threads direkt auf die Grafikkarte! Die CPU bräuchte man dann einfach komplett nicht mehr.


    Mein Wissen im Programmierbereich ist wirklich sehr beschränkt, aber vom Programmieraufwand sollte das eigentlich nicht mehr sein als das Verschieben eines (oder mehrerer) Threads auf nen zweiten CPU-Kern...

    DaOptika
    also ich dachte eigentlich das CUDA lediglich bestimmte Operationen (komplexe Berechnungen) auf die GPU auslagern könne, und nicht komplette Programme / Threads - dafür reicht mein Wissen nicht wirklich.
    selbst wenn man ne CUDA Anwendung hätte, wäre ich mir nicht sicher ob man aus diesem speziellen Kontext heraus überhaupt irgendwie Zugriff auf den Bildbuffer bekommen kann?? mmh - keine Ahnung. Das gehört aber wohl dann doch in ein anderes Forum / Thread ... vielleicht dorthin wo sich jemand damit auskennt?



    Igor

    Wobei CUDA ja nur für Nvidia Karten ist.
    Besser wäre ne Lösung auf OpenCL Basis. Aber das unterstützen nur neue Grafikkarten.



    Wurde eigentlich was verändert bei Atmowin 0.46 zu 0.45 beim beenden von Atmowin?
    Wenn ich die 0.46er Version schließe stellt er sich oft nicht auf die Shutdown Farbe (0,0,0) ein sondern bleibt beim letzten Bild. Ich muss dann Atmowin nochmal starten und wieder schließen. Dann funktioniert es meistens.

    cha0s
    geändert wurde da einiges - mmh - ich guck mal - vielleicht läuft dummerweise zu diesem Zeitpunkt noch der LiveView Thread - und überschreibt den letzten Wert nochmal - ich geh mal gucken.


    ich nehme mal an bei dir läuft AtmoWin ständig im LiveView? oder welcher Betriebsmodus ist aktiv?


    [Edit]
    also auf die Schnelle müsste das eigentlich funktionieren - wenn man die AtmoWin.exe beendet - dass dann Atmo die eingestellte Farbe annimmt. Ich sehe zumindest erstmal kein offensichtliches Problem.


    Igor

    Ja, läuft im LiveView.


    Gerade hats wieder nicht umgeschalten. Ich werd morgen nochmal die 0.45er Version testen ob das Verhalten mit der Version wirklich nicht auftritt.
    Bei gerade 10x starten und beenden hat die 0.45er Version jedenfalls funktioniert wie sie soll.


    Hat wer hier noch Win7 x64 und bekommt nach ein paar Minuten Laufzeit ne Meldung durch Windows, dass eine Leistungsbeeinträchtigung festgestellt wurde und man solle das Farbschema auf Basis umstellen (deaktiviert sämtliche aero effekte). Weiß nicht ob da durch ein Windows Update ne Funktion eingebaut wurde oder ob diese Meldung auch in der 0.45er Version kam. Werde das auch nochmal testen morgen.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden