Test Adapter eusec 3.x.x

Foggy

@typhos ganz herzlichen dank.

Der Livestream funktioniert jetzt. Im Feld Hostname habe ich jetzt die IP des ioBrokers eingesetzt, damit geht es. Auch der RTSP-Stream mit dem Port 8554.

Calibrate ist für mich persönlich nicht so wichtig und ich kann es in der App nutzen. Hätte hier nur helfen wollen.

Talkback: hier habe ich eine https adresse zu einer mp3-Datei eingetragen, hier mal der Log:

eusec.0
	2026-09-28 22:13:15.454	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 53... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":53}]
eusec.0
	2026-09-28 22:13:15.454	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.453	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.452	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.452	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.451	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.450	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.449	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.448	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.446	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 52... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":52}]
eusec.0
	2026-09-28 22:13:15.445	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 51... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":51}]
eusec.0
	2026-09-28 22:13:15.356	debug	[euSec.onStateChange] state eusec.0.T8426xxxxxxxxxxx.cameras.T8426xxxxxxxxxxx.livestream_rtsp changed: rtsp://IP.ioBroker:8554/T8426xxxxxxxxxxx (ack = true) was already acknowledged, ignore it...
eusec.0
	2026-09-28 22:13:15.353	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 51... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":51}]
eusec.0
	2026-09-28 22:13:15.352	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 51... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"IP.Adresse","remotePort":12522,"dataType":"VIDEO","seqNo":51}]
eusec.0
	2026-09-28 22:13:15.329	debug	[euSec.onStateChange] state eusec.0.T8426xxxxxxxxxxx.cameras.T8426xxxxxxxxxxx.livestream changed: http://IP.ioBroker:1984/stream.html?src=T8426xxxxxxxxxxx&background=false (ack = true) was already acknowledged, ignore it...
eusec.0
	2026-09-28 22:13:15.316	info	Talkback for device T8426xxxxxxxxxxx: playing "https://www.url.de/test.mp3"...
eusec.0
	2026-09-28 22:13:15.315	debug	[Object.write] [http] [Station.onCommandResponse] Station got p2p command response [{"station":"T8426xxxxxxxxxxx","commandType":1005,"channel":0,"returnCodeName":"ERROR_PPCS_SUCCESSFUL","returnCode":0,"customData":{"command":{"name":"deviceStartTalkback"}}}]
eusec.0
	2026-09-28 22:13:15.315	debug	[Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Result data for command received [{"stationSN":"T8426xxxxxxxxxxx","message":{"sequence":5,"commandType":1005,"channel":0,"acknowledged":true,"retries":0,"returnCode":0,"data":{"type":"Buffer","data":[209,0,0,5,88,90,89,72,237,3,16,0,0,0,1,0,0,1,0,0,233,206,85,185,220,3,31,146,34,53,75,142,140,224,229,156]},"customData":{"command":{"name":"deviceStartTalkback"}}},"resultCodeName":"ERROR_PPCS_SUCCESSFUL","resultCode":0}]
eusec.0
	2026-09-28 22:13:15.314	debug	[Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Received data [{"stationSN":"T8426xxxxxxxxxxx","seqNo":4,"commandIdName":"CMD_START_TALKBACK","commandId":1005,"resultCodeName":"ERROR_PPCS_SUCCESSFUL","resultCode":0,"resultData":"0000000000000000000000000000000000000000000000000000000000000000","data":"000000000000000000000000000000000000000000000000000000000000000000000000","seqNumber":6,"p2pDataSeqNumber":5,"offsetDataSeqNumber":0}]
eusec.0
	2026-09-28 22:13:15.314	debug	[Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Skipping decryption, data not block-aligned [{"stationSN":"T8426xxxxxxxxxxx","seqNo":4,"commandType":"CMD_START_TALKBACK","signCode":1,"dataLength":36,"mod16":4}]

typhos

@Foggy Schön, dass der Livestream jetzt läuft, und danke für die Rückmeldung!

Zum Talkback: Laut Log nimmt die Kamera den Talkback-Start an, und der Adapter fängt an, die Datei abzuspielen („Talkback for device … playing“). Dein Ausschnitt endet aber eine Zehntelsekunde danach, da ist ffmpeg noch gar nicht richtig angelaufen. Was danach passiert, kann ich deshalb nicht sehen. An der E30 hat Talkback außerdem noch niemand getestet. Kannst du bitte Folgendes nachschauen?

Das Log ab der Zeile „playing“ bis zum Ende des Livestreams, nur die Zeilen mit „talkback“, „Talkback“, „ffmpeg“ oder „Error“. Die vielen VIDEO-Zeilen kannst du weglassen. Mich interessiert vor allem, ob eine Zeile „Talkback for device … - Error“ kommt und ob danach „Station stop talkback“ und „Station stop livestream“ folgen.
Wird talkback_play nach dem Abspielen bestätigt (ack = true)? Das passiert erst, wenn die Datei ganz durchgelaufen ist.
Wie lang ist die MP3, und läuft der Livestream ungefähr so lange?
Hörst du etwas, wenn du über die Eufy-App sprichst? Steht speaker auf true und speaker_volume nicht auf 0?
Zum Gegentest: Leg die MP3 direkt auf den ioBroker-Rechner (unter Linux z. B. /opt/iobroker/test.mp3) und schreib den vollständigen Pfad in talkback_play. Dann scheidet der Download über https als Ursache aus.

Foggy

Guten Abend,

hier das entsprechende Log. Die mp3 ist gut 20 Sekunden lang. Speakter ist true und volume auf 100. Wenn ich über die App spreche, höre ich das.

2026-10-01 19:47:49.669 - info: eusec.0 (47919) Talkback for device T8426xxxxxxxxxxx: playing "http://123.456.789.000:8081/files/0_userdata.0/acoustic-intro-music.mp3"...
2026-10-01 19:47:49.715 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 58... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"VIDEO","seqNo":58}]

2026-10-01 19:48:16.702 - debug: eusec.0 (47919) [euSec.onStateChange] state eusec.0.T8426xxxxxxxxxxx.cameras.T8426xxxxxxxxxxx.talkback_play changed: http://123.456.789.000:8081/files/0_userdata.0/acoustic-intro-music.mp3 (ack = true) was already acknowledged, ignore it...
2026-10-01 19:48:16.704 - debug: eusec.0 (47919) [Object.write] [http] [Station.stopTalkback] Station stop talkback - sending command [{"stationSN":"T8426xxxxxxxxxxx","deviceSN":"T8426xxxxxxxxxxx"}]
2026-10-01 19:48:16.705 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol._sendCommand] Sending p2p command... [{"station":"T8426xxxxxxxxxxx","sequence":6,"commandType":1006,"channel":0,"retries":0,"messageStatesSize":1}]
2026-10-01 19:48:16.706 - debug: eusec.0 (47919) [Object.write] [http] [Station.stopLivestream] Station stop livestream - sending command [{"stationSN":"T8426xxxxxxxxxxx","deviceSN":"T8426xxxxxxxxxxx"}]
2026-10-01 19:48:16.710 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol._sendCommand] Sending p2p command... [{"station":"T8426xxxxxxxxxxx","sequence":7,"commandType":1004,"channel":0,"retries":0,"messageStatesSize":2}]
2026-10-01 19:48:16.717 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA DATA - Processing sequence 5... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"DATA","seqNo":5}]
2026-10-01 19:48:16.718 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Skipping decryption, data not block-aligned [{"stationSN":"T8426xxxxxxxxxxx","seqNo":5,"commandType":"CMD_STOP_TALKBACK","signCode":1,"dataLength":36,"mod16":4}]
2026-10-01 19:48:16.718 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Received data [{"stationSN":"T8426xxxxxxxxxxx","seqNo":5,"commandIdName":"CMD_STOP_TALKBACK","commandId":1006,"resultCodeName":"ERROR_PPCS_SUCCESSFUL","resultCode":0,"resultData":"0000000000000000000000000000000000000000000000000000000000000000","data":"000000000000000000000000000000000000000000000000000000000000000000000000","seqNumber":8,"p2pDataSeqNumber":7,"offsetDataSeqNumber":0}]
2026-10-01 19:48:16.719 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Result data for command received [{"stationSN":"T8426xxxxxxxxxxx","message":{"sequence":6,"commandType":1006,"channel":0,"acknowledged":true,"retries":0,"returnCode":0,"data":{"type":"Buffer","data":[209,0,0,6,88,90,89,72,238,3,16,0,0,0,1,0,0,1,0,0,233,206,85,185,220,3,31,146,34,53,75,142,140,224,229,156]},"customData":{"command":{"name":"deviceStopTalkback"}}},"resultCodeName":"ERROR_PPCS_SUCCESSFUL","resultCode":0}]
2026-10-01 19:48:16.719 - debug: eusec.0 (47919) [Object.write] [http] [Station.onCommandResponse] Station got p2p command response [{"station":"T8426xxxxxxxxxxx","commandType":1006,"channel":0,"returnCodeName":"ERROR_PPCS_SUCCESSFUL","returnCode":0,"customData":{"command":{"name":"deviceStopTalkback"}}}]
2026-10-01 19:48:16.721 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA DATA - Processing sequence 5... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"DATA","seqNo":5}]
2026-10-01 19:48:16.723 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA DATA - Processing sequence 5... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"DATA","seqNo":5}]
2026-10-01 19:48:16.748 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA DATA - Processing sequence 6... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"DATA","seqNo":6}]
2026-10-01 19:48:16.749 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Skipping decryption, data not block-aligned [{"stationSN":"T8426xxxxxxxxxxx","seqNo":6,"commandType":"CMD_STOP_REALTIME_MEDIA","signCode":1,"dataLength":36,"mod16":4}]
2026-10-01 19:48:16.749 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Received data [{"stationSN":"T8426xxxxxxxxxxx","seqNo":6,"commandIdName":"CMD_STOP_REALTIME_MEDIA","commandId":1004,"resultCodeName":"ERROR_PPCS_SUCCESSFUL","resultCode":0,"resultData":"0000000000000000000000000000000000000000000000000000000000000000","data":"000000000000000000000000000000000000000000000000000000000000000000000000","seqNumber":8,"p2pDataSeqNumber":7,"offsetDataSeqNumber":0}]
2026-10-01 19:48:16.749 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Result data for command received [{"stationSN":"T8426xxxxxxxxxxx","message":{"sequence":7,"commandType":1004,"channel":0,"acknowledged":true,"retries":0,"returnCode":0,"data":{"type":"Buffer","data":[209,0,0,7,88,90,89,72,236,3,16,0,0,0,1,0,0,1,0,0,233,206,85,185,220,3,31,146,34,53,75,142,140,224,229,156]},"customData":{"command":{"name":"deviceStopLivestream"}}},"resultCodeName":"ERROR_PPCS_SUCCESSFUL","resultCode":0}]
2026-10-01 19:48:16.750 - debug: eusec.0 (47919) [Object.write] [http] [Station.onCommandResponse] Station got p2p command response [{"station":"T8426xxxxxxxxxxx","commandType":1004,"channel":0,"returnCodeName":"ERROR_PPCS_SUCCESSFUL","returnCode":0,"customData":{"command":{"name":"deviceStopLivestream"}}}]
2026-10-01 19:48:16.750 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 46... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"CONTROL","seqNo":46}]
2026-10-01 19:48:16.752 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleDataControl] Station Handle DATA CONTROL - CMD_NOTIFY_PAYLOAD [{"stationSN":"T8426xxxxxxxxxxx","payload":"{\"cmd\":6246,\"payload\":{\"num\":0}}"}]
2026-10-01 19:48:16.752 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleDataControl] Handle DATA CONTROL - CMD_NOTIFY_PAYLOAD Livestream status [{"stationSN":"T8426xxxxxxxxxxx","payload":{"num":0}}]
2026-10-01 19:48:16.756 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA DATA - Processing sequence 6... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"DATA","seqNo":6}]
2026-10-01 19:48:16.757 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 46... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"CONTROL","seqNo":46}]
2026-10-01 19:48:16.757 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 46... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"CONTROL","seqNo":46}]
2026-10-01 19:48:16.763 - debug: eusec.0 (47919) [Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 46... [{"stationSN":"T8426xxxxxxxxxxx","remoteAddress":"123.456.789.E30","remotePort":29713,"dataType":"CONTROL","seqNo":46}]
2026-10-01 19:48:16.830 - debug: eusec.0 (47919) [euSec.onStateChange] state eusec.0.T8426xxxxxxxxxxx.cameras.T8426xxxxxxxxxxx.livestream changed: (ack = true) was already acknowledged, ignore it...
2026-10-01 19:48:16.875 - debug: eusec.0 (47919) [euSec.onStateChange] state eusec.0.T8426xxxxxxxxxxx.cameras.T8426xxxxxxxxxxx.livestream_rtsp changed: (ack = true) was already acknowledged, ignore it...

typhos

@Foggy Danke für das Log! Laut Log läuft auf Adapterseite alles durch: Die Kamera bestätigt Start und Stopp des Talkbacks, ffmpeg spielt die Datei ohne Fehler ab, und talkback_play wird danach bestätigt. Offen ist noch, ob die Kamera die einzelnen Audiopakete annimmt. Wenn nicht, schreibt die Bibliothek erst etwa 50 Sekunden nach dem Start eine Fehlermeldung, und dein Ausschnitt endet vorher.

Kannst du es bitte noch einmal testen und Folgendes nachschauen?

Das Log ab „playing“ bis etwa eine Minute nach „Station stop livestream“, nur die Zeilen mit „retries“, „talkback“ oder „error“ (Groß-/Kleinschreibung egal). Mich interessiert vor allem, ob „Max send video data retries … reached“ oder ein zweites „Station stop talkback“ auftaucht.
Hörst du an der Kamera wirklich gar nichts, also auch kein Knacken, Rauschen oder abgehacktes Geräusch?
Zum Gegentest bitte noch einmal mit der MP3 als lokaler Datei (z. B. /opt/iobroker/test.mp3, vollständiger Pfad in talkback_play).

CptJackSparrow

Moin!
Bei mir funktioniert der Stream leider nicht mehr...
Der Stream wird scheinbar on demand gestartet. Nach kurzer Zeit erscheint ein erstes Bild, 2 Sekunden später ein zweites Bild, danach wird es wieder schwarz. Dann beginnt es von vorne, ein erstes Bild, ein zweites Bild 2 Sekunden später und schwarz, usw.

S380 Homebase mit diversen eufyCam 2C. Bei einer Indoor Cam C220 ohne Einbindung in die S380 genau das gleiche Verhalten.

Geht es nur mir so oder ist es ein grundsätzliches Problem?

Folgend ein Auszug aus dem Log und ein File mit Debug Infos.

2026-10-05 07:34:30.149  - info: eusec.0 (803607) On-demand stream T8113T7223200B11: first picture 4 seconds after the request, 1 video request(s) of go2rtc waiting
2026-10-05 07:34:30.148  - info: eusec.0 (803607) streamToGo2rtc(): T8113T7223200B11 - Declared H.264 level 4.2 replaced with 4.0
2026-10-05 07:34:25.959  - info: eusec.0 (803607) Starting the livestream of device T8113T7223200B11
2026-10-05 07:34:25.956  - info: eusec.0 (803607) On-demand stream T8113T7223200B11: requested by go2rtc - starting livestream
2026-10-05 07:33:50.735  - info: eusec.0 (803607) On-demand stream T8113T722322107A: first picture 2 seconds after the request, 1 video request(s) of go2rtc waiting
2026-10-05 07:33:50.733  - info: eusec.0 (803607) streamToGo2rtc(): T8113T722322107A - Declared H.264 level 4.2 replaced with 4.0
2026-10-05 07:33:48.382  - info: eusec.0 (803607) Starting the livestream of device T8113T722322107A
2026-10-05 07:33:48.379  - info: eusec.0 (803607) On-demand stream T8113T722322107A: requested by go2rtc - starting livestream

iobroker-log-gamma-2026-10-05T05-42-23-202Z.txt

typhos

@CptJackSparrow Danke für das Log, damit war der Fehler schnell gefunden. Es liegt nicht an dir, sondern am Adapter seit 3.4.0: Er hat jeden großen Keyframe fälschlich als „go2rtc kommt nicht hinterher“ gewertet und danach das Video bis zum nächsten Keyframe verworfen. go2rtc hat deshalb nur alle paar Sekunden ein einzelnes Bild bekommen und die Verbindung neu aufgebaut. Das passt genau zu dem, was du siehst, und betrifft die 2C an der S380 genauso wie die C220.

Behoben ist das in Version 3.4.2, die jetzt im latest-Repository liegt. Sobald sie bei dir angezeigt wird, bitte aktualisieren und kurz Bescheid geben, ob der Stream wieder durchläuft.

CptJackSparrow

@typhos sagte:
Behoben ist das in Version 3.4.2, die jetzt im latest-Repository liegt. Sobald sie bei dir angezeigt wird, bitte aktualisieren und kurz Bescheid geben, ob der Stream wieder durchläuft.

Gerade eben installiert und es läuft wieder perfekt! Nach ca. 3 Sekunden sind die Streams der verschiedenen Cams immer aufgebaut und werden durchgehend angezeigt. Danke für den schnellen fix!

Ephi

Hallo @typhos

Erst einmal vielen Dank dafür, dass der Adapter weiter entwickelt wird. Ich habe eine Frage zu den RTSP-Streams. Ich habe die Funktion „Livestream bei Bedarf starten“ aktiviert. Ich nutze den VLC-Player (unter iOS) zum Öffnen der RTSP-Streams. Die Video-Übertragung funktioniert soweit (außer dass meist nach 1-2 Sekunden für ein paar Sekunden ein schwarzer Bildschirm angezeigt wird, danach kommt das Bild aber wieder und läuft dann auch durch). Allerdings wird nie Ton über die RTSP-Streams übertragen. In der Eufy-App selbst wird ganz normal der Ton übertragen, wenn ich dort einen Stream aufrufe. Mikrofon und Tonaufzeichnung sind in der Eufy-App jeweils auch aktiviert.

Ich nutze folgende Kameras, die jeweils über die Homebase 3 angebunden sind:

SoloCam S340 (2x)
Indoor Cam Pan&Tilt 2K

Danke für deine Hilfe.

typhos

@Ephi Danke für die Rückmeldung!

Grundsätzlich überträgt der Adapter den Ton auch bei „Livestream bei Bedarf starten“. An meiner Testkamera liefert der RTSP-Stream eine Tonspur mit (AAC, 16 kHz, mono). Bei dir fehlt sie also entweder schon, bevor der Stream bei go2rtc ankommt, oder erst im VLC. Damit ich das auseinanderhalten kann, schau bitte Folgendes nach:

Adapterversion: Welche Version von eusec läuft bei dir?
Log: Öffne den Stream einer S340 im VLC und schau danach im Log (Stufe info reicht) nach den Zeilen mit „On-demand stream“. Mich interessiert vor allem, ob die Zeile „no audio within 5 seconds - continuing without“ auftaucht. Der Adapter schreibt sie, wenn die Kamera nach dem ersten Bild 5 Sekunden lang keinen Ton schickt. In dem Fall lässt go2rtc die Tonspur weg, und VLC bekommt keine.
go2rtc: Ruf bitte im Browser http://<IP-des-ioBroker>:1984/api/streams?src=<Seriennummer der Kamera> auf, während der Stream im VLC läuft, und stell die Ausgabe hier ein. Daran sehe ich, ob go2rtc von der Kamera Ton bekommt und was es an VLC weitergibt.
Gegentest ohne VLC: Öffne den Link aus dem Datenpunkt livestream der Kamera im Browser und schalte im Player den Ton ein. Hörst du dort etwas?

Zum kurzen Schwarzbild: Schreib bitte dazu, wie viele Sekunden nach dem Öffnen es ungefähr auftritt. Dann kann ich es mit den Zeitstempeln im Log vergleichen.

Ephi

Hallo @typhos

Danke für deine Antwort. Ich bin übers Wochenende nicht daheim, werde die Tests aber so schnell wie möglich durchführen, sobald ich wieder zu Hause bin.

Viele Grüße,
Ephi

Ephi

@typhos

So, jetzt bin ich dazu gekommen, deine Fragen zu beantworten:

Adapterversion: Welche Version von eusec läuft bei dir?

3.5.0

Log: Öffne den Stream einer S340 im VLC und schau danach im Log (Stufe info reicht) nach den Zeilen mit „On-demand stream“. Mich interessiert vor allem, ob die Zeile „no audio within 5 seconds - continuing without“ auftaucht. Der Adapter schreibt sie, wenn die Kamera nach dem ersten Bild 5 Sekunden lang keinen Ton schickt. In dem Fall lässt go2rtc die Tonspur weg, und VLC bekommt keine.

Hier im Log sind nach Starten des RTSP-Streams folgende Einträge:

Danach kommen erst wieder Einträge, wenn der Stream stoppt (nach 1 Minute)

go2rtc: Ruf bitte im Browser http://<IP-des-ioBroker>:1984/api/streams?src=<Seriennummer der Kamera> auf, während der Stream im VLC läuft, und stell die Ausgabe hier ein. Daran sehe ich, ob go2rtc von der Kamera Ton bekommt und was es an VLC weitergibt.

Hier die Ausgabe (Nr. der Kamera habe ich anonymisiert):

{
  "producers": [
    {
      "id": 33,
      "format_name": "hevc",
      "protocol": "http",
      "remote_addr": "127.0.0.1:45951",
      "url": "http://127.0.0.1:45951/T81XXXXXXXXXXXXX/video",
      "medias": [
        "video, recvonly, H265"
      ],
      "receivers": [
        {
          "id": 34,
          "codec": {
            "codec_name": "hevc",
            "codec_type": "video"
          },
          "childs": [
            35
          ],
          "bytes": 393437,
          "packets": 89
        }
      ],
      "bytes_recv": 393736
    },
    {
      "id": 36,
      "format_name": "adts",
      "protocol": "http",
      "remote_addr": "127.0.0.1:45951",
      "url": "http://127.0.0.1:45951/T81XXXXXXXXXXXXX/audio",
      "medias": [
        "audio, recvonly, MPEG4-GENERIC/16000/1"
      ],
      "receivers": [
        {
          "id": 37,
          "codec": {
            "channels": 1,
            "codec_name": "aac",
            "codec_type": "audio",
            "sample_rate": 16000
          },
          "childs": [
            38
          ],
          "bytes": 18310,
          "packets": 93
        }
      ],
      "bytes_recv": 17938
    }
  ],
  "consumers": [
    {
      "id": 32,
      "format_name": "rtsp",
      "protocol": "rtsp+tcp",
      "remote_addr": "192.168.178.136:64384",
      "sdp": "v=0\r\no=- 1 1 IN IP4 0.0.0.0\r\ns=go2rtc/1.9.4\r\nc=IN IP4 0.0.0.0\r\nt=0 0\r\nm=video 0 RTP/AVP 96\r\na=rtpmap:96 H265/90000\r\na=fmtp:96 profile-id=1;sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwB4vAk=;sprop-sps=QgEBAWAAAAMAgAAAAwAAAwB4oAKAgC0WNvu8pm4CAgIIAAADAAgAAAMAeEA=;sprop-pps=RAHAcrQTZA==\r\na=control:trackID=0\r\nm=audio 0 RTP/AVP 97\r\na=rtpmap:97 MPEG4-GENERIC/16000/1\r\na=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1408\r\na=control:trackID=1\r\n",
      "user_agent": "LibVLC/3.0.23 (LIVE555 Streaming Media v2016.10.21)",
      "medias": [
        "video, sendonly, ANY",
        "audio, sendonly, ANY"
      ],
      "senders": [
        {
          "id": 35,
          "codec": {
            "codec_name": "hevc",
            "codec_type": "video"
          },
          "parent": 34,
          "bytes": 393437,
          "packets": 89
        },
        {
          "id": 38,
          "codec": {
            "channels": 1,
            "codec_name": "aac",
            "codec_type": "audio",
            "sample_rate": 16000
          },
          "parent": 37,
          "bytes": 18310,
          "packets": 93
        }
      ],
      "bytes_recv": 104,
      "bytes_send": 419035
    }
  ]
}

Gegentest ohne VLC: Öffne den Link aus dem Datenpunkt livestream der Kamera im Browser und schalte im Player den Ton ein. Hörst du dort etwas?

Nein. Bei dem weiteren Test stellt sich allerdings heraus, dass der Ton nur bei den beiden Outdoor-Kameras (S340) nicht übertragen wird. Bei der Indoor-Kamera (Pan&Tilt, s.o.) habe ich jedoch Ton, allerdings nur im Browser. Über RTSP im VLC-Player kommt auch hier kein Ton an.

Zum kurzen Schwarzbild: Schreib bitte dazu, wie viele Sekunden nach dem Öffnen es ungefähr auftritt. Dann kann ich es mit den Zeitstempeln im Log vergleichen.

Ab dem Öffnen von VLC dauert es zunächst 5-8 Sekunden, bis der Stream überhaupt steht und ein Bild angezeigt wird (das ist von mal zu mal unterschiedlich). Das Schwarzbild kommt ca. 4-5 Sekunden nach dem ersten Bild (ist auch schwankend, lässt sich leider nicht allgemeinverbindlich mitteilen).

Danke für Deine Hilfe!

typhos

@Ephi Danke für die ausführlichen Antworten, damit kann ich schon einiges eingrenzen.

Was deine Ausgabe zeigt

Der Ton kommt bei go2rtc an. go2rtc hat von der Kamera 93 AAC-Pakete (16 kHz, mono) bekommen und alle 93 an den VLC weitergegeben. Das sind rund 6 Sekunden Ton, also genauso lange wie das Video bis dahin. Die Zeile „no audio within 5 seconds“ steht auch nicht im Log. Adapter und go2rtc lassen den Ton also nicht weg.
Bei der Pan&Tilt hörst du den Ton im Browser, im VLC aber nicht. Es sind dieselben Daten, nur ein anderer Player. Das spricht dafür, dass der VLC die Tonspur aus dem RTSP-Stream nicht abspielt.
Bei den S340 hörst du auch im Browser nichts, obwohl Tondaten ankommen. Ich vermute, dass die Kamera auf diesem Weg stille Tondaten schickt. Sicher sagen kann ich das aber erst mit einer Aufnahme.

Zwei Tests bitte

VLC ohne RTSP: Öffne im VLC als Netzwerkstream
http://<IP-des-ioBroker>:1984/api/stream.mp4?src=<Seriennummer der Pan&Tilt>
Hörst du dort etwas? Wenn ja, liegt es am Zusammenspiel von VLC und RTSP und nicht an der Kamera.
Aufnahme einer S340: Ruf im Browser
http://<IP-des-ioBroker>:1984/api/stream.mp4?src=<Seriennummer der S340>&duration=15&filename=s340.mp4
auf und sprich währenddessen vor der Kamera. Der Browser lädt dann 15 Sekunden als Datei herunter. Hör kurz rein, ob etwas zu hören ist, und schick mir die Datei, gern per PN oder als Cloud-Link, falls das Forum sie nicht annimmt. Daran sehe ich, ob in der Tonspur überhaupt etwas steckt.

Zum Schwarzbild

Im Log gibt es in dieser Zeit keinen Neustart des Streams, der Adapter liefert also durchgehend. Tritt das Schwarzbild auch im Browser auf oder nur im VLC? Wenn nur im VLC, tippe ich darauf, dass der VLC dort Bild und Ton neu synchronisiert.

Ephi

@typhos

Erst einmal vielen Dank für Deine tolle Analyse!

Ich habe jetzt gerade auf die Schnelle schon mal den ersten Test durchgeführt: Wenn ich den http://-Netzwerkstream im VLC-Player so öffne, wie Du Ihn mir hier vorgegeben hast, höre ich über alle drei Kameras Ton auch über VLC. Es scheint also tatsächlich am Zusammenspiel VLC und RTSP zu liegen.

Wenn ich die http://-Streams im VLC-Player öffne, kommt es zu der von mir beschriebenen Bildunterbrechung in etwas anderer Form daher als in der Variante RTSP-Stream im VLC-Player. Dann sieht man nämlich kein Schwarzbild, sondern ein verpixeltes, meist grünliches Bild, was nach ein paar Sekunden wieder normal wird. Das tritt nur bei den S340-Außenkameras auf (also bei den Batterie- bzw. Solarpanel-betriebenen Kameras). Bei der Pan&Tilt-Innenkamera gibt es weder ein Schwarzbild noch Bildunterbrechungen (diese ist eine leitungsgebundene Kamera).

Ich hoffe, ich kann Dir morgen noch eine Aufnahme zusenden, bei der man die grünliche Verpixelung sehen kann. Heute ist es dafür schon etwas zu spät…

Ephi

@typhos

Du hast eine PN von mir mit dem Video. Bezüglich der dort ebenfalls zu sehenden Bildstörungen habe ich das Gefühl, dass diese durch mehrfache Änderung der Auflösung erfolgen. Vielleicht kannst Du ja etwas damit anfangen. Danke für Deine Hilfe.

typhos

@Ephi Danke für das Video und den VLC-Test, damit ist das Bild jetzt ziemlich klar.

Ton über RTSP

Über stream.mp4 hörst du im VLC alle drei Kameras. Adapter und go2rtc liefern den Ton also. Dass er über RTSP fehlt, liegt am VLC: Er bekommt die Tonspur, spielt sie aber nicht ab. Nimm im VLC am besten den http-Link statt RTSP:

http://<IP-des-ioBroker>:1984/api/stream.mp4?src=<Seriennummer>

Ton der S340

In deiner Aufnahme ist eine Tonspur mit Inhalt, sie ist aber sehr leise. Der Grundpegel liegt bei etwa -65 dB. Zwischen Sekunde 4 und 8 und gegen Ende steigt er auf etwa -40 dB, die lauteste Stelle erreicht -26 dB. Bei normaler Lautstärke hört man davon kaum etwas. Dreh beim Abspielen der Datei einmal ganz auf: Hörst du dann etwas?

Grünes Bild und Schwarzbild

Dein Gefühl stimmt, die Auflösung ändert sich mehrmals. In der Aufnahme startet die S340 mit 1280x720, wechselt nach 4,1 Sekunden auf 1920x1080 und nach 8,3 Sekunden auf 2880x1616. Das passt zu deinen Beobachtungen: VLC über RTSP zeigt 4-5 Sekunden nach dem ersten Bild ein Schwarzbild, und über http wird das Bild für ein paar Sekunden grün und verpixelt. Die Kamera schickt die Bilder sauber, das habe ich Bild für Bild geprüft. Die Player kommen aber mit einer Auflösung, die sich mitten im Stream ändert, nicht zurecht.

Das passiert, wenn die Streaming-Qualität der Kamera auf „Auto“ steht. Die Pan&Tilt ist davon nicht betroffen, wahrscheinlich steht sie auf einer festen Qualität.

Abhilfe: Stell bei jeder S340 eine feste Qualität ein, entweder in der eufy-App oder im Objektbaum über den Datenpunkt video_streaming_quality der Kamera:

1 = HD (720P)
2 = Full HD (1080P)
3 = 3K HD

Die Einstellung „Livestream-Qualität“ in der Adapter-Konfiguration greift bei der S340 bisher nicht. Sie kennt nur Niedrig/Mittel/Hoch, die S340 benennt ihre Stufen aber nach der Auflösung. Ab der nächsten Version gilt sie auch für solche Kameras: Niedrig ist dann 720P, Mittel 1080P und Hoch 3K. Bis dahin hilft der Datenpunkt oder die eufy-App.

Sag gern Bescheid, ob mit fester Qualität das Schwarzbild und das grüne Bild verschwinden.

Ephi

@typhos sagte:

Abhilfe: Stell bei jeder S340 eine feste Qualität ein, entweder in der eufy-App oder im Objektbaum über den Datenpunkt video_streaming_quality der Kamera

Erst einmal vielen Dank. Das komische ist, dass sowohl in der Eufy-App als auch im Objektbaum die Qualität bereits fest auf 3K HD eingestellt ist. Ich kann dementsprechend hier nichts mehr verändern. Ich habe jetzt nochmals zunächst auf Auto und dann nochmals fest auf 3K HD umgestellt. Das Verhalten bleibt aber gleich...

typhos

@Ephi Danke fürs Nachsehen, dann lag ich bei der S340 falsch. Wenn sie schon fest auf 3K HD steht, erhöht sie die Auflösung beim Start jedes Livestreams offenbar selbst: erst 720p, dann 1080p, dann 3K. Am Adapter kann ich das nicht abstellen, und die Änderung an der Livestream-Qualität aus meinem letzten Beitrag hilft bei der S340 deshalb auch nicht.

Was helfen sollte: der Kompatibilitäts-Stream

Trag in der Adapter-Konfiguration unter „Geräte mit Kompatibilitäts-Stream“ die Seriennummern der beiden S340 ein. Dann rechnet go2rtc den Stream mit ffmpeg auf 720p H.264 um. ffmpeg kommt mit den Wechseln der Auflösung zurecht, und der Player bekommt durchgehend dasselbe Bildformat. Ich habe das mit deiner Aufnahme nachgestellt: Nach dem Umrechnen haben alle Bilder 1280x720.

Der Stream heißt dann <Seriennummer>_compat. Die Datenpunkte livestream und livestream_rtsp der Kamera zeigen danach automatisch darauf. Im VLC entsprechend:

http://<IP-des-ioBroker>:1984/api/stream.mp4?src=<Seriennummer>_compat

Zwei Einschränkungen:

Das Bild hat dann nur 720p, und das Umrechnen kostet CPU auf dem ioBroker-Rechner, solange jemand zuschaut.
In 3.5.0 kann ein Kompatibilitäts-Stream hängen bleiben, nachdem ein Player ihn geschlossen hat. Dann hilft nur ein Neustart des Adapters. Das ist für die nächste Version behoben.

Probier es gern aus und sag Bescheid, ob das grüne Bild und das Schwarzbild damit weg sind.

Ephi

@typhos sagte:

Probier es gern aus und sag Bescheid, ob das grüne Bild und das Schwarzbild damit weg sind.

Hab es gerade ausprobiert. In der Tat sind die Bildstörungen damit weg, allerdings kommt über den Kompatibilitäts-Stream jetzt kein Ton mehr. Habe es mehrfach gestartet, immer eindeutig ohne Ton, obwohl die Tonspur aktiviert ist im VLC-Player.

Edit: Wenn ich den normalen Stream wie bisher aufrufe ist der Ton eindeutig zu hören, nur halt mit den bekannten Bildstörungen.

Edit 2: Wenn ich den _compat-Stream im Browser öffne ist ein Ton zu hören, nicht jedoch im VLC-Player... Scheinbar hat der VLC-Player doch deutliche Probleme mit dem Ton, je nach Streamquelle. Schade, dass es offenbar keine Lösung gibt, bei der alle Probleme behoben sind. Oder hast Du noch eine Idee?

typhos

@Ephi Danke fürs Testen, das hat geholfen. Ich konnte das mit meiner eigenen Kamera nachstellen: Auch bei mir kommt über den Kompatibilitäts-Stream im VLC kein Ton.

Ursache: Beim Umrechnen beginnt das Bild 2 bis 4 Sekunden vor dem Ton. ffmpeg füllt den Anfang des Videos mit wiederholten Bildern auf, damit die Bildrate konstant bleibt. Danach laufen Bild und Ton im Stream die ganze Zeit um diesen Abstand versetzt. Der Browser puffert und spielt den Ton trotzdem ab, VLC verwirft ihn als zu spät. Beim normalen Stream gibt es den Versatz nicht, deshalb hast du dort Ton.

Behoben habe ich das, indem ffmpeg die Zeitstempel des Bildes so lässt, wie sie von der Kamera kommen. Damit liegen Bild und Ton bei mir wieder gleichauf, und der Kompatibilitäts-Stream hat weiterhin durchgehend 720p. Die Änderung kommt mit der nächsten Version, zusammen mit der Korrektur gegen das Hängenbleiben des Kompatibilitäts-Streams.

Bis dahin: Mit Ton und ohne Bildstörungen geht es nur über den Kompatibilitäts-Stream im Browser. Falls dir dort auffällt, dass der Ton nicht zum Bild passt, liegt das am selben Versatz und ist mit der nächsten Version ebenfalls weg.

Ephi

@typhos

Super, Danke für deine Mühen!

Community Forum

NEWS

Test Adapter eusec 3.x.x

Support us

230

33.1k

84.1k

1.4m