Bug in multimedia.image Widget

[smai]

Ausser es gibt einen Access-Control-Allow-Origin Header.
So ein Pseudo-Proxy ist natürlich eine Möglichkeit, alternativ kann auch ein echter Proxy eingesetzt werden.

[bruepe]

Danke. Leider bin ich nicht in der Lage das so in das vorhandene script einzubauen dass es läuft.

[psilo]

smai das müsste er sich aber doch relativ einfach dazubauen können... oder ggf als feature request in der 2.9 konfigurierbar machen?

[bruepe]

Ich kenne mich mit Java leider nicht wirklich aus. Also könnte ich es nicht selber basteln.
Ich habe vorher mit dem Support telefoniert. Die checken mal, was es für andere Möglichkeiten gibt.
Allerdings muss der Support erst mit der Entwicklung Rücksprache nehmen.

Edit:

Laut Support gibt es leider nur folgende Streams:
rtsp://IP:554/11 (main stream)
rtsp://IP:554/12 (minor stream)
rtsp://IP:554/13 (mobile phone stream)
http://IP:PORT/web/cgi-bin/hi3510/snap.cgi?&-getpic

Ich tendiere dazu die Cam zurückzusenden und mir eine andere zu holen bei der es einen "normalen" "einbindbaren" Stream gibt.

[psilo]

Java != JavaScript, nur am Rande ;-)

Du müsstest es aber irgendwo in den PHP Code hacken. Daher beides irrelevant

[bruepe]

Hat sonst noch jemand eine Idee?

[bruepe]

Oder hat mir jemand ein paar Quellen/Hilfen wie ich das mit einem Proxy hinbekomme?

[bruepe]

Der Digitus Support meinte mit einem JFrame. Wird das klappen oder brauche ich das gar nicht erst versuchen?

[psilo]

Mir ist nicht klar, was in diesem Zusammenhang ein Java Konstrukt helfen soll?! (https://docs.oracle.com/javase/7/doc...ng/JFrame.html)

Vermutlich Digitus auch nicht
Erfahrungsgemäß ist jeder 1st Level Support mit Anfragen dieser Art überfordert, da das was Du machst über den Use Case des Normalverbrauchers hinaus geht..

Als Idee: ich habe jetzt bei mir so umgebaut, dass ich mit einem Raspi als NGINX ReverseProxy über Clientzertifikate + basic auth (doppelt gesichert..) gegen die Webcam eine Weiterleitung gebaut habe:

        location /video {
                if ($ssl_client_verify != SUCCESS) {
                        return 403;
                        break;
                }
                #client_certificate_auth only
                auth_basic "Restricted Area: FlurCam";
                auth_basic_user_file /etc/nginx/.flurcam;

                if ($allowed_country = no)  {
                        return 403;
                }
                proxy_pass http://192.168.178.40/video;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Authorization "Basic <base64 encoded user+":"+password>";
        }

Das klappt wunderbar und damit ist die Kamera über die DynDNS Domain eingebunden. Sollte auch mit den JS Files so keine Probleme geben, sofern Du diese ähnlich vom ReverseProxy ins LAN weiterroutest.

Der Reverse Proxy hat eigene Auth Daten (in der .flurcam), die Kamera im LAN dann wieder separate, die ich als base64 String mitgebe.

In der SV ists relativ lightweight:

<img class="ui-corner-bottom" id="mjpgImage" alt="Processing..." src="https://smartvisu:<passwort>@<mydyndns_domain>/video/mjpg.cgi?profileid=1">