cam2web und Edomi

[starwarsfan]

Hallo @gaert,

als ich ein wenig mit der Webcam des PEAKnx ControlPro und Edomi herumgespielt habe, bin ich über zwei Probleme gestolpert.

Ich verwende cam2web, um einen Stream der Kamera zu erzeugen. Dabei sind via http://iport/camera/mjpeg der MJPEG-Stream sowie via http://iport/camera/jpeg Standbilder verfügbar. Das funktioniert problemlos gleichzeitig mit mehreren Browsern. Daraufhin habe ich in Edomi eine Kamera angelegt, welche den MJPEG-Stream verwendet. Den Stream in der Visu anzuzeigen funktioniert wunderbar.

Wenn ich allerdings Snapshots archivieren möchte, gibt es zwei Probleme. Bei einer Edomi-Cam mit dem JPEG-Standbild, Typ JPG und klick auf Vorschau, dunkelt sich die Konfig-Page ab und der grüne Kringel dreht sich ewig. Nach zehn Minuten habe ich dann den Fehler

[I]QUEUE: 1 Queueeinträge entfernt (Laufzeit >600s)[/I]

im Log. Wenn ich die Kamera anlege und ohne Vorschau speichere, dann habe ich zehn Minuten nachdem ich einen Snapshot archivieren wollte, ebenfalls diesen Fehler im Log.

Daraufhin habe ich für die Archivierung den MJPEG-Stream verwendet. Wenn ich damit einen Snapshot archiviere, gibt es den Fehler

[I]Datei: /var/edomi-backups/_public/main/queuecmd/cmd120.php | Fehlercode: 8 | Zeile: 83 | imagecreatefromstring(): gd-jpeg, libjpeg: recoverable error: Premature end of JPEG file[LF][/I]

im Log. Der Screenshot wird aber korrekt archiviert und ich kann ihn mir im Kameraarchiv ansehen.

Haben diese beiden Probleme etwas miteinander zu tun und wie komme ich dem genauer auf die Spur? Das cam2web-Projekt scheint gepflegt zu sein. Wenn also am Stream oder Snapshot etwas krumm ist, würde ich dort gerne einen Bugreport aufmachen. Die Infos zur Cam spucken das hier beim Aufruf von http://iport/camera/info aus:

{
    status: "OK",
    config: {
        device: "2M WebCam",
        height: "600",
        title: "2M WebCam",
        width: "800"
    }
}

Any ideas? Was soll ich wie testen?

[gaert]

MJPEG ist etwas "tricky" - es gibt keine echten Standard bzw. diverse Verfahren. EDOMI erwartet im "Header" (MIME) eine Angabe "boundary=...", dies ist quasi eine Zeichensequenz zur Trennung der Einzelbilder. Wenn dieser Parameter fehlt weiß die Funktion nicht, wo ein Bild aufhört und das nächste beginnt. Zudem müssen die JPGs immer mit (hex)ffd8 beginnen, so sieht es der Standard vor.

Viel mehr kann ich dazu leider auch nicht sagen - ich habe damals etliche Streams (aus'm Internet) getestet und (fast) keine Probleme feststellen können. Nur einige wenige Streams wollten nicht so recht, warum weiß ich nicht. Im Browser (also auch in der Visu) funktionierte es hingegen immer - offenbar sind die Browserprogrammierer schlauer?!

EDIT:
Sieht der Header z.B. so aus?

HTTP/1.0 200 OK
Connection: close
Server: MJPG-Streamer/0.2
Cache-Control: no-store, no-cache, must-revalidate, pre-check=0, post-check=0, max-age=0
Pragma: no-cache
Content-Type: multipart/x-mixed-replace;boundary===MJPEGIMAGEBOUNDARY==

EDIT2:
Ich werde mal testweise den Subheader (den Headers jedes JPGs) auswerten bzw. zumindest auf 2xCR/LF warten, statt auf die JPG-Startbytes zu lauschen. Klappt mit diversen Internet-Streams bislang perfekt (die aktuelle Variante allerdings auch).

Beim nächsten Update werde ich diese Version dann mal implementieren - hoffentlich gibt's dann keine Probleme bei anderen Nutzern...

[starwarsfan]

N'abend gaert

Danke für die Infos. Wenn ich die JPEG-URL im Chrome aufrufe und mir die Header in den DevTools anzeigen lasse, dann sieht das so aus:

Request-Header:

GET /camera/jpeg HTTP/1.1
Host: controlpro:8000
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: de-CH,de-DE;q=0.9,de;q=0.8,en-US;q=0.7,en;q=0.6

Respone-Header:

HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 55163
Cache-Control: no-store, must-revalidate
Pragma: no-cache
Expires: 0

Der Anfang der Respone selbst sieht so aus:

data:image/jpeg;charset=utf-8;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8...

Kannst Du damit etwas anfangen?

[starwarsfan]

Hier das Ganze noch für die MJPEG-URL.

Request:

GET /camera/mjpeg HTTP/1.1
Host: controlpro:8000
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: de-CH,de-DE;q=0.9,de;q=0.8,en-US;q=0.7,en;q=0.6

Response:

HTTP/1.1 200 OK
Cache-Control: no-store, must-revalidate
Pragma: no-cache
Expires: 0
Connection: close
Content-Type: multipart/x-mixed-replace; boundary=--myboundary

[gaert]

"boundary" passt soweit - dann liegt's vermutlich an der JPEG-Erkennung (s.o.). Inzwischen habe ich dies ja wie gesagt abgeändert: Vor jedem JPG wird ein Subheader eingefügt (laut "Norm") und dieser endet angeblich immer mit zwei LFs oder auch 13/10/13/10. Wir werden sehen...

Wie gesagt: MJEPG ist etwas merkwürdig - es existiert irgendwie keine exakte Spezifikation im Netz. Klar, es sind JPEGs die durch "boundary" getrennt werden. Aber zu jedem Einzelbild gibt es (i.d.R.) noch eine Header mit der Länge etc. - aber eben nicht immer.

[blaky]

Dann freuen wir uns auf das Update. Die Hikvision Gemeinde wird dir danken.. da machen die Mjpegs in Edomi zicken während sie im Browser laufen.

[fisch3009]

auch wenn es Offtopic ist: Meine Hikvision (DS-2CD2032-I ) macht mit Edomi nur zicken, weil sie nur einen MJPG Stream liefert und Edomi unter umständen (Vorschau, Visu, Einzelbild speichern) mal mehr braucht. Bei mir läuft das über ein MJPG Relay (ein Python Skript) und seitdem zickt das mit Edomi auch kein Stück mehr.

[Andreas1]

Bei mir läuft das über ein MJPG Relay (ein Python Skript) und seitdem zickt das mit Edomi auch kein Stück mehr.

Hast du dazu einen Link?
Das dürfte auch die User mit Dahua-Kameras interessieren. Diese können zwar mehrere MJPG-Streams gleichzeitig, setzen aber Digest-Auth voraus, was Edomi nicht kann.

[fisch3009]

Ja: https://github.com/OliverF/mjpeg-relay
Wurde hier aber auch schon erwähnt.