Bild von IP-Webcam auslesen

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

Das Demoprogramm funktionierte soweit erstmal.
Ich hatte mir nur in die GUI noch ein paar Edits reingemacht, um leichter Testen zu können.
(EXE im Anhang, falls noch wer bei seiner Webcam testen möchte)

Nach einer Weile blieb allerdings das Bild einfach hängen und veränderte sich nicht mehr.
Es gab keine Fehlermeldung und die Form-Caption stand auf Verbunden.
Bei Klick auf Stoppen kam dann aber manchmal die Meldung "Verbindung wurde vom Host getrennt."
(wobei es bei mir zwei verschachtelte RDP-Sitzungen gab, da der Kundenrechner nur von unserem Server aus erreichbar ist, was hier und da einige Problemchen verursacht)

Und Stretch macht sich mit Proportional zusammen auch nicht schlecht.


Der TThread ist jetzt noch nicht raus, aber so sieht man erstmal die Unterschiede direkter.
- die winzigen zu synchronisierenden Prozeduren als anonyme Methoden angelegt (aus 2-3 Funktioen wurde jeweils nur noch Eine)
- die globelan Klassenvariablen entfernt, welche eh nur für die Synchronisierung verwendet wurden
- FormatMessage+FORMAT_MESSAGE_FROM_SYSTEM durch SysErrorMessage ersetzt
- Klassenintern auch auf die internen Variablen gegangen, anstatt über die öffentlichen Property
(da wo es intern nur an der einen Stelle Zugriffe gibt ... so könnte man später auch Getter und Setter verbauen, um externe Zugriffe zu verarbeiten)

[Morphie]

Hmmm irgendwie flackert das Bild jetzt aber... Ist das bei dir nicht so?

btw: Das mit den anonymen Methoden kannte ich noch nicht, das finde ich echt nett

edit: das Flackern liegt am "proportional = true"
außerdem:

Delphi-Quellcode:

procedure TMJPEGClient.Execute;
...
          JPEGStream := TStream.Create;
...
              JPEGStream.Position := 0;
...
end;

Das erzeugt unter XE4 einen Fehler.
Der setter von Position ruft intern Seek auf. Und dort steht:

Zitat:

No existing TStream classes should call this method, since it was originally abstract.

Daher:

Delphi-Quellcode:

procedure TMJPEGClient.Execute;
...
          JPEGStream := TMemoryStream.Create;
...
end;

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