Ankündigung

Einklappen
Keine Ankündigung bisher.

cam2web und Edomi

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    cam2web und Edomi

    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
    Code:
    QUEUE: 1 Queueeinträge entfernt (Laufzeit >600s)
    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
    Code:
    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]
    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:

    Code:
    {
        status: "OK",
        config: {
            device: "2M WebCam",
            height: "600",
            title: "2M WebCam",
            width: "800"
        }
    }
    Any ideas? Was soll ich wie testen?
    Kind regards,
    Yves

    #2
    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?
    Code:
    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...
    Zuletzt geändert von gaert; 17.04.2018, 07:21.
    EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

    Kommentar


      #3
      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:
      Code:
      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:
      Code:
      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:
      Code:
      data:image/jpeg;charset=utf-8;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8...
      Kannst Du damit etwas anfangen?
      Kind regards,
      Yves

      Kommentar


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

        Request:
        Code:
        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:
        Code:
        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
        Kind regards,
        Yves

        Kommentar


          #5
          "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.
          EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

          Kommentar


            #6
            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.

            Kommentar


              #7
              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.
              Grüße
              Matze

              Kommentar


                #8
                Zitat von fisch3009 Beitrag anzeigen
                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.

                Kommentar


                  #9
                  Ja: https://github.com/OliverF/mjpeg-relay
                  Wurde hier aber auch schon erwähnt.
                  Grüße
                  Matze

                  Kommentar

                  Lädt...
                  X