HTML5 Video funktioniert nicht via HTTPS

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 „Gefällt mir“

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 „Gefällt mir“

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.

GELÖST. Kamera zurückgesetzt, Flash gelöscht. Nun kommt in Schalterstellung H264 der korrekte HTML5-Stream an:

<canvas id="activeVideo" mode="html5" width="1920" height="1080" style="width:100%"></canvas>

Wer weiß, was da war. Danke allen für die schnelle Hilfe und die damit verbundenen Einblicke… :slight_smile:

2 „Gefällt mir“

Ich habe eure Diskussion hier mal wortlos verfolgt, da ich zwar die gleichen Schwierigkeiten hatte, aber nicht die technischen Kenntnisse besitze, wie ihr sie habt. Habe nun die Videoeinstellung auf HTML5 geändert, die Kamera neu gestartet , nun wird mir auch mode html 5 im Quelltext angezeigt und das Bild ruckelt nicht mehr. Natürlich nur über den HTTP Port, ansonsten JPEG. Wenn ich jetzt noch den Vollbild Modus hätte, wäre ich wunschlos glücklich. :slightly_smiling_face:
Herzlichen Dank an alle und einen schönen Tag.

@m.polinowski: Nach dem Studium Eures Javascript: Warum benutzt Ihr für den H.264 Stream ein in WASM geschriebenes ffmpeg? Das erklärt die hohe CPU-Auslastung, da der Videostream mit Javascript (!!!) dekodiert wird. Kann man nicht den in modernen Browsern vorhandenen H.264-Decoder benutzen und nur als Fallback den in Javascript geschriebenen? Ich weiss, manche Browser liefern das Codec nicht mit, aber man könnte es doch benutzen, falls vorhanden.

Für h.264 ja. Für den Audio Codec nein. Die Browser Hersteller haben sich da für Codecs entschieden ohne die Hardware Hersteller zu konsultieren. Selbst die ganz neuen IP Kamera Chipsätze, in dieser Preisklasse, unterstützen nicht das was sich die Browser da ausgedacht haben. Das ist ja der Grund weshalb Flash immer noch eine gute Lösung ist für die meiste aktuelle Hardware - das funktioniert einfach.

Web Assembly erlaubt es uns das externe Plugin durch etwas browser-natives zu ersetzen. Die Alternative ist, das Video über eine Cloud Platform laufen zu lassen und dort browser-konform zu machen.

Für zukünftige Chipsätze wird das dann hoffentlich nicht mehr notwendig sein.

Schade! Geht dann wohl auch nicht ohne Ton? Den habe ich normal nicht an, da ja „abhören“ in Deutschland im Freien eh … ähm… unzulässig ist.

Mit der ganzen Arbeit die du da reinsteckst, würde ich dir den Griff zum Smarthome empfehlen. In Node-RED hat man die Kamera schnell über MQTT eingebunden. Mit etwas Erfahrung bekommt man da auch FFMPEG ans Laufen und kann dann seinen eigenen Stream erzeugen, ins Dashboard einbinden und dass dann hinter den Proxy legen - anstatt die Kamera UI direkt freizugeben.

1 „Gefällt mir“

Node-RED steht eh auf dem Plan.

Das mit dem Webassembly und ffmpeg war eher die Frage für die anderen Kunden die sich schon über die CPU-Auslastung des HTML5-Streams beschweren.

Die Analyse des Javascripts war eher Wissensbegierde :slight_smile:

Dank in jedem Fall.

1 „Gefällt mir“

… ich muss mal unabhängig vom konkreten Problem sagen: große Klasse für die schnelle und vor allem sachkundige Korrespondenz in diesem Forum. Das kann man normalerweise nicht erwarten; da steht wohl auch viel Expertise und „Kundendienst“ dahinter. Hat man selten, kenne kein anderes aktuelles Beispiel.
Ich komme auch aus der Softwareentwicklung (allerdings Backend/J2EE, daher meine unqualifizierten Beiträge bzgl. „Webzeuch“):
so eine konkrete und zeitnahe Problemanalyse hätte ich mir in so manchem Projekt gewünscht… Danke.

3 „Gefällt mir“

:upside_down_face: :slightly_smiling_face:

1 „Gefällt mir“