Bild von IP-Webcam auslesen

[himitsu]

Zitat von 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...

Keine Sorge, ich meinte TP-Link, den Hersteller der Webcam, von Welchem bisher noch keine Antwort eingetroffen ist.

[himitsu]

So, ich denk das war's jetzt erstmal.
Bis au eine Kleinigkeit (der Canvas) läuft es jetzt stabil.



Erstmal wurde eine kleine Version abgesplittet, welche einen Minimalcode enthält.

Die große Version enthält mehr Events und Einstellungsmöglichkeiten.
- diese kann aber über Compilerschalter eingeschränkt werden, z.B. indem man die VCL-Zugriffe entfernt
- es kann auf die Übertragenen Daten zugeriffen werden, z.B. zum Loggen oder für die Implementation einer Verschlüsselung
- der gesendete Anfrage-Header kann angepasst werden, z.B. für die Verschlüsselung und wenn es dort Probleme gibt
- man kann einen Canvas direkt anhängen, wo die Komponente das Bild draufzeichnet

Es sollte eigentlich für jedes Bedürfnis ein passendes Event/Property bereitstehen.
Ob und wie ich da aber noch Proxy reinbekomm, muß ich mal sehn. (sobald das direkt mit dem TTCPClient läßt es sich leicht nachrüsten)

Sehr unpraktisch ist, daß der TTCPClient in den Schleifen kein Timeout hat.
Mir war aufgefallen, daß eine Kamera manchmal einfach hängen blieb. (Connection blieb offen, aber es sind keine Daten mehr reingekommen)
So blieb meine Datenleseschleife hängen, bei "0 byte gelesen" im ReceiveBuf und landete in einer Endlosschleife. (das hab ich erstmal nicht über ein Timeout gelöst, aber dafür wird dort nun auf das "Stop" gehört)
[edit] in der MJpegClientSmall.pas fehlt dieser Bugfix noch (ist dann im nächsten Upload drin)
Aber im TTCPClient.ReceiveLn ist diese Endlosschleife dennoch drin.

Die Testprogramme sollte ich wohl auch langsam mal in Demo umbenennen.



Nun aber nochmal zum Canvas.
Die "Selbstzeichenfunktion", siehe MJpegTest_Canvas.dproj, gefällt mir noch nicht so richtig.
Vielleicht hat da jemand einen guten Vorschlag?

Ich hätte dort TGraphic als Property nehmen können, dann würde man ganz leicht auf TImage/TPicture/TJPEGImage zugreigen können.
Aber die TPaintBox hat ja kein TGraphic-Property.
So kann zwar überall draufgezeichnet werden, aber die Komponente kann die Bildgröße von den TImage/TPicture/TJPEGImage nicht automtisch anpassen.

Es kann aber auch nicht die Bildausgabe automatisch an die Zeichenfläsche angepasst werten => stretch
Und sowas http://www.delphipraxis.net/18336-gr...ermitteln.html geht ja leider nicht.

Nja, via OnDataReceived oder OnImageReceived kann man die Bilder immernoch manuell an alles übergeben.



In Punkto FrameLimiter hatte ich auch noch keine schöne Lösung.
Man kann zwar die Anzahl der angezeigten Bilder (FPS) begrenzen, indem man ein Sleep einbaut und somit die ausgabe verzögert.
Einige Cameras brechen die Verbindung ab, wenn der Sendepuffer voll ist und Andere legen nur eine Pause ein.
- nur sind dann dabei die Bilder verzögert => z.B. bei 0.1 FPS sind die Bilder um mindestens 10-20 Sekunden verzögert, wenn die Kamera ein Bild pro Sekunde ausliefert.

Die andere Lösung war, wenn man zwar alles schnell runterläd, aber z.B. via OnPreReceived die "unnötigen" Bilder überspringt.

[ramboni]

Hallo,

ist es möglich im Falle eines falschen Request, statt den Fehlercode "-9" den
jeweiligen Fehlercode zurück zu bekommen? Sprich z.B.: 401, 404 oder 400?

Oder geht das schon und ich bin nur zu doof?

LG

[himitsu]

Du bekommst im OnError (ErrorMessage) und vorher auch nochmal im OnConnected (ReceivedHeader) den HTTP-Header geliefert, wo du diesen Statuscode auslesen kannst.

Falls ich mich jetzt nicht vertan hab, sähe 'ne Billigvariante für OnError mit ErrorCode=TMJpegClient.eFAILURE so aus:

Delphi-Quellcode:

i := Pos(sLineBreak, ErrorMessage);  // bzw. 'HTTP/' statt sLineBreak
i := PosEx(' ', ErrorMessage, i);
StatusCode := Copy(ErrorMessage, i + 1, 3);

StatusCode := Copy(ErrorMessage, PosEx(' ', ErrorMessage, Pos(sLineBreak, ErrorMessage)) + 1, 3);

Ab der zweiten Zeile fängt der Header an und da steht immer in der 1. Zeile der Statuscode.
HTTP/1.1 200 OK (HTTP-Version Leerzeichen StatusCode Leerzeichen StatusTextBisZeilenende)



Bestimmt wäre es möglich diese Fehlernachrichten direkt als TStrings anstatt String an diese Events zu übergeben, dann wäre Auswerten etwas einfacher.
[edit]
Als TStrings hätte es denn Vorteil, daß der RequestHeader immer an der selben Stelle (Index) anfangen könnte, da einzeilne Zeilen Strings auch Zeilenumbrüche enthalten können.

[ramboni]

Bei
.Connected(Sender: TObject; ReceivedHeader: TStrings);

bekomme ich mit ReceivedHeader.Text in der ersten Zeile: HTTP/1.1 401 Unauthorized
Was super ist.

Allerdings bekomme ich bei
.Error(Sender: TObject; ErrorCode: HRESULT; ErrorMessage: string);

<HTML><HEAD><TITLE>401 Unauthorized</TITLE></HEAD>
<BODY BGCOLOR="#cc9999"><H4>401 Unauthorized</H4>
Authorization required.
</BODY></HTML>


Das sieht irgendwie nicht nach einem Header aus, oder?
Hier wäre "HTTP/1.1 401 Unauthorized" cool
Oder muss da was von HTML stehen?

LG

[himitsu]

Joar, gerade bei der einen ErrorMessage war kein Header dabei, obwohl es Einen gibt.

NWar nur der Fehlertext, den der Server ausgibt, der natürlich sonstwie aussehen kann ... angefangen bei einem einfachen Text, wo "401 Unauthorized" steht, bis zu einer mehr oder weniger aufwändigen HTML-Seite.
(der Witz ist, jetzt wenn ich drüber nachdenke, dann hatte ich an der Stelle den Header auch noch absichtlich weggelassen )

Delphi-Quellcode:

if ErrorMessage.Length > 2 then
  StatusCode := StrToInt(Copy(ErrorMessage[2], Pos(' ', ErrorMessage[2]) + 1, 3));

[edit]
Anhang nochmal ausgetauscht (09:30 17:22)

[himitsu]

Ich kopiere das mal für Alle hier mit rein.

Zitat von ramboni:

Gibt es ein Event wenn der Benutzername/Passwort falsch sind
bzw. wie kann ich soetwas feststellen?

Ein direktes Event dafür gibt es nicht,
aber da die Kamera in diesem Fall die Verbindung verweigern sollte, kommt natürlich bei OnError eine entsprechende Meldung an,
jenachdem wie der Server in der Kamera darauf reagiert und was/ob er dann zurückgibt.

Zitat von ramboni:

Ich habe eine relativ hohe CPU-Auslastung wenn ich beide Kameras aktiviert habe
bzw. den Stream ca. 5x gleichzeitig öffne. Mach ich da was falsch? Ich habe die Ausgabe
auf einem Image.

Das Dekodieren und Anzeigen der Bilder braucht halt ein bissl Rechenleistung.

Man könnte die Streamverarbeitung ausbremsen, indem man z.B. ein Sleep nach jedem Bild einfügt.
z.B. siehe Max FPS in MJpegTest_OnImage, MJpegTest_OnData

Aber einige Kameras scheinen das nicht ganz zu mögen und trennen irgendwann die Verbindung (womöglich Überlauf des Sendepuffers).
Bzw. dabei könnte das Video mehr oder weniger verzögert sein.

Man kann auch versuchen die Bearbeitung der Bilder anders zu lösen.
- Also bei OnDataReceived einsteigen und den Stream in eine andere/schnellere JPEG-Komponente einlesen.
- Und/oder die Ausgabe/Darstellung anders lösen?

Oder man könnte über OnPreReceived dafür sorgen, das garnicht erst alle empfangenen Bilder verarbeitet werden.
Result := (GetTickCount - ReceiveStart) >= 1000; = überspringe das Bild, wenn das letzte Bild vor weniger als einer Sekunde angezeigt wurde.
Damit würde der Datenstrom zur Kamera nicht beeinflusst.
Man kann ja gern versuchen da auch nochmal ein kleines Sleep reinzumachen, um zusätzlich nochmal den Traffic zu beschränken.

Zitat von ramboni:

Du schreibst in deinem Text: " gesendete Anfrage-Header kann angepasst werden"
Kannst du mir sagen wie das geht? Verschlüsselung hört sich interessant an

Die einfachste Verschlüsselung ginge via HTTPS. (in wie weit und ob das jetzt schon möglich ist, weiß ich aber noch nicht)

In OnConnecting kannst du den RequestHeader bearbeiten, bevor er zur Kamera gesendet wird.
Da könnte man z.B. eine Komprimierung oder eben Verschlüsselung aktivieren, indem man die passenden Werte im Header übergibt.

Es kommt aber alles darauf an, was die Kamera für Funktionen anbietet, denn die muß da ja mitmachen.

Und über OnReceiveDebug kommt man an TTCPClient.OnReceive und TTCPClient.OnSend ran, wo man dann die empfangenen/gesendeten Daten komprimieren/dekomprimieren/verschlüsseln/entschlüsseln.