Bild von IP-Webcam auslesen

[Morphie]

Ja, ich hatte alles korrekt eingetragen.
Bekomme aber immer noch 400 Bad Request... Hast du etwas an dem GET geändert?

Ich habe den Traffic mal mit meinem Programm geloggt:

Code:

'HTTP/1.1 200 OK'
'Server: Netwave IP Camera'
'Date: Wed, 02 Oct 2013 11:14:47 GMT'
'Accept-Ranges: bytes'
'Connection: close'
'Content-Type: multipart/x-mixed-replace;boundary=ipcamera'
''
'--ipcamera'
'content-type: image/jpeg'
'content-length: 36352'
''
Binärdaten
''
'--ipcamera'
'content-type: image/jpeg'
'content-length: 36352'
''
Binärdaten
''

[himitsu]

OK, dann ist das StreamFormat zumindestens gleich.


Etwas geändert ja (im OnConnect kann man für den RequestHeader weitere Zeilen mit übergeben), aber da dort nichts gemacht wird, sollte der Header eigentlich gleich bleiben.

Ich geb den Haeder mal mit ans Log aus.

[edit]
Und über eine CheckBox kann man angeben, ob die Header einzeilig (so wie es vorhin noch war) oder zusammenhängend versendet wird.

[Morphie]

Ich habe dir mal eine PN mit den Zugangsdaten zu meiner Cam geschickt, vielleicht kannst du damit besser testen?

[himitsu]

Du wirst es bestimmt nicht glauben, aber deine Kamera versteht auschließlich nur den Windowszeilenumbruch (#13#10).
Die ist einfach nicht mit der Linux-Variante (#10) klargekommen und auch den Mac (#13) mag sie nicht.

Und ich dachte mir so "läßt'e mal die #13 besser weg, nicht daß eine Kamera mal mit Windows nicht klar kommt"

[himitsu]

Sooo,

noch ein bissl Fehlerbehandlung mit rein und versucht die Header mit auszuwerten, dazu vorher jeweils erstmal den kompletten Header einlesen.
Die Header werden auch an die Events mit übergeben, damit dort notfalls drauf reagiert werden könnte.


Wie sieht dein Code denn nun aus?

Ach ja, content-length muß natürlich nicht immer der letzte Headereintrag sein, kurz vor dem DataStream.
Der DataStream fängt aber nach der Leerzeile an, bzw. es fängt abwechselnd, nach der Leerzeile, der Header an.
(da du ja nach dem content-length versuchst das Bild zu laden)


Für dich eventuell besser, wenn du die Events nicht via Synchronize im Hauptthread ausführst.
So könntest du mehrere Threads (je Kamera Einen) parallel laufen lassen, in deinem Service, ohne daß die sich gegenseitig ausbremsen.



Ach ja, das Flackern kommt vom TImage, welches da wohl irgendwelche Problemchen hat.
Im Code zeichne ich daher aktuell das Jpeg auf eine TPaintBox.

Je größer das TImage, um so eher und stärker flackert es.
Mit Self.DoubleBuffered läßt es sich etwas eindämmen.
Das TImage selber hat kein DoubleBuffered, da es sich auf dem Canvas seines Owners zeichnet. Und mit einem TPanel+DoubleBuffered dazwischen war auch nichts zu machen.

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

[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