WebCam mit DirectShow

[grizzly]

VSampleDemo

Es gibt Beispiele zu Hauf, wie man WebCams mittels Video for Windows (VfW) anspricht. Wie das Ganze mit DirectX funktioniert ist schon weit weniger gut dokumentiert. Mittlerweile gibt es dafür Lösung in DSPack und der Komponente TVideoSample von Egor Averchenkov (ich hab's allerdings nicht ausprobiert).
Trotzdem stelle ich hier mal meinen Port der Microsoft DirectX 9.0 SDK Update (Summer 2003) Beispiele PlayCap und PlayCapMoniker vor.

Im Anhang findet ihr einen Screenshot (Version 2.1) und den Source der Demo-Applikation (Version 3.1).
Link zu Screenshot, Binary und Source auf meiner Homepage: VSampleDemo.

Der Aufbau der Demo-Applikation ist grob wie folgt:
- VSample.pas greift auf die Webcams zu. Diese Unit ist der eigentliche Port der Microsoft C++ Beispiele.
- VFrame.pas erlaubt einen vereinfachten Zugriff auf VSample, inklusive einer "NewVideoImage"-Event Methode
- Frame_Video.pas bietet eine (häßliche!) Oberfläche zur Steuerung (Start/Stop/Anzeige), gekapselt in ein TFrame (unglückliche Namensähnlichkeit)
- MainForm beinhaltet zwei der Frames aus Frame_Video.pas, damit gleichzeitig zwei laufende Videos angezeigt werden können.

History:

Version 3.2
09.07.2012
- Support für 8-Bit Graustufenbilder. Statt RGB Bilder nachträglich in Graustufen umzurechnen, kann man nun direkt 8-bit Graustufenbilder abfragen (Property Gray8bit). Bringt aber nur bei Codecs wie YUY2 Zeitersparnis, bei RGB kostet es Zeit!
- Liste der unterstützten Videoauflösungen korrigiert. Bisher stand da jeder Eintrag doppelt.
- Kleinere Speicherlöcher geflickt.

Version 3.1
06.05.2012
Kleinere Korrekturen und Anpassungen:
- YUY2 nimmt nun Rücksicht auf Microsofts LifeCam Cinema (Die schickt im 1280*720 Video mode 33% mehr Daten als nötig)
- MJPEG Dekompression mit GDI+. Das ist etwas schneller als das in Delphi mitgelieferte JPEG.
- Die Bild-Spiegelung in der Demo3 führte auf meinem etwas neueren Win7 64bit zum Crash. Habe die Methode jetzt geändert.

Version 3.0
23.08.2009
- Unterstützung anderer Videoformate (nicht nur RGB):
° YUY2 (YUYV, YUNV)
° MJPG
° I420 (YV12, IYUV)
- Direkte Ansteuerung der Video-Eigenschaften
- Überwachungs-Modus "Surveillance". Schreibt JPG Dateien in ein "Spy" Unterverzeichnis. ACHTUNG! Laßt euch nicht die Festplatte volllaufen!


Version 2.1
30.08.2008
- Neuere DirectX Header und Jedi.inc-Datei
(Damit sollte der Code mit Delphi >7 kompilierbar sein)
- Rudimentäre Echtzeit-Video-Bildverarbeitung:
° Invertieren
° Umwandlung in Graustufen
° Hervorhebung der Änderungen zum vorherigen Video-Frame
- Pause/Resume
- Update der Kameraliste mittels Popup möglich
- Kameras werden über ihren Index innerhalb der Kameraliste und nicht mehr über den Namen gestartet.
(Dies sollte die Verwendung zweier Kameras mit gleichem Namen ermöglichen)


Version 2.0
27.07.2008
- Callback Bug beseitigt.
- DirectX Dateien mit im Archiv (spart den separaten Download)


Version 1.0
05.06.2006
- Initial version


Da VSampleDemo mittlerweile arg unübersichtlich geworden ist, habe ich noch drei ganz simple Demos zur Verwendung von VSample.pas und VFrame.pas gestrickt. Source-Codes findet ihr ebenfalls im Anhang.


Gruß
Michael

[Gutelo]

Hallo Grizzly,

noch eine weitere Frage. Ich verwende Version 3.0, da ich nicht diese Graphik lib einbinden moechte. Allerdings wuerde ich gerne die doppelten Eintraege bei der Liste der Aufloesung entfernen (korrigiert in version 3.2).

Nun habe ich Unterschiede in FUNCTION TVideoSample.LoadListOfResolution: HResult; zwischen Ver. 3.0 und 3.2 gesucht und die Zeile

IF not(IsEqualGUID(ppmt^.formattype, KSDATAFORMAT_SPECIFIER_VIDEOINFO2)) then

gefunden. Diese habe ich bei Version 3.0 hinzugefuegt. Allerdings aendert das nichts an der Menge der aufgelisteten Aufloesungswerte. Ich bin mir nicht sicher on meine doppelten Eintraege ueberhaupt doppelt sind. Jede Aufloesung kommt zwar doppelt vor, aber jeweils endend mit ...(RGB) oder ...(xyz) wobei xyz chinesische Character sind (siehe Anhang). Ich vermute dass es zwei unterschiedliche Graphikformate sind.

Gutelo

[grizzly]

Hallo!

In der 3.2 ist in TFormatInfo der Typ von FourCC geändert: Von ARRAY[0..3] OF char zu ARRAY[0..3] OF ansichar.
Vielleicht behebt das schon das Problem mit der ulkigen Angabe zum verwendeten Kompressor.

Welche Grafik lib meinst Du? GDI+?
Falls das das Problem ist: In Unit VFrames.pas einfach die Unit UGDIPLus rauswerfen. Beim Kompilieren wird dann ein Fehler in der Methode UnpackFrame moniert. An dieser Stelle ist aber der alte Code noch drinnen. Einfach den GDI+ Zweig auskommentieren, und die 3.2 läuft ohne GDI+:

Delphi-Quellcode:

{
 IF GDIPlusAvailable // GDI+ version is faster than Delphi's JPEG library
   then begin
     if fGray8Bit
       then GDIPlus_LoadBMPStream2(MemStream, FBitmapGray)
       else GDIPlus_LoadBMPStream2(MemStream, FBitmap);
   end
   else begin}
     JPG.Grayscale := fGray8Bit;
     JPG.LoadFromStream(MemStream);
     if fGray8Bit
       then FBitmapGray.Canvas.Draw(0, 0, JPG)
       else FBitmap.Canvas.Draw(0, 0, JPG);
   {end;}

Hätte ich einen Compiler-Switch machen sollen...

Gruß
Michael

[grizzly]

Ups, jetzt sehe ich erst die anderen Posts.

@Drumbo: 64-bit habe ich noch keinerlei Erfahrung, da werde ich so bald keine Antwort liefern können. Aber unterstützen die neuen Delphis (X2, X3, X4, X5 etc) nicht schon von Haus aus Video, so dass man meinen Code hier gar nicht braucht?

@Gutelo: Das mit dem fVideoRunning hört sich nach einem Fehler an. Muss ich bei Gelegenheit prüfen. Momentan ist nur mal wieder die Zeit knapp

Gruß
Michael

[wamkuipers]

Bitte entshudige mich, i rede nicht sehr gut Deutsch.

I have a problem with vsample.pas. Basicly i like the software.

I my application
procedure TVideoImage.WndProc(var Msg: TMessage);

calls in fOnNewFrame(self, fWidth, fHeight, fImagePtr[fImagePtrIndex]);

multiple times in a re-entrant way.

That causes even program crashes.

It is not clear why that happens.
I assume that errors occur not caught by
Application.HandleException(Self); // the wrong Thread?

Actually my callback procedure is called in the VCL (mainform) thread which is ok.

I can get clear how it can occur that my call procedure is called again before is has finished!
A posible reason could be improperly handled errors.
Also the DSPACK have a similar behaviour, but even a lot worse.

My callback procedure use (mainform).update calls, which should be allowed in the VCL thread. (With DSPACK the callback procedure does is NOT called in the VCL thread ...)

Further more the video picture blocks with moving the mainwindow with a leftmouse down.

Any sugestions what could cause my trouble?

Kind regards
William