Hallo,
ich habe heute früh das Update auf WebUI 2.6 gemacht. Allerdings ist mir folgendes aufgefallen:
Wenn ich die Kamera direkt über den HTTP-Port (80) zugreife und auf HTML5-Video umgestellt habe, wird alles in FullHD angezeigt und das als Stream. Im Chrome Netwerkviewer sieht man keine sekündlichen MJPEG Downloads sondern ein einen HTML5-Stream.
Wenn ich mich direkt mit der Kamera via HTTPS (Port 443) verbinde, erzeugt das Webinterface nur einen Kanvas und läd jede Sekunde ein niedrig aufgelöstes MJPEG Bildchen. Der Schalter H.264 hat keinen Einfluss, egal ob an oder aus werden jede Sekunde ein niedrig aufgelöstes MJPEG geholt.
Normalerweise greife ich auf die Kamera über einen Apache2-Webserver mit HTTP/2, der die Verschlüsselung mit eigenen Zertifikat durchführt und als Reverse Proxy die Kamera hinter der Firewall per HTTP (Port 80) zugreift - also der klassische Aufbau (zum Internet HTTPS mit Reverse Proxy zur lokalen Kamera unverschlüsselt). Auch in dieser Variante wird der Stream nicht in FullHD via HTML5 dargestelt. Weiterhin nur ein Canvas Element und alle Sekunde ein niedrig aufgelöstes Bild.
Ich habe das Javascrkipt analysiert, anscheinend schaltet das WebUI bei Erkennung von HTTPS das H264 ab, was aber vor allem dann keinen Sinn macht, wenn die Kamera hinter einem Reverse Proxy steht! Außerdem ist die Anzeige sehr komisch, denn der H264-Schalter unten tut nicht das was er soll.
Sollte hier von INSTAR keiner eine Lösung haben, auch über HTTPS (via Reverse Proxy) den Stream als HTML5-Video zu bekommen, werde ich ein Support-Ticket aufmachen.
Ich sehe ein, dass die Kamera evtl mit HTTPS überfordert ist auch das Video in FullHD zu senden, aber das tut sie hier ja nicht. Die Verschlüsselung macht der Webserver im Router (Intel Core i7) - und der kann sogar HTTP/2, was die WebUI aus dem Internet richtig schnell macht (multiplexing).
Wie an anderer Stelle bereits geschrieben, habe ich das Problem auch. Ich kann den Livestream nur über den Http Port in einer sehr guten Qualität darstellen. Sobald ich auf den HTTPS Port gehe ist die Bildqualität sehr schlecht. Vollbildmodus funktioniert bei mir leider auch nicht mehr.
Allerdings wurde mir das Update auch nur über den HTTP Port angezeigt. Über den von mir bevorzugt benutzten HTTPS Port wurde mir kein Update vorgeschlagen. Vielleicht wurde das sogar bewusst so gesteuert, da das Problem bekannt ist. Keine Ahnung, hoffe aber mal, dass das noch gelöst wird.
Der HTML5 Videostream wird über einen Websocket bereitgestellt, der nur unter HTTP zur Verfügung steht. D.h. wenn die WebUI erkennt das man über HTTPS zugreift, fällt sie zurück auf den MJPEG Stream. Aufgrund der recht hohen Bandbreitenanforderungen wird dieser standardmäßig in der mittleren Auflösung geladen.
Man kann ihn jedoch über das Dev Menü auf die hohe Auflösung stellen (Achtung diese Einstellungen werden nicht auf der Kamera, sondern per Cookie gespeichert. Es muß also bei jedem Browser geändert werden).
Um zum Dev Menü zu gelangen, muß man das System/Logbuch Menü öffnen und dort die drei Tasten d, e und v gleichzeitig gedrückt halten. Beim Loslassen lädt dann das Menü.
Dankesehr, das hilt schon sehr, da man dann zumindest Ansatzweise ein scharfes Bild bekommt.
Ich werde mal sehen, ob ich über den Reverse Proxy vor dem unverschlüsselten Kamera-HTTP-Port nicht das Websocket zum Laufen bekomme. Das Javascript werde ich durch den Apache (evtl auch NGINX) umschreiben lassen. Ich werde hier die Ergebnisse Posten, falls jemand anderes auch den Websocket im Reverse-Proxy aktivieren will.
… unabhängig von http oder https, direktem Zugriff oder via Portforwarding von außen ruckelt der Stream im HTML5-Modus im Sekundentakt. Im Flashmodus ist es in jeder Zugriffsart fliessend.
Wird das noch gefixt? Wäre fein…
Wie gesagt, der HTML5 Stream steht nur über HTTP zur Verfügung. Sobald man per HTTPS zugreift schaltet die WebUI auf MJPEG. Da der sehr viel Platz in der Leitung braucht kann es durchaus ruckeln.
Wenn der HTML5 Stream ruckelt wird es vermutlich eher an der CPU Auslastung des Rechners liegen. Gerade auf alten PCs oder schwachen Mobilgeräten kann der Prozessor gut ausgelastet werden.
Dem ist so!
Daher nutze ich den Webbrowser nur zur Konfiguration der Kamera und solange Flash
noch läuft eben auch mal das Livebild per Webbrowser
Und wofür gibt es die InstarVision Apps für Smartphone und Windows PC.
Es ist ja gut zu wissen, wofür Du den Browser benutzt, aber andere möchten das vielleicht anders handhaben , nutzen den Browser nicht nur zur Konfiguration und möchten das Livebild halt am PC und nicht über das Smartphone sehen. Da hilft die Instar Vision App für Windows nur bedingt, wenn man ein anderes Betriebssystem hat.
Danke für die Antwort - CPU-Auslastung ist unabhängig vom Modus bzw. Browser minimal (macMini 2014, macbook air 2020) - ehrlich gesagt, sehe ich auch keinerlei Unterschiede in der Darstellung zwischen HTML5-Stream und MJPEG (habe via DEV-Menü auf HD umgestellt). Es läuft beides abgehackt.
Das nur für die evtl. Analyse, mich störts nicht allzusehr.
Die Darstellung sollte gleich gut sein - sobald man den MJPEG Stream auf Full HD gestellt hat.
Allerdings sollte der HTML5 Stream einiges mehr an CPU benötigen. Der MJPEG Stream hingegen sehr viel mehr Bandbreite.
Der HTML5 Stream ruckelt auf meinem Android Tablet auch sehr stark - CPU limitiert. Auf einem halbwegs aktuellen Core i7 Desktop hingegen läuft er sogar besser als der Flash Stream.
Wenn der Stream überall ruckelt und die CPU Auslastung im grünen Bereich ist, würde ich eher sagen, dass der HMTL5 Stream gar nicht aktiviert wird. Man kann es eventuell mal mit einem anderen Browser probieren. Der Browser wird von der WebUI vielleicht falsch erkannt und der Stream fällt automatisch immer auf MJPEG zurück.
Die Leistung der Browser unterscheidet sich auch. Mit Safari (und macOS) habe ich keine Erfahrung. Aber speziell unter Linux habe ich gemerkt das z.B. Firefox um einiges besser läuft als Chrome.
hat das einen Effekt? Cache leeren und ggf. den HTML5 Stream noch mal neu auswählen - also in den Videoeinstellungen auf z.B. Flash stellen, speichern und noch mal zurück auf HTML5.