[atmocontroller] Betrieb unter Windows

nein, sonst nichts,

habe jetzt gerade wieder die 0.35 am laufen. beende ich diese und starte die 0.4er gehts nicht. Starte ich dann wieder die 0.35er gehts wieder

ipconfig - gibt gleich nen Update - ist mein Fehler...
da war ein +1 auf die Auswahl zuviel ... *g* das passiert wenn man kurz vor Schluss nochmal was ändert... weils hübscher aussehen soll (Codeformatierung)

http://eldo.gotdns.com/atmowin/atmoWin_0.41.zip
http://eldo.gotdns.com/atmowin/atmoWin_0.41_source.zip

oder

http://www.primacom.net/~w6533344/

Igor

Yippiekayeah

Zitat

Yippiekayeah

na bitte sehr... wenn du noch was findest immer her damit... aber hoffe nicht bitte gleich das es immer so schnell geht mit den fixes... sitze nicht immer durch zufall so nahe am PC dass ich meine Mails gleich lese *g*

und ich schon wieder

Fehler bei Verwendung von mehreren Bildschirmen Dank dem Debugging von MacGyver behoben...

http://eldo.gotdns.com/atmowin/atmoWin_0.42.zip
http://eldo.gotdns.com/atmowin/atmoWin_0.42_source.zip

oder

http://www.primacom.net/~w6533344/

Und gleich noch ne Idee die MacGyver bei mir platziert hat - derzeit gibt es ja die Option Widescreen... aber was ist z.B. mit Material 2,35 : 1 ?

Müssten nicht je nach Ausgabedevice (ob 16:9, 16:10 oder 4:3?) - und je nach Videomaterial ... andere Ränder abgeschnitten werden? -- extremes Beispiel 4:3 Video auf 16:9 TV - d.h. Rand links und Rechts?
- oder 2,35:1 auf 4:3 TV? ... d.h. die Option Widescreen geht imho nicht weit genug für meine Begriffe?

Was meint ihr - wäre es sinnvoll wenn man im Popup Menü von AtmoWin - auch noch das Seitenverhältnis festlegen könnte?

Igor

Zitat

Original von Igor
Was meint ihr - wäre es sinnvoll wenn man im Popup Menü von AtmoWin - auch noch das Seitenverhältnis festlegen könnte?
Igor

Das wären dann allerdings noch einige weitere Kästchen... Wobei man das Seitenverhältnis vom Medium (Monitor) natürlich über die momentane (Windows)-Auflösung berechnen kann, und in sofern nur grob wichtig wäre, ob 4:3, 16:9 oder immer alles berechnet werden soll. Je nach Monitor muss was weg, oder halt nicht... Wäre eine kleine If-Schleife mehr beim Bildbeschneiden...

Allerdings ist es ja nicht ganz so einfach, wie du schon angedeutet hast wegen der Vielzahl an - nennen wir sie mal - "Zwischenformaten". Wann muss ich was wählen?

Sprich: perfekte Ergebnisse halte ich ohne manuelle Eingabe (mit visueller Rückmeldung) für nicht möglich.
Mögliche Eingabeform für so etwas wäre z.b. ein verkleinerter Screenshot, wo man über eine Rechteck-Maske festlegen kann, wo genau ausgewertet werden soll. Daran könnte man nebenbei auch gezielt auf Visualisierungen von z.B. WinAmp ausrichten. Wie sowas allerdings programmiert wird... Keine Ahnung.

Matthiaz

Zitat

Das wären dann allerdings noch einige weitere Kästchen... Wobei man das Seitenverhältnis vom Medium (Monitor) natürlich über die momentane (Windows)-Auflösung berechnen kann, und in sofern nur grob wichtig wäre, ob 4:3, 16:9 oder immer alles berechnet werden soll. Je nach Monitor muss was weg, oder halt nicht... Wäre eine kleine If-Schleife mehr beim Bildbeschneiden...

Also wenn ich mirs recht überdenke - ist das alles so nicht notwendig - da der Algorithmus die schwarzen Balken eh ignoriert (wegen Schwellwert für Farbe) - hab das gestern extra nochmal probiert mir ein schwarzes Desktop eingerichtet - und dort in de Mitte ein kleines Filmchen laufen lassen - gibt an der Ausgabe die gleichen Farben - wie wenn ich den Film auf Vollbild laufen lassen würde - d.h. die Widescreen Option aus der Linux Version hat eigentlich nur eine Bedeutung für die Linux Version - da dort scheinbar das Capture Device immer eine 4:3 Bild liefert - wenn dieses aber für die Bild-Füllende Ausgabe auf einem 16:9 Display oben und abgeschnitten wird - bewirkt diese Widescreen Option das die abgeschnittenen Bereiche nicht mit in die Rechnung einfliessen -- also ist diese Option eher ne grasse Variante von Overscan Kompensation? -- was IMHO mit Widescreen nicht wirklich was zu tun hat --- weil das der Algorithmus ja schon über den Schwellwert für die Farbe mitbekommt und so sämtliche Schwarze Balken egal an welcher Stelle ob oben/unten oder links/rechts - keinen Einfluss haben.

Jetzt kommt bestimmt gleiche die Fragen - warum es für die Windows Version keine Rolle spielt ob wir einen 16:9 oder 4:3 Monitor verwenden? unser "GDI Capture Device" liefert doch auch immer ein 64x48 Bildchen was ja 4:3 ist? - ja stimmt, aber:
- es steht ja nirgends ob dieses Bildchen das richtige Pixel-Seitenverhältnis haben muss - d.h. wenn z.B. die Auflösung 1360x768 Pixel beträgt - greift der Capture in X-Richtung jedes: 21 Pixel ab, und in Y-Richtung jedes: 16 Pixel

Bei z.B. 1024x768 -> wird in X: 16, Y: 16 abgetastet...

so beinhaltet unser 64x48 Bildchen immer den gesamten Bildschirm - wenn auch ein wenig verzerrt - das stört aber nicht denk ich...

das einzige was ich aber auch schon vorgesehen habe - was wir ggf. kompensieren müssten ist bei der Ausgabe auf herkömmliche TV Geräte via TV Out - da dort ja ein gewisser Overscan am TV auftritt - d.h. Bildteile welche zwar auf dem Desktop - aber auf dem TV nicht zu sehen sind - müssen ignoriert werden für die Atmo Berechnung - dafür hab ich in der Registry schon zwei Parameter hinterlegt - wo man einen Horizontalen und Vertikalen Overscan einstellen kann..., um genau dieses Problem zu vermeiden.

Zitat

Sprich: perfekte Ergebnisse halte ich ohne manuelle Eingabe (mit visueller Rückmeldung) für nicht möglich.
Mögliche Eingabeform für so etwas wäre z.b. ein verkleinerter Screenshot, wo man über eine Rechteck-Maske festlegen kann, wo genau ausgewertet werden soll.

Ich hoffe meine Erklärung war fürs erste mal ausreichend - warum wir keine Sonderbehandlung für Widescreen, 16:9, 4:3 Displays oder Videoformate benötigen... selbst der Parameter Widescreen macht IMHO für die Windows Version wohl keinen Unterschied... bedingt dadurch wie das Screencapture erfolgt.

Zitat

Daran könnte man nebenbei auch gezielt auf Visualisierungen von z.B. WinAmp ausrichten. Wie sowas allerdings programmiert wird... Keine Ahnung.

mmh ne andere Idee das man direkt ein bestimmtes Fenster als Quelle fürs Atmo auswählen kann - wäre noch ein Gimmick... so z.B. das Effekt Fenster von WinAmp... ist recht einfach man muss nur statt GetDC(0)... das Handle von dem Fenster ermitteln... FindWindow lässt grüssen und dieses dann Capturen... ist halt ne Frage wie erkennt Atmo Win welches Fenster es wann capturen soll... und wann den Desktop - d.h. automatische Quellenumschaltung...

Igor

Hi,

ja, das mit Widescreen hast du schon richtig verstanden, hab das eingebaut für meinen Fernseher, weil das ist ein 16:9 Gerät und hat keine auom. Umschaltung. Dh. wenn ein 4:3 Bild dargestellt werden soll kann ich zwar von Hand durch drei Menüs umschalten, dass es mit schwarzen Balken rechts und links dargestellt wird, das ist aber furchtbar unpraktisch. Deshalb habe ich das TV so eingestellt, dass es im Zwifel vom 4:3 Bild oben und unten was abschneidet und so 16:9 draus macht...und dieser Modues heisst eben "Widescreen". Da dieses Feature sicher nur bei einem TV-Signal sinn macht und auf keinen Fall bei einem Monitor (die Dinger kann man ja heut eh nicht mehr zu abschneiden überreden, oder?) kannst du das auch weglassen und keiner ist mehr verwirrt...denke ich zumindest

Die Sache mit dem Fenster find ich aber doch interessant
Grüße,
Simon

samc
die Fensteridee werd ich mal verfolgen - mal sehen wie kompliziert das ist - da man ja dem Fenster auch folgen muss wenn es verschoben wird - ist das schon ein wenig komplizierter *g*

Mmh - ich möchte mein Atmolight ja auch unter Windows einsetzen für Live TV - allerdings gucke ich nicht über den HTPC fern - sondern direkt d.h. mit Kabel Receiver / Sat Receiver ist mit dem TV direkt verbunden und der Receiver hat eine Videoverbindung zu meiner PVR250 - jetzt hab ich die Idee das Signal von der PVR250 im AtmoWin als mögliche Quelle abzugreifen und dort zu verarbeiten....

Gibt es Interesse an so einer Lösung? - den Aufwand nur für mich alleine zu treiben auf weiter flur scheue ich derzeit noch?

Igor

Hi,

mit der PVR250 wirst womöglich Probleme mit Zeitversatz bekommen...hattedie mal unter Win in Betrieb und kann mich da an was erinnern.

Ich werde wohl bald eine Linux-app aus dem atmo-plugin bauen, die selbst von einer bttv Karte liest (sollte in Echtzeit gehen) und atmo drüberrechnet...

Grüße,
Simon

samc
könntest recht haben - die PVR250 hat ne gewisse Latenz.. einige Sekunden... mal sehen ob man das beim Atmo so stark merkt... oder ob ich die Idee aus dem Grund fallen lassen muss...

Igor

PS: was wird aus meinen LED Problem? gelesen?

Ich verwende recht erfolgreich das Atmowin 0.42.
Leider hab ich damit unter DVBViewer und HD und leider notwendigem VMR9 einige Performence- und Darstellungsprobleme... (Ruckeln, OSD funktioniert nicht, Nvidia-Bug)
Trotz DualCore und HD 2600 pro...
Lässt sich das Atmowin denn nicht mit Overlay betreiben? Gibts da keine Möglichkeit? Damit wären alle Darstellungsprobleme gelöst...

@mcdownload

Naja an das Overlay kommt man leider nicht ran - es sei dann man schafft es sich in den Grafiktreiber zu hacken - das mein ich wörtlich! - wenn du da ran kommst - könnte man sogar ... kopiergeschütztes Material 1:1 digital duplizieren *böse*- von daher glaub ich da wirds wohl keine dokumentierte API dafür geben?

- was aber evtl. gehen könnte sind DirectShow Filter bauen - die man in die Verarbeitungspipeline der Frames einklinkt... allerdings ist jetzt natürlich die Frage - da dies ja auch wieder ne Lücke in dem ganzen DRM Quatsch von M$ wäre - ob das in dem Fall auch noch so einfach geht? - wie überzeugt man die Wiedergabe Software davon unserem DirectShow Filter als Zwischenschritt vor die Ausgabe zu schalten?

Bis jetzt hab ich nur ein wenig in diese Richtung gelesen... aber noch nichts programmiert... weil mein Visual Studio irgendwie bockt sobald ich die erste DirectShow "includes" verwenden will...

Igor

Servus!

So einen Filter gibt/gab es schon. Siehe Momolight
Es gibt sogar eine Version für den Atmocontroller. Vielleicht kann man da was abschauen, ich war allerdings mit dem Filter nicht so glücklich.

swifty

swifty99

das kenne ich schon -nur leider hat der Autor meines Wissens nach keine Quellen veröffentlich... sondern nur das Binary... vielleicht muss man mal einen Bettelbrief schreiben...

Igor

ich krieg den AtMomolightfilter absolut nicht zum laufen. Wenn ich im DVBViewer den Filter als Postprozessor aktiviere, schalten die LEDs auf Blau, das wars dann schon...
Ich glaube auch, dass der Filter nicht mit Overlay läuft...

mcdonald

So ein DirectShow Filter den wir brauchen hat erstmal nichts mit dem Overlay zu tun - das ist die Aufgabe des letzten Filters in der Kette der sich darum kümmern muss das Frame auf den Bildschirm zu bekommen... unser Filter den wir haben müssten - hängt irgendwo zwischen Decoder Filter ... und Ausgabe Filter ... von einem Overlay weiss dieser nix.

Das würde sich vom theoretischen so verhalten - zunächst wird durch einen Filter der Stream in Audio und Videodaten zerlegt, der Video Stream geht durch den Video Decoder z.B. Mpeg2, DivX -- aus dem kommt ein Stream von Frames als "Einzelbilder" heraus - diese Frames gehen eins nach dem anderen durch unseren Filter - und unverändert an den Ausgabefilter weiter... wir ziehen uns nur ein Mini Bild und geben das zur Verabeitung an unsere übliche Logik... Mal sehen wenns morgen regnet und ich sonst nix zu tun bekomme... ist das ja mal ein Feiertagsprojekt... da was zu basteln... so schwer kanns doch eigentlich nicht sein?? oder?

Igor

Das wäre eine wunderbare Sache, so ein Filter...
Das VMR9 macht mir wirklich nur Probleme, die ich vorher nicht hatte...
Ich bin ja schon froh, dass das AtmoWin so ohne Probleme läuft...

Hallo Igor,

ich habe mir ein Atmolight mit der dritten Sammelbestellung von Pasi bestellt.
Ich will das ganze unter Windows mit MediaPlayerClassic und ffdshow betreiben.
Deshalb vervolge ich diesen Thread gespannt. Ich habe mir das AtmoWin installiert und die Sourcen durchgeschaut.
Als Videoausgabe verwende ich den OverlayMixer.

Der DirectShow Filter ist sicher der richtige Weg für Video.

Ich habe einen solchen DirectShow Filter zum Test erstellt (Habe beruflich schon einige Filter geschrieben). Ich habe das Sample Ezrgb24 vom Plattform SDK genommen, einen Inplace-Filter daraus gemacht, in der Transform Funktion in das Original-Bild ein 64x48 Vorschaubild eingeblendet, um zu sehen, ob das ganze funktioniert: Es funktioniert ohne viel CPU-Zeit zu verbrauchen.
Bisher verarbeitet der Filter nur RGB32, er muss am Ende natürlich auch YV12 verarbeiten können.

Ich habe zur Zeit wenig Zeit um nebenher etwas zu programmieren.

Wenn es euch hilft, kann ich die Sourcen zur Verfügung stellen.

Gruß

Bernd

Hallo Bernd,

kurze Antwort her mit dem Source - klingt interessant so hatte ich mir das vorgestellt - einen DummyFilter mit einem Input Pin und einem Output Pin der die Daten nur durchreicht und sich mini Kopie der Framedaten zieht...

>>bissher verarbeitet der Filter nur RGB32, er muss
>>am Ende natürlich auch YV12 verarbeiten können.
gut ich denk da muss man halt noch ein wenig dran arbeiten, um die anderen Farbformate auch zu beherrschen bzw. umzurechnen... aber das ist ja nur Mathematik *g*
Wenn erstmal das Grundgerüst der Funktionsweise klar ist...

Welche Voraussetzungen brauche ich für deinen Filter? hab mir jetzt noch das DirectX9 SDK installiert damit ich die notwendigen Header Files für Visual Studio habe...
Welche Version von Visual Studio verwendest du?
wäre nicht schlecht wenn du uns ein komplettes Projekt zur Verfügung stellen würdest... was man erstmal für den Anfang kompiliert bekommt?

Wenn der Quellcode als Zip nicht zu gross kannst du ihn ja mal als Anhang ins Forum stellen - andernfalls hast du von mir schonmal PM.

Igor