Bild von IP-Webcam auslesen

[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).

[Morphie]

Ja, das ist mir auch aufgefallen... Da das aber ein Beispiel ist, war mir das egal, es ging ja um die Klasse TMJPEGClient

edit: wenn man die Klasse dann noch in eine Komponente gießt, kann man die Verwaltung dort ja sauberer gestalten...

[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.

[Morphie]

Zitat von himitsu:

So, bisher gab es noch keine Antwort von TP.

Sorry, ich habe das Projekt erst mal eingefroren, da ich mich zur Zeit beruflich neu orientiere... Sobald ich wieder viel Freizeit habe, führe ich die Sache aber weiter...

Zitat von himitsu:

(die Frage nach einem direkt auslesbaren JPEG war wohl zu schwer)

??? Habe ich da etwas übersehen? Was meinst du?

Zitat von himitsu:

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

Mit meinen Webcams läuft das Testprogramm ohne Probleme.
Der Framerate-Limiter funktioniert auch.