+ Antworten
Seite 1 von 5 1 2 3 ... LetzteLetzte
Ergebnis 1 bis 10 von 47
  1. #1
    Registriert seit
    Aug 2011
    Beiträge
    88

    Standard RTSP Streams >1080p ruckeln seit der 5.5

    Das RTSP Streaming seit der 5.5 macht mir große Probleme.

    Rückblickend auf die 5.4 war das Streamen im WF von der Lupus LE202 HD im Media Objekt mit
    "rtsp://tom:home@192.168.1.50:554/cam/realmonitor?channel=1&subtype=0"
    - unter Win10 mit IE11 und Android 9 Fully ok
    - der Stream mit Aktualisierung der Datum/Zeit Anzeige war Sekunden synchron kontinuierlich
    - auf dem iPad mit IOS 14.1 kam die Meldung "Der Stream kann unter IOS nicht angezeigt werden"


    Unter 5.5 passiert folgendes mit dem gleichen RTSP String im WF:
    - auf dem iPad ist der Stream meiner Lupus Cam nun sichtbar
    - unter Android Fully kommt nun "Diese Funktion ist im Internet Explorer nicht verfügbar" (Android hat kein IE und Fully nutzt Chrom)
    - unter Android mit Chrom ist der Stream vorhanden
    - unter WIN 10 mit IE11 habe ich "Fehler beim Laden von Stream!"
    - unter WIN 10 mit Edge-Chromium ist der Stream vorhanden.

    Dabei sehe ich auf alle Geräten folgende Probleme
    - bisherige Anzeigen auf Android Fully Kiosk und Win10 IE Kiosk gehen nicht mehr
    - die Zeitanzeige läuft nicht mehr im Sekundentakt, auf keinem der Geräte, das heißt der Stream ist nicht kontinuierlich
    sondern wird nur alle 5-7 sec aktualisiert - eher ein langsamer Bildwechsler!

    Wer kann mir ein 5.4 Paket für Raspi (link) zur Verfügung stellen bis diese Fehler in der 5.5 beseitigt sind


    Danke im voraus

    tom2005

  2. #2
    Registriert seit
    Feb 2005
    Ort
    Lübeck
    Beiträge
    24,167

    Hi Tom,

    was für einen Pi hast und und welche Auflösung hat dein Kamera-Stream?

    Und magst du in dem Android Fully mal die URL aufrufen und den Inhalt kopieren? http://wieistmeinuseragent.de/

    paresy

  3. #3
    Registriert seit
    Aug 2011
    Beiträge
    88

    Ich nutze einen Pi3b+ mit USB Boot auf Debian Stretch,
    Die Cam ist .

    Name:  Stream_haupt.PNG
Hits: 299
Größe:  29.0 KB

    Windows URL:
    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36 Edg/86.0.622.61

    Du verwendest Chrome Version 86.0.4240.111 unter Windows

    Fully: war IE11 jetzt "default" und nun ist das ok, aber mit der Verzögerung wie oben

    danke schon mal

    tom2005
    Geändert von tom2005 (04.11.20 um 17:15 Uhr)

  4. #4
    Registriert seit
    Feb 2005
    Ort
    Lübeck
    Beiträge
    24,167

    Ich befürchte dein Pi schafft den FullHD Stream deiner Kamera nicht zeitnah zu dekodieren. Kannst du bei deiner Kamera die Auflösung Test-Weise reduzieren?

    paresy

  5. #5
    Registriert seit
    Aug 2011
    Beiträge
    88

    Ich habe den Stream von Haupt- auf Substream umgestellt.
    Damit funktioniert die Anzeige bezogen auf den Sekundentakt wie gewünscht.

    Die Vermutung mein Pi schafft den HD-Stream jetzt nicht zu dekodieren, scheint sich zu bewahrheiten.

    Allerdings, meine Frage ist:

    Warum ist die Last mit dem 5.5 Update so groß geworden, dass der Pi es nicht mehr schafft.

    Bis dahin gab es niemals die Vermutung das der Pi dazu zu schlapp ist. Ich konnte auf 4 Geräten gleichzeitig den Stream betrachten.
    auf dem 2x 6" Handy, dem 9,7" Samsung Tablet und dem Windows Tablet 11,6" und das in der Webfront TabPane 95%.

    Heute mit der 5.5 und Anzeige auf 4 Geräten lag die Auslastung lt. App bei 30% und die Temp stieg nach 3 min auf 74 °C.
    Da ist noch genug Luft nach oben.

    Man könnte nun denken es liegt an der Programmierung der Dekodierung Funktion von H.264H.

    Kann man den Teil der einwandfrei und schnell bisher funktioniert hat nicht so lassen wie er ist und optimiert nur den IOS Teil der noch nicht ging.
    Ich meine also besser 2 Stufen die schnell sind, als eine Zeile die den Pi an seine Grenzen treibt.

    Zumal, wenn ich den Datendurchsatz betrachte für beide Streams, ist da nur eine Differenz von 80 - 100 kbit/s zu Gunsten von mpeg.
    Also an der Datenmenge kann es kaum liegen.

    Es beantwortet auch nicht die Frage warum es nun unter IE11 nicht mehr geht.


    LG
    tom2005
    Geändert von tom2005 (04.11.20 um 21:34 Uhr)

  6. #6
    Registriert seit
    Feb 2005
    Ort
    Lübeck
    Beiträge
    24,167

    Hi Tom,

    die alte Variante hatte immer mehrere Sekunden Latenz. Das ist für die meisten Anwendungsfälle nicht geeignet. Deshalb dekodieren wir jetzt alles und kodieren es nach MJPEG. Der IE11 kann dies leider nicht.

    Früher haben wir einfach nur den Stream als HTML5 Video verpackt. Aber wie oben schon gesagt - die Latenz war zu hoch und somit war es für uns auch keine Option dies beizubehalten.

    Ggf macht es Sinn ein paar Euro für den Pi4 auszugeben. Der hat wesentlich mehr CPU Power.

    paresy

  7. #7
    Registriert seit
    Aug 2011
    Beiträge
    88

    Hi paresy,

    danke für die Antwort. Das erklärt es für mich.

    Wenn man nun aber weder mit der geringeren Auflösung noch dem kleineren Bild zufrieden ist, aber auch keinen schnelleren Pi will,
    was spricht dann dagegen ein "Mediaobjekt 2" als Modul zusätzlich zu installieren, das wieder nur einfach den Stream als HTML5 Video verpackt.

    So bleibt es dem User überlassen was für ihn das beste ist und ob er mit der Verzögerung leben will.

    Danke nochmal für die tolle Arbeit bisher

    tom2005

  8. #8
    Registriert seit
    Feb 2005
    Ort
    Lübeck
    Beiträge
    24,167

    Hi Tom,

    Der Aufwand, ein zweites mit vielen Nachteilen (z.B. war dies nur auf RTSP beschränkt) behaftetes System zu pflegen, spricht dagegen. Außerdem gäbe es dann wieder mehr Optionen die der Support immer differenzieren müsste

    paresy

  9. #9
    Registriert seit
    Jan 2016
    Ort
    Hessen, Deutschland
    Beiträge
    73

    Die "alte" Version hat doch den Link praktisch nur als <img> Tag im WebFront eingefügt, oder nicht? Das wäre für mich aktuell das bevorzugte Verhalten, da die SymBox mit 5.5 leider mit 10 Mobotix-Streams vollständig überlastet ist.

    Außerdem habe ich das Problem das die neuen Streams im WebFront nicht mehr richtig skaliert sind. Ich hatte über Inhaltsteiler 6 Kästen erstellt und dort die Kameras drin. Diese haben sich dann immer so skalieret dass das Kamera-Bild voll sichtbar war (manchmal eben mit Balken am Rand).

    Mit den neuen Streams füllen die Kamerabilder aber die Kästen vollständig aus, egal bei welcher Fenstergröße. Da fehlen dann natürlich plötzlich Bildausschnitte.

  10. #10
    Registriert seit
    Feb 2005
    Ort
    Lübeck
    Beiträge
    24,167

    Hi Andy,

    hattest du die RTSP Streams oder die MJPEG Streams in Verwendung? Falls es MJPEG war, kannst du das alte Verhalten aber selber schnell nachbauen. (Bei RTSP war es ein <video> Element und wir haben die Daten intern "umverpackt")

    Erstellt dir dazu ein paar String Variablen, welche das HTMLBox Profil nutzen und dort der <img> Tag drin ist. Im WebFront verknüpfst du dann diese über Inhaltswechsler welche direkt auf die String Variable zeigen. Damit solltest du zu 100% das alte Verhalten wiederherstellen können.

    Wir sind aktuell noch am prüfen, wie wir bei den MJPEG -> MJPEG Streams den Transcoding schritt entfernen können, sodass zumindest bei lokalen Verbindungen ohne Resizing das Transcoding entfallen könnte.

    Der Vorteil der aktuell Implementation ist, dass die Authentifizierung von IP-Symcon gemacht wird und du niemals Kennwörter der Kamera's ins WebFront leakst. Und du bekommst die Streams über den Connect oder DynDNS nach außen ohne die Kameras ebenfalls weiterleiten zu müssen.

    paresy

Ähnliche Themen

  1. RTSP-Streams
    Von Nall-chan im Forum Allgemeine Diskussion
    Antworten: 175
    Letzter Beitrag: 03.07.20, 17:54