HTML5 Video funktioniert nicht via HTTPS

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.

2 Likes

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

Schon klar und verstehe ich ja auch.

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.

…„Der Browser wird von der WebUI vielleicht falsch erkannt und der Stream fällt automatisch immer auf MJPEG zurück.“ …

genau so ist es: in Firefox und Chrome liest man im Inspector (obwohl Webgui auf HTML5-Video gestellt ist) folgendes:

"<img id="activeVideo" mode="mjpeg" class="img-responsive" src="http://192.168.178.113:80/mjpegstream.cgi?-chn=11&amp;usr=....."

Da müsste man mal schauen was die WebUI denkt was der Browser ist in dem sie läuft:

Einfach mal das in der Console eingeben und den Screenshot hier posten:

instar.system

Das sollte so aussehen:

FIREFOX:

activeX: false
browser: „Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:77.0) Gecko/20100101 Firefox/77.0“
chrome: false
edgc: false
edge: false
ff32bit: false
firefox: true
ie: false
ipad: false
iphone: false
ipod: false
linux: false
mac: true
mobile: false
opera: false
os: „MacIntel“
safari: false

scripts: Object { }
win: false
win7: false

: Object { … }

CHROME:
browser: „Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) Ap…L, like Gecko) Chrome/83.0.4103.116 Safari/537.36“, os: „MacIntel“, win: false, win7: false, mac: true, …}activeX: falsebrowser: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36"chrome: trueedgc: falseedge: falseff32bit: falsefirefox: falseie: falseipad: falseiphone: falseipod: falselinux: falsemac: truemobile: falseopera: falseos: "MacIntel"safari: falsesafari9: falsesafariDl: falsescripts: {}win: falsewin7: false__proto__: Object

Und das kommt beim Zugriff über HTTP nicht HTTPS ?

Und der Kollege erwähnt gerade noch - eventuell einmal den Browser Cache leeren. Da könnten noch Infos gespeichert sein von der v2.5 WebUI.

über HTTP. Bei HTTPS-Zugriff (alles im lokalen Netzwerk) kommt folgendes:

activeX: false
browser: „Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:77.0) Gecko/20100101 Firefox/77.0“
chrome: false
edgc: false
edge: false
ff32bit: false
firefox: true
ie: false
ipad: false
iphone: false
ipod: false
linux: false
mac: true
mobile: false
opera: false
os: „MacIntel“
safari: false
scripts: Object { }
win: false
win7: false

​ Cache wurde gelöscht, gleiches Ergebnis im Inspector.

:point_up_2:t2: 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.

leider nein, kein Effekt.

Und noch ein paar Eindrücke aus dem selben Netzwerk unter Windows 10/ Firefox:
mit https funktioniert der HTML5-Stream, sowohl in Default- als auch in HD-Auflösung
dafür sieht man mit http nichts, es erscheint ein zerbrochenes Bild-Icon im Videofenster.

Ich würde noch als sinnvoll erachten, wenn der Button „H.264“ unter dem Video deaktiviert/durchgestrichen und auch den aktuelle Status entsprechend der Realität anzeigt werden würde, falls der HTML5-Stream (ebenso Flash) aktuell aufgrund von Einschränkungen des Browsers oder wegen HTTPS statt HTTP nicht benutzt wird. Das wäre für zukünftige Updates eine Anregung. Denn derzeit weiß man nicht wirklich was man aktuell hat.

2 Likes

Steht bereits auf der Liste :ok_hand:t2:

Dann ist es kein HTML5 sondern der MJPEG Stream. Mit HTTPS gibt es keinen echten H.264-Videostream.

das stimmt. was müsste denn im Inspector stehen, wenn es ein HTML5-Stream wäre?

HTML5 Video

html5

MJPEG Video

MJPEG