MJPEG Stream ruckelt - Zugriff auf H.264 Stream?

Hallo zusammen,
ich greife über den MJPEG-Stream (http://192.168.2.xxx/mjpegstream.cgi?-chn=11&-usr=guest&-pwd=xxxx) auf den Live-Stream meiner Instar 9008 zu.
Dieses Stream benutze ich, um ihn bei Ereigniserkennung im IoBroker darzustellen.
(Dies mache ich einfach über einen HTML-Code (img src=„http://192.168.2.xx/mjpegstream.cgi?-chn=12&-usr=guest&-pwd=xxx“ width=„550“.

Das Ganze klappt auch wirklich fehlerfrei… nur ruckelt leider der Stream immer! Benutze ich den Qualität schlechteren Stream (Also chn12), dann wird alles flüssig dargestellt, aber Qualität ist natürlich nicht so gut).

Die Frage is nun: Woran liegt es. An der Verbindung kann es (meiner Meinung nach nicht liegen), denn das Anzeige-Gerät hat eine kabelgebundene 1Gbit-Verbindung).

Mir ist aufgefallen, dass, wenn ich mich bei der Kamera direkt einlogge, auch dieses Ruckeln zu sehen ist.
Das Ruckelt hört allerdings auf, wenn ich in der WebUI beim Live-Bild den Schalter „H.264“ einschalte.

Mir ist klar, dass das dann ein anderes Videoformat ist.
Die Frage ist allerdings: Komme ich auch an die „H264-Version“ des Live-Streams (z-B. über eine Webadresse) heran, sodass ich das ganze im Iobroker benutzen kann?

Oder gibt es gar eine ganz andere Möglichkeit, den Live-Stream der Kamera ruckelfrei darzustellen (im Übrigen kann ich mir sowieso nicht erklären, warum der MJPEG-Stream ruckelt, da - wie gesagt - die Datenverbindung eigentlich ausreichend sein müsste.

Hallo und ein gutes Neues Jahr!

Warum das Ganze ruckelt, kann ich aus dem Stehgreif nicht sagen. Aber hast Du mal den RTSP-Stream abgegriffen. In der Form rtsp://user:password@IP-Adresse/11

Den kann man sich u.a. im VLC-Player darstellen lassen. Der H264 Codec ist eingebunden.
Grüße

Danke für den Hinweis.
Der Stream im VLC-Player ruckelt ganz leicht hin und wieder… ist aber definitiv besser als der MPJEG-Stream… der ruckelt ganz doll.

Die Frage ist: Was hilft das jetzt? Warum ruckelt der MPJEG-Stream überhaupt… ist es vlt. die Kamera, die das nicht „schafft“. Die Datenleitung ist wie gesagt 1Gbit (im Übrigen natürlich nicht ganz 1 Gbit, aber ich habe testweise mal eine Datei von einem Gerät runtergeladen, das ebenfalls an dem Switch hängt, an dem die Kamera hängt… und daraus ergab sich eine Datenübertrag von 100 MB die Sekunde… also 800 MBit). Die Instar hat ja sowieso nur ein 100MBit-Interface… an der Datenübertragung kann es also eigentlich nicht liegen (jedenfalls an der Datenübertragung des Anzeigegeräts)).

An der Datenleitung wird es nicht liegen, sofern der Rechner auch im Netzwerk der Kamera liegt. Wenn man aus dem Internet heraus zugreift, ist das natürlich eine andere Sache.
Bzgl. Bandbreitenanforderungen hat Instar ein Tool bereit gestellt, mit dem man einen Einblick erhält, welche Größenordnungen in etwa eine Rolle spielen. Unter „Erweitert“ kann man noch an den Parametern wie Keyframes, Frame Rate etc. spielen.
Die Keyframes würde ich im Kameramenü nicht zu klein wählen. Die Frame-Rate wiederum nicht zu groß. 20fps…25fps sollten genügen. Und dann die Keyframes >= Frame-Rate. Ein Vorschlag.

Danke für die Antwort.
Der Zugriff erfolgt im gleichen Netzwerk (und nicht über das Internet). Habe extra sogar einen „Managed Switch“ gekauft, der die Datenleitung der Kamera priorisiert… aber auch das hat nicht geholfen.
An den Videoeinstellungen habe ich natürlich schon alles probiert: Key-Frame und FPS stehen beide auf 25.

Meine Frage ist auch, ob es eigentlich anderen beim MPJEG-Stream genauso bei der Instar 9008 geht?
Ich habe 4 Stück davon und bei jeder einzelnen Kamera habe ich dieses Problem des Ruckelns beim MPJEG-Stream…

Beim MJPEG Stream ist das normal - hier hat man max. 5-10 fps. Das Verfahren ist einfach nicht effizient. Die maximale Framerate bekommt man nur mit h.264 und RTSP oder dem WS Stream in der WebUI (HMTL5 Video).

Ok, aber der MJPEG-Stream auf Kanal 12 läuft (bei mir) flüssig… hier scheint ja dann die FPS doch höher zu sein (und nur die Datenrate geringer)

@estimator

Bzgl. Bandbreitenanforderungen hat Instar ein Tool bereit gestellt, mit dem man einen Einblick erhält, welche Größenordnungen in etwa eine Rolle spielen. 

Wenn ich das ausprobiere, dann ist ja sogar die Datenrate im H264 höher als im MPJEG-Stream.
Warum ruckelt es dann beim MJPEG und nich beim H264?
Das ist mir tatsächlich unverständlich.

Dann ist es vermutlich der „Anzeige“-Browser, der das Problem macht, würde ich vermuten.

Ich habe grad den MJPEG-Stream per VLC getestet. Z.Zt. geht ein guter Wind, da kann man an den Bewegungen der Bäume gut erkennen, wie flüssig der Stream läuft. Ich habe den Eindruck, bei höchster Auflösung (Kanal 11, 1920*1080) gerade mal 3 Frames pro Sekunde zu bekommen. VLC zeigt als Content Bitrate knapp 9000 kb/s an.
EDIT: Allerdings sehe ich unter Statistics - Video - Displayed, dass es mindestens 10 Frames/s sein müssten. Demnach werden nicht alle übertragenen Frames auch angezeigt. ?
Wechsle ich wieder zu rtsp und H264, dann läuft alles flüssig und die Content Bitrate schwankt zwischen 1500…4000 kb/s.

Ok, dann scheint ja bei dir das gleiche „Phänomen“ aufzutreten, wie bei mir.

Habe das ganze bei mir auch mal mit dem MPJEG-Stream im VLC-Player getestet und komme auch auf eine Datenrate von ca. 9000 kb/s.
Die Framerate konnte ich da jetzt aber nicht ablesen, oder hast du die „berechnet“?

grafik

Die Frage ist: Warum werden in dem MPJEG-Stream, den man per http abgreifen kann, nur so wenige Frames übertragen…
Vlt. kann sich hier ja mal ein Instar-Mitarbeiter zu äußern… :slight_smile:

HTTP1 über TCP ist nicht für Streaming vorgesehen - da gibt es einen großen Overhead bei jedem gesendeten Frame. RTSP über UDP läuft da um einiges besser.

Und dann kommt hinzu das man bei MJPEG nur die JPG Komprimierung hat. Bei h.264 wird nur ein Bruchteil der Daten gesendet, um das gleiche Video darzustellen.

Gefühlt berechnet aus der Differenz der angezeigten Bilder im Sekundentakt.

Anscheinend auch in Innsbruck, das Skispringen ist abgesagt. :disappointed: