HTML5 Video funktioniert nicht via HTTPS

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

ok, dann hab ich das Inspektorergebnis unter W10 falsch gedeutet, da stand was mit mode=„jpeg“ und keine URL dahinter… was daran lag, dass der MJPEG-Modus in den Einstellungen auf JPEG stand.
Also Update: es geht auch auf W10 nicht im HTML5-Modus, damit scheint es wohl kein Mac-Problem zu sein.

Nach dem was die WebUI da sagt scheint sie das System richtig zu erkennen und sollte - solange man über HTTP zugreift - den HTML5 Stream nehmen.

Da müssten die Kollegen mal per Fernwartung drüberschauen - irgendwas ist da merkwürdig.

Hallo Mike,

Ist es eigentlich gewollt, dass mit HTTPS auch kein MJPEG stream kommt, sondern der WebUI auf JPEG schaltet? Bei mir steht im canvas mode=„jpeg“ (und alle sekunde zwei HTTP requests zur Kamera auf den „snap.jpeg“). Sobald ich auf HTTP schalte und kommt „html5“ (mit H.264) und „mjpeg“ (ohne) - hier nur ein stream auf das CGI.

Den MJPEG Stream kann man in den Video Einstellungen von MJPEG auf pseudo-MJPEG (also JPG) umstellen. Die Firmware stellt uns nur letzteren über HTTPS zur Verfügung. Ich kann momentan nicht mehr sagen was da genau die Begründung war - aber es hatte einen Vorteil.

1 Like

Danke. Das ist wieder das initial gemeinte Problem: HTTPS wird bei mir durch den Reverse Proxy zur Verfügung gestellt. Den MJPEG Stream gibt es bei mir also auch über HTTPS (weil die Kamera mit dem userfacing Webserver nur HTTP spricht und damit alles bereitstellt).

Wäre schön wenn die HTTPS-Einschränkungen im Javascript via Setting „überschrieben“ werden könnten. Mir ist schon klar dass die Kamera etwas schwachbrüstig ist um noch Verschlüsselung zu machen, daher hat man für sowas ja Reverse Proxies.

Eventuell wäre es besser, wenn das Javascript von der Kamera nachfragt „was kannst du denn alles“, egal ob HTTP oder HTTPS.