Bild von IP-Webcam auslesen

[himitsu]

MJPEG und irgendwas von RealMedia liefert die Kamera via HTTP/HTTPS.

Und dann ist noch so Zeug wie eingebaut.
RTSP (Real-Time Streaming Protocol) - Port 554
Remote Playback - Port 8866 (?)


So, dann schau ich besser erstmal ob der Kunde die Kameras auch aktiviert hat.
So ging ja erstmal eine Woche drauf, nur um die IPs zu bekommen und daß die Kameras auch aktiv sind.
und vorher erstmal zu erfahren was das nun genau für Kameras sind.
Mir sagte man ja nicht, daß es IP-Webcams sind und so hab ich mich erstmal auf CAPI und Co. gestürzt und als dann alles fertig war und es beim Kunden getestet werden sollte ...... nja.

[Morphie]

Das Problem kenne ich... Egal wie detailliert man ein Lasten/Pflichtenheft (oder etwas vergleichbares) schreibt, es fehlen immer irgendwelche Details, die dazu führen, dass man nachbessern muss...

[himitsu]

Lasten- und Pflichtenheft ist gut ... "bau ma was ein, damit wir auch von einer webcam das bild in DMS bekommen"

Nja, da mach ich mal 3 Wochen Urlaub und schon schaltet wer die Kameras aus.


Aber zur Komponente.
Wenn du z.B. von TComponent erbst und den TThread nur als Unterkomponente laufen läßt, dann kann man diese Komponente auch nett auf der Form oder einem DatenModul ablegen und gemütlich über den OI die Events anhängen.
Bzw. das TThread.Execute ganz einfach über TThread.CreateAnonymousThread(...) startet, die Synchronisierung über TThread.Synchronize(nil, ...) schiebt und sich somit die komplette TThread-Instanz erspart.
(im Notfall kann ich's dir auch mal in wenigen Minütchen entsprechend umstellen)



PS: Den Mist mit dem TfrmMain.JPEGReceived hab ich auch schon erlebt.
grad erst vor paar Wochen, als ich meine Webcam schnell mal via CAPI reingebaut hatte.

Wusstest du, daß es theoretisch sowas gibt?

Delphi-Quellcode:

procedure TfrmMain.JPEGReceived(Sender: TObject; Data: TMemoryStream);
begin
  Image1.Picture.ForceType(TJPEGImage);
  Image1.Picture.Graphic.LoadFromStream(Data);
end;

Aber weil irgendein besch* Arsch diese Prozedur unbedingt als Private deklarieren mußte, sieht der Ersatz-Code praktisch so aus

Delphi-Quellcode:

procedure TfrmMain.JPEGReceived(Sender: TObject; Data: TMemoryStream);
var
  JPEG: TJPEGImage;
begin
  if not (Image1.Picture.Graphic is TJPEGImage) then begin
    JPEG := TJPEGImage.Create;
    try
      Image1.Picture.Assign(JPEG);  // bzw. Image1.Picture.Graphic := JPEG;
    finally
      JPEG.Free;
    end;
  end;
  Image1.Picture.Graphic.LoadFromStream(Data);
end;

Oder eben so, wie bei dir.

[Morphie]

Zitat von himitsu:

(im Notfall kann ich's dir auch mal in wenigen Minütchen entsprechend umstellen)

Das wäre nett, würde mich schon interessieren, was man noch so alles verbessern kann

[himitsu]

Ohhh, der MJPEG-Stream das sind einfach nur viele HTTP-Anfragen in einer Connection?
Im Prinzip müsste es dann doch auch gehn, wenn ich auf den Stream einfach vie TIdHttp zugreife, welches schon eingebaut ist.
Dann könnte ich es so erstmal so beim Kunden schnell zum Laufen bringen.

Ich probiere es so dann erstmal aus und schau dann, was ich mit deiner Komponente machen kann.
Wäre auf jeden Fall einfacher, als jetzt einen ActiveX-Server zu installieren oder andere extrem große Fremdkoponenten reinzubekommen.



Für die Schnittstellen noch ein Hinweis:

Verwende besser kein TMemoryStream für die Parameter in öffentlichen Schnittstellen, sondern lieber einen passenden gemeinsamen Vorfahren.
Du kannst intern gern den TMemoryStream verwenden, aber als Parameter/Schnittstelle macht sich der Basistyp TStream besser.

z.B. kann man bei procedure Test(Data: TStream); alles übergen, was einen Stream darstellt, auch TMemoryStream und TFileStream.
Aber wurde es direkt als TMemoryStream deklariert, dann kann man keinen TFileStream mehr übergeben.
(Ausnahmen sind natürlich, wenn intern direkt auf spezielle)

In deinem Fall kommt der Stream da zwar raus und wird nicht reingegeben, aber insgesammt sind Komponenten/Codes einfacher wiederverwendbar, wenn sie sich auf gemeinsame Basistypen beziehen.

[Morphie]

Zitat von himitsu:

Ohhh, der MJPEG-Stream das sind einfach nur viele HTTP-Anfragen in einer Connection?

Es gibt eigentlich nur eine einzige Anfrage an den Server. Der sendet daraufhin quasi eine "unendliche" Antwort zurück.
Die "unendliche" Antwort besteht im Prinzip aus unendlich vielen JPEGs + Größenangabe usw.

Zitat von himitsu:

Im Prinzip müsste es dann doch auch gehn, wenn ich auf den Stream einfach vie TIdHttp zugreife, welches schon eingebaut ist.
Dann könnte ich es so erstmal so beim Kunden schnell zum Laufen bringen.

Ob man mit idHTTP darauf zugreifen kann, weiß ich nicht, da der Stream ja nie komplett heruntergeladen werden kann...

Zitat von himitsu:

Für die Schnittstellen noch ein Hinweis:

Danke, werde ich berücksichtigen

Wenn das so weitergeht, kann womöglich noch eine ordentliche Komponente entstehen (vielleicht was für die CodeLib?)

[jensw_2000]

Oder Du nimmst das VLC ActiveX Control.
Das kann RTSP und Screenshots aus dem Videostream IMHO auch.

[himitsu]

Dann muß aber vermutlichauf dem Zielkomputer der VLC-player installiert sein?
Ist vielleicht etwas übertrieben, wo die dort auf dem arbeitsrechner eh keine Videos gucken dürfen.


HTTP ging leider nicht
(wäre auch zu Einfach gewesen )

Ist jetzt kein Problem an deiner Komponente, sondern mehr ein kleiner Fehler bei der Verwaltung.

Delphi-Quellcode:

procedure TfrmMain.Button1Click(Sender: TObject);
begin
  FreeAndNil(Client);  // Schließen, wenn schon offen

  Client := TMJPEGClient.Create('192.168.1.10', 80, '/videostream.cgi'); // die URL ist bei vielen Kameras anders, also anpassen!
  Client.OnJPEGReceived := JPEGReceived;
  ...
  Client.Start;
end;

procedure TfrmMain.Button2Click(Sender: TObject);
begin
  FreeAndNil(Client);
end;

procedure TfrmMain.FormDestroy(Sender: TObject);
begin
  FreeAndNil(Client);  // auch wenn du zwar den Thread über das Terminated abbrichst, bleibt die Komponente bestehen und könnte womöglich auch noch nach dem freigeben des Fensters nochmal versuchen drauf zuzugreifen.
end;

Drück einfach mal mehrmals auf Starten (ok, da passiert hier nicht viel, außer daß jetzt mehrere Threads arbeiten),
aber mehrmals auf Stoppen geklickt, wird vermutlich schön knallen (aber mindestens einmal mußte vorher der thread gestartet wurden sein).

[himitsu]

So, bisher gab es noch keine Antwort von TP.
(die Frage nach einem direkt auslesbaren JPEG war wohl zu schwer)

Die letzten Tage hab ich vorallem den Arbeits-Thread nochmal komplett überarbeitet.
- genauer das Übertragungsprotokoll direkt auf die grundsätzliche Motion JPEG-Definition angepaßt
- die Fehlerbehandlung überarbeitet
- ein Logging für den Thread und die übertragenen Daten eingebaut, um die Funktion zu testen und die Daten-/Fehleranalyse bissl zu vereinfachen
- die Error-Events entsprechend angepaßt
- versucht einen FrameLimiter einzubauen, bzw. die FPS mitzuzählen
- und vorallem wurde das ReceiveEvent erweitert
- im Testprogramm wird die Komponente immernoch manuell erstellt, damit die Unit installiert werden muß

Wäre nett, wenn nochjemand das Programm und den Code prüfen könnte, auch mit anderen Webcams.

Nette Test-Webcams hab ich auf www.mjpeg.net entdeckt und aktuell sind ein paar knuffige Vögelchen voreingestellt.