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

[taktaky]

Hi
[Fatal Error] VSample.pas(30): File not found: 'DirectShow9.dcu' !!!

[Nuclear-Ping]

[Fatal Error] Taktaky.brain(30): Google not found: 'DirectShow9.pas' !!!

[Mokuba01]

Zitat:

Zitat von taktaky

Hi
[Fatal Error] VSample.pas(30): File not found: 'DirectShow9.dcu' !!!

Zitat:

Zitat von Delphi 6 Professional

[Fataler Fehler] VSample.pas(30): Datei nicht gefunden: 'DirectShow9.dcu'

dem kann ich mir nur anschließen

[mkinzler]

Delphi + DirectX = Clootie

[grizzly]

Hab kleine Korrekturen vorgenommen und die Demo-Applikation überarbeitet.
Siehe ersten Post.
Die benötigten DirectX Header Dateien sind nun beim Sourcecode mit abgelegt.
(Mit DSPack o.a. seid ihr aber nach wie vor besser bedient ;) )


Gruß
Michael

[wazup]

Ich bekomme Fehler beim Compilieren in der Unit DirectDraw.pas:

Code:

[DCC Error] DirectDraw.pas(359): E2154 Type 'IDirectDrawSurface' needs finalization - not allowed in variant record
[DCC Error] DirectDraw.pas(366): E2154 Type 'IDirectDrawSurface' needs finalization - not allowed in variant record
[DCC Error] DirectDraw.pas(376): E2154 Type 'IDirectDrawSurface' needs finalization - not allowed in variant record
[DCC Error] DirectDraw.pas(383): E2154 Type 'IDirectDrawSurface' needs finalization - not allowed in variant record
[DCC Error] DirectDraw.pas(395): E2154 Type 'IDirectDrawSurface' needs finalization - not allowed in variant record
[DCC Error] DirectDraw.pas(835): E2154 Type 'IDirectDrawSurface' needs finalization - not allowed in variant record
[DCC Error] DirectDraw.pas(837): E2154 Type 'IDirectDrawSurface' needs finalization - not allowed in variant record
[DCC Error] DirectShow9.pas(149): F2063 Could not compile used unit 'DirectX\DirectDraw.pas'

[grizzly]

Tatsächlich, mit Turbo Delphi (=2006) erhalte ich denselben Fehler.

Die Ursache ist simpel:
Die DirectX Sourcen im Archiv sind etwas alt. Das beigelegte Jedi.inc kennt keine Compiler neuer als Delphi 7. Und deshalb wird die Compilerdirective COMPILER5_UP nicht definiert.

Bei mir hat es gereicht, in der Datei DirectDraw.pas in die Zeile 72 (gleich nach "{$I DirectX.inc}") ein "{$DEFINE COMPILER5_UP}" einzufügen, und schon konnte ich kompilieren:

Delphi-Quellcode:

unit DirectDraw;

interface

{$I DirectX.inc}

{$DEFINE COMPILER5_UP}  // <= Das hier mal zu Testzwecken einbauen

Das ist zwar nicht schön, aber um zu gucken, ob das die Ursache war, reicht es allemal. Ein neues Jedi.inc wird schon aufzutreiben sein. Vielleicht komm' ich morgen dazu, das Archiv upzudaten...

Gruß
Michael

Edit: Neue Version 2.1 im ersten Post. Kompiliert bei mir mit Turbo-Delphi ohne Probleme.

[grizzly]

Neue Version 2.1 im ersten Post.

Hat nun nicht nur neue DirectX Header, damit es auch mit frischen Delphi-Versionen kompiliert, sondern auch ein paar kleine Beispiele zur Manipulation der Videobilder in Echtzeit:
- Invertieren
- Graustufen
- Differenzbilder (interessant für Leute, die die berüchtigte "Überwachungskamera" realisieren wollen.)


Gruß
Michael

[rakekniven]

Schönes Tool, dass hier mit zwei Logitech QuickCam E 3500 tadellos funktioniert.

Ein Hinweis noch:
Ich habe hier die beiden Cams mit 640 x 480 laufen und muss das Fenster vergrößern. Beim FormResize wird der Splitter nicht positioniert.

Interessen an einem Patch oder Ideenvorschlag?

Gruß

[krzyk_91]

Ich habe ein Problem mit dem Programm. Wenn ich die Auflösung vergrössern will, klicke ich auf Videosize und ändere eine größere Auflösung und ich bekomme einen Fehler: This format is not currently available. Weiß jemand, wie man das korrigieren kann???

[grizzly]

Die Demo 2.1 kann nur RGB24 Video-Frames verarbeiten. Vielleicht liefert Deine Kamera bei höheren Auflösungen kein RGB24 mehr?
Wenn das das Problem ist, dann mußt Du Dich noch ein wenig gedulden: Demnächst gibt es eine neue Version, welche noch folgende drei Formate unterstützt:

YUY2 (vermtl. baugleich mit YUYV, YUNV)
MJPG,
I420 (vermtl. baugleich mit YV12, IYUV)

Da kann ich mich dann auch gleich um den Splitter kümmern, der ärgert mich selber auch schon....


Gruß
Michael

[krzyk_91]

andere Programme, z. B. amcap stellen mir größere Auflösungen zur Vefügung, aber ich werde warten, bis eine neue Versoin zugänglich ist

[grizzly]

So, die neue Version ist da: Version 3.0 im ersten Post.

Wie immer war zu wenig Zeit zum Schreiben und Testen.

Bekannte Mängel:
1.
Die Software hätte noch gut einen Warnhinweis vertragen, wenn man eine Kamera im Surveillance-Modus betreibt. Da werden bis zu 4000 JPGs auf die Platte geschrieben! Außerdem versucht sie gnadenlos, ein Spy Unterverzeichnis anzulegen - was auch nicht immer klappen wird!
2.
Die Liste der verfügbaren Video-Auflösungen wird nicht angepaßt, wenn man beispielsweise die Auflösung über die Treiber-Dialoge ändert.
3.
Ich mir noch nicht sicher, ob es eine gute Idee war, beim Call-Back von "Buffered" auf das Sample-Interface zu wechseln. Falls es sonderbare Effekt mit der neuen Version gibt, in VFrames.pas, in der Routine VideoStart die 0 in eine 1 umwandeln:

Delphi-Quellcode:

VideoSample := TVideoSample.Create(Application.MainForm.Handle, false, 0, HR)  // 1 statt 0 eintragen

4.
Der direkte Zugriff auf einige Video-Eigenschaften hat gelegentlich keinen Effekt. Vielleicht ist es aber auch nur ein Kamera-Gerätesoftware Problem.

Nachtrag:
Da VSampleDemo mittlerweile viel zu überfrachtet ist, um wirklich noch als "Demo" zu funktionieren, habe ich noch drei Miniatur-Demos erzeugt:
Demo01: Öffnet die erste gefundene Videokamera und zeigt deren Bilder an. Nichts weiter.
Demo02: Erlaubt Auswahl der Kamera und Start/Stop Operationen
Demo03: Wie Demo02, zusätzlich kann man die Eigenschafts-Dialoge der Kamera aufrufen, Bilder abspeichern, und es wird gezeigt, wie sich in die Videobilder malen läßt.
Source dieser simplen Demos findet sich ebenfalls im ersten Post.


Viel Glück :roll:
Michael

[grizzly]

Kleines Update:

Version 3.1 im ersten Post. Dort sind auch die Änderungen am Code vermerkt.


Gruß
Michael

[Zacherl]

Sehr schönes Beispiel zur Webcamverwendung. Habe das Teil grade mal unter XE2 kompiliert und mit FakeWebcam getestet. Dort hängt sich die Anwendung allerdings dauerhaft auf, wenn ich folgende Zeile nicht auskommentiere:

Delphi-Quellcode:

FUNCTION TVideoSample.GetStreamInfo(VAR Width, Height: integer; VAR FourCC: dword): HResult;
VAR
  ..
BEGIN
  Width := 0;
  Height := 0;
  // Die folgende Anweisung führt zum Einfrieren des Programms
  // pIMediaControl.Stop;

[grizzly]

Vielen Dank für den Test!

Ich habe diese Zeile bei mir nun auch mal rausgeworfen, sowie die zugehörige Zeile

Delphi-Quellcode:

pIMediaControl.Run;

am Ende der Prozedur. Und es macht auf keinem meiner Rechner / Webcams etwas aus. Video läuft nach wie vor.

Jetzt muß ich noch rausbekommen, warum ich diese Zeilen überhaupt drinnen hatte und warum es bei keiner meiner 5 verschiedenen Webcams bisher ein Problem war.
Vielleicht gibt's Ende der Woche die Version 3.11 mit Deiner Änderung...

Gruß
Michael

[grizzly]

Neue Version 3.2 im ersten Post.

Da ich für ein anderes Projekt Graustufen Information benötigt habe und der Umweg über Rohdaten --> RGB --> Graustufen bei einigen Codecs echte Zeitverschwendung ist, habe ich jetzt noch den Support für 8-Bit Graustufenbilder eingebaut.

@Zacherl: Deine Änderung ist übernommen. Ich verstehe zwar immer noch nicht ganz, warum es geklemmt hat, aber ich hatte in den letzten Wochen keine Probleme wegen der Änderung (3 Rechner, 5 Cams). Dann wird's schon passen. Nochmals Danke für den Hinweis!

Gruß
Michael

[Drumbo]

Guten Morgen,

Das Tool ist echt super! Ich hab nur folgendes Problem:
Wenn ich es für eine 32bit Zielplattform compiliere und bearbeite funktioniert alles super.
Wähle ich nun jedoch eine 64 bit PLattform bleibt der Compiler schon bei den Directx header hängen.
Jetzt ist meine Frage: gibt es eine möglichkeit dieses Tool auch für 64 Plattformen zu schreiben?

Gruß Drumbo

[Gutelo]

Hallo,

Tolles Paket und funktioniert prima. Ich habe nur ein Problem mit der Property VideoRunning, die immer auf false steht unabhaengig davon ob die Webcam gestartet oder gestoppt wurde. Woran kann das liegen? Oder muss man VideoRunning selber setzen?

Gutelo

Edit: so wie ich das sehe wird VideoRunning nur bei VideoStop auf false gesetzt aber bei VideoStart nicht auf true.

Grizzly, sollte man nicht fVideoRunning := true; bzw fVideoRunning := false; bei den Prozeduren VideoStart, VideoPause, und VideoResume einfuegen?

[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 :cry:

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