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! :wink:

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

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

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

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

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

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

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

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

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 :slight_smile:

paresy

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.

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

Danke für den Tipp, die Lösung habe ich mir natürlich auch überlegt und ist technisch natürlich leicht umzusetzen. In meinem Fall sind es alles bereits MJPEG-Streams von den Mobotix Kameras, da diese am besten auf allen Tablets und Endgeräten dargestellt werden konnten.

Ist aber ärgerlich dass ein Stable-Update solch extreme Einwirkung auf die Performance hat… wäre einfach schön gewesen wenn die bestehenden Objekte ihr Verhalten beibehalten und man die Zusatz-Funktionen bewusst aktivieren muss (oder eben eine neue Instanz erstellen). Wenn jemand vielleicht größere Anlagen mit noch mehr Kameras hat und dann nichtsahnend das Stable-Update einspielt steht er plötzlich da und das gesamte System reagiert ggf. gar nicht mehr weil die Streams auf unterschiedlichen Geräte offen sind und alles blockieren. Jetzt muss man eine ganze Reihe Kameras händisch neu anlegen und überall hin verlinken.

Ich hänge mich hier auch noch mal dran :wink:

Ich hatte auch das Problem, das nach dem update auf 5.5 meine 5 Streams nur noch als quasi Standbild in WF angezeigt wurden.

https://www.symcon.de/forum/threads/44905-Media-Streams%28RTSP%29-in-5-5-nur-Standbild

Durch die Transkodierung von RTSP (H.264)–> MJPEG ist mein NAS völlig überfordert.:banghead:

Ich würde mir auch wünschen, das es dem Nutzer überlassen wird ob er eine Transkodierung möchte (wegen dem Delay) oder nicht.
Ich kann mit einem Versatz von 3-8 Sekunden leben. :rolleyes:

Danke

Oliver

Nach allem was ich hier bisher so lese, warte ich erst mal mit einem Update auf die 5.5.
Irgendwie ist mir das zu heiß, dass ich mir mein System aufgrund der eingebundenen Kameras lahmlege und dann erst mal alles umbauen muss. Ich kann schließlich nicht kontrollieren, wer wann über sein WebFront einen Sream aufruft.

Ich würde es daher auch bevorzugen, wenn man einstellen könnte, ob eine Transkodierung stattfindet und auch, ob der Stream über IPS ans WebFront geht oder ob er direkt aufgerufen wird.

Gruß
Slummi

Das „einfrieren“ aller Streams wenn sie in der hochauflösenden Variante angesehen werden kann ich für alle meine 4 Reolink Cams bestätigen!

Hat vor Update auf 5.5. ohne Probleme funktioniert.

In der Preview funktioniert es allerdings.

Wann frieren die Cams denn ein? Sofort oder nach mehreren Stunden?

paresy

sofort. nach ein paar sekunden gibts zwar artefakte, aber es tut sich nichts.

vielleicht wichtig:
bei einer vorbeigehenden person habe ich gemerkt, das sie sich in extremer zeitlupe bewegt hat. so gut wie nicht zu merken das sie sich bewegt hat.

und wie gesagt beim preview stream, mit geringerer auflösung und bildrate stellt er alle vier streams gleichzeitig in einem fenster ohne probleme dar.

Ich stimme den Vorrednern auch noch mal explizit zu.

Wenn man es nicht mit einer zusätzlichen Zeile in Medientyp z.B „Stream (RTSP)“ machen kann oder möchte,
dann geht es doch bestimmt mit einem Symcon eigenen RTSP-Modul.

So wie ich es verstanden habe sind es nur einige Zeilen Text und keine riesigen Transkodierungen. :slight_smile:

Moin,

ich habe auch Probleme seit 5.5.
Der Stream friert nach nach 2 Sekunden ein.
Vorm Einfrieren bewegt sich alles in Zeitlupe.
Der Substream mit reduzierter Auflösung läuft ohne Probleme.
Am Server liegt es aber glaube ich nicht? Oder ist ein Core i3-8109U mit 16GB RAM nicht mehr ausreichend.
Mit 5.4 liefen diese Einstellungen problemlos.

Jemand eine Idee?

Danke und Gruss

Ein Stream mit diesen Einstellungen benötigt seit 5.5 75% CPU und 12,5% RAM.
Im lokalen Netz kann ich also nur einen einzelnen Stream in dieser Qualität im WF integrieren.

Remote via VPN friert selbst ein einziger Stream, wie oben beschrieben ein. Meine Leitung schafft max. 50 Mbit/s Upload.
Sobald ich remote via VPN einen Stream im WF aufrufe, zeigt die Fritzbox maximale Auslastung beim Upload. Dann friert der Stream ein, CPU Auslastung und Upload gehen wieder runter.

Was genau da passiert, kann ich leider nicht sagen, ich frage mich jedoch, ob das so gewollt ist?

Wenn ich mich remote via VPN direkt mit der Kamera verbinde, läuft alles einwandfrei.

Wenn ich den Stream auf 720p, also die niedrigste Qualität stelle, dann wird zwar nur noch 35% CPU benötigt, jedoch friert der Stream weiterhin ein, sobald ich remote via VPN das WF öffne. Das Reduzieren der Qualität kann also nicht die Lösung sein. Zumal wir hier von einem einzigen Stream sprechen. Viele User werden 1-4 bzw. noch mehr Streams integrieren wollen, was mit bisher völlig ausreichender Hardware nun nicht mehr möglich ist. Oder was mache ich falsch?

Ich habe auch nicht verstanden, warum der RTSP Stream in MJPEG umgerechnet werden muss.
Die erwähnten Verzögerungen habe ich in 5.4 gar nicht bemerkt.
Wer MJPEG benötigt, kann das Protokoll doch direkt auswählen?

Gibt es eine Möglichkeit weiterhin RTSP Streams zu nutzen, wie es in 5.4 der Fall war?

Danke und Gruss

Hallo,
gleiches Problem bei mir. Video ist sehr zäh und nach ein paar Sekunden habe ich nur noch Standbild.

Ich habe noch nicht nach den Systemressourcen gesehen, es läuft aber auf einem virtualisierten Server (Xeon) und sollte hier keinen Engpass haben. Es handelt sich auch nur um eine Kamera.

Ansonsten finde ich es super, dass die Zeitverzögerung nahezu weg ist (war vorher für die Klingel kaum zu gebrauchen, da das Bild erst 10 Sekunden nach dem Klingeln an der Haustür den Besuch gezeigt hatte).