Beiträge von brshub

    Hallo,


    Stand AtmoDSFilter:


    ich bin kaum zum Programmieren gekommen. (letzte Woche ca 4h)


    Der DirectShow Filter verarbeitet zur Zeit nur RGB32 als Input. Mit MediaPlayerClassic, DVD input(720x576) habe ich ohne AtmoDSFilter ca. 10% CPU Verbrauch, mit dem Filter ca 20% (Pentium 4, 3GHz). AtmoWin verbraucht im Dummy Modus < 1% CPU.


    Ich habe in die Transform Funktion des Filters (dort wo die einzelnen Frames kommen) das Capturen ins Thumbnail eingebaut. Dann habe ich in meiner Testapplikation in der Verarbeitung ein Sleep(500) eingebaut und das Video in MPC (MediaPlayerClassic) ruckelt (eigentlich klar). Deshalb habe ich die Verarbeitung in einen extra Thread ausgelagert, dass die Videoausgabe auf jeden Fall flüssig bleibt. Das funktioniert jetzt. Das Öffnen von TS Streams und YV12 als Input funktioniert noch nicht. (Das muss unbedingt noch sein.)
    Eine Propertypage will ich auch noch für den Filter erstellen: (Thumbnail width/height/format).


    Ich brauche dazu mindestens nochmal einen Abend, aber meine Zeit ist zur Zeit sehr knapp. (Ausserdem habe ich ja noch kein AtmoLight).



    Gruß Bernd

    Hallo,



    sieht gut aus mit dem DirectShow Filter. Ich habe das Interface eingebaut, konnte aber nicht testen ob es funktioniert, weil ich ja kein AtmoLight habe.


    Ich habe mir deshalb eine AtmoDSFilterTestApp Applikation gemacht, die ebenso wie AtmoWin den Com-Server beinhaltet und das Vorschaubild mit SetDIBitsToDevice im Fenster ausgibt. Das funktioniert für RGB32 Video-input.


    Werde den Source noch etwas überarbeiten, mal sehen wie es diese Woche noch klappt.


    Zitat

    Allerdings ein Problem sehe ich noch kommen - die Wandlung das YV12 Formates oder dieser anderen typischen Overlay Formate und unser HSV Picture .... hast du dir mal den Speicheraufbau eines solchen YV12 Bildes angesehen?


    YV12 ist ein planares Format: es kommen erst die Y daten, dann U und V. Etwas andere Pointer Arithmetik. Es gibt etwas seltsame Formeln zum Umrechnen in RGB. Ich denke es wäre gut, wenn man im Filter das Übergabeformat in der PropertyPage wählen könnte.



    Gruß Bernd

    Hallo,


    ich habe am Freitag abend die sourcen von atmowin geladen, konnte sie aber nicht übersetzen, weil die AtmoWin.idl Datei nicht enthalten war. Ich habe dann selbst eine idl Datei und einen Com-Server mit dem Interface als Beispielanwendung erstellt, habe das wie im Source von Igor in die Rot eingetragen. Konnte auch im Client einen Interface-Pointer bekommen, die Funktionen des Interfaces aufzurufen hat aber nicht funktioniert (Exception). Gegen 2Uhr habe ich entnervt aufgegeben.


    Am Samstag und Sonntag hatte ich keine Zeit. Jetzt habe ich mir die aktuellen Sourcen angesehen. Exzellente Arbeit von Igor! Es scheint nicht mehr viel Arbeit zu sein den DirectShow Filter zu schreiben.



    Bis dann Bernd

    Igor


    Zitat

    Und du stimmst meiner Idee zu - das de COM Server in der AtmoWin.exe implementiert ist? und du diesen aufrufst sobald du ein Frame erzeugt hast.


    Das klingt sehr logisch. Evtl. könnte man sich das mit der ROT dann auch sparen wenn man den COM server singleton-mäßig macht.


    Zitat

    Vielleicht sollten wir bei den Pixeldaten noch ein Height und Width mitgeben - falls wir später nochmal die Auflösung ändern wollen? sind ja nur zwei Parameter...


    Das müssen wir eigentlich nicht, denn es wird ja im Variant ein BITMAPINFO incl. Pixeldaten übergeben. Auch den ersten Parameter für das Format kann man sich sparen, wenn man z.B. bmiHeader.biCompression = FCC('YV12') setzt.



    Matthiaz
    mcdonald


    ich wollte eigentlich keine so hohe Erwartungshaltung erzeugen.



    Bernd

    Igor


    ich werde schauen, was ich machen kann. Für eine Developer Session (ganzes WE) habe ich aber nicht die Zeit.
    Aben wenn ich ja einen COM Server schon habe, brauche ich das Interface ja nur noch zu implementieren.
    Ich denke es wäre gut, wenn der Filter die Funktion SetNewPixelData(int format, VARIANT* var) in einem separaten Thread aufruft, dass falls die Verarbeitung in AtmoWin.exe lange dauert, der Videostream in der VideoApp nicht blockiert ist.


    Bernd.

    Hallo Igor,


    meine Idee ist folgende:


    der DirectShow Filter stellt ein Com-Interface zur Verfügung mit der Funktion HRESULT GetBitmapInfo(VARIANT* var); er registriert sich in der ROT (Running object table), erstellt mit SafeArrayCreate einen Speicherbereich, der prozessübergreifend verwendet werden kann. Er schreibt das 64x48 Thumbnail in das Array. AtmoWin.exe enumeriert die ROT und liest daraus das Interface, ruft GetBitmapInfo auf und bekommt aus dem SafeArray ein LPBITMAPINFO mit SafeArrayAcessData. Der Rest der Verarbeitung liegt bei AtmoWin. Der Filter wäre relativ rivial.
    Ich denke das müßte geschwindigkeitsmäßig gut klappen, wenn SafeArrayAccessData sich nicht ausbremst (von unterschiedlichen Prozessen).


    Ich könnte das testhalber in den Filter einbauen, aber erst am Wochenende.



    Gruß Bernd

    Hallo Igor,


    das Projekt ist mit Visual Studio 2005 erstellt, natürlich C++ unmanaged.


    Das DirectX SDK bringt nichts, da DirectShow nicht mehr in DirectX enthalten ist, sondern im Plattform SDK zu finden ist.
    Plattform SDK:
    http://www.microsoft.com/downloads/details.aspx?FamilyId=74DD6E2D-89C6-4E1E-AF00-FC7D70F15439&displaylang=en


    Ich schicke das komplette Projekt als Zip Datei, ist nicht sehr groß (ca. 300kB).


    Werde die Dateien noch etwas umbenennen, so dass man einen besseren Programmrumpf hat.



    Gruß Bernd

    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