WebRTC
WebRTC copied to clipboard
Webrtc card doesn't always stop/disconnect stream
The battery of my Aqara G4 doorbell drained over night after setting up webrtc card.
Home assistant and go2rtc are running in containers on same host.
HA Core version 2024.6.4 WebRTC v3.6.0
go2rtc config:
log:
level: debug
hass:
config: "/config"
streams:
Doorbell-Repeater-50CF:
- homekit://IP:37345?blabla
- ffmpeg:Doorbell-Repeater-50CF#audio=opus
homekit:
Doorbell-Repeater-50CF:
log:
08:33:18.399 info go2rtc version=1.9.7 platform=linux/amd64 revision=dbe9e4a
08:33:18.400 debug build version=go1.22.9 vcs.time=2024-11-11T17:20:53Z
08:33:18.400 info config path=/config/go2rtc.yaml
08:33:18.400 info [api] listen addr=:1984
08:33:18.400 info [rtsp] listen addr=:8554
08:33:18.400 info [webrtc] listen addr=:8555/tcp
08:33:18.401 debug [hass] load config url=hass:127_0_0_1
08:33:18.401 debug [hass] load config url=hass:Doorbell Repeater-50CF
20:12:04.823 debug [webrtc] new consumer src=Doorbell-Repeater-50CF
20:12:06.393 debug [ffmpeg] bin version=6.1.1 libavformat=60. 16.100
20:12:06.393 debug [exec] run rtsp args=ffmpeg,-hide_banner,-v,error,-fflags,nobuffer,-flags,low_delay,-timeout,5000000,-user_agent,go2rtc/ffmpeg,-rtsp_flags,prefer_tcp,-i,rtsp://127.0.0.1:8554/Doorbell-Repeater-50CF?audio&source=ffmpeg:Doorbell-Repeater-50CF%23audio%3Dopus,-c:a,libopus,-application:a,lowdelay,-min_comp,0,-vn,-user_agent,ffmpeg/go2rtc,-rtsp_transport,tcp,-f,rtsp,rtsp://127.0.0.1:8554/ID
20:12:06.434 debug [rtsp] new consumer stream=Doorbell-Repeater-50CF
20:12:06.435 debug [streams] start producer url=homekit://IP:37345?
20:12:08.450 debug [exec] run rtsp launch=2.057050391s
20:12:08.450 debug [streams] start producer url=ffmpeg:Doorbell-Repeater-50CF#audio=opus
20:13:12.584 debug [streams] stop producer url=ffmpeg:Doorbell-Repeater-50CF#audio=opus
20:13:12.587 debug [rtsp] handle error=EOF
20:13:12.587 debug [streams] stop producer url=homekit://IP:37345?
20:13:12.587 debug [rtsp] disconnect stream=Doorbell-Repeater-50CF
20:18:40.717 debug [webrtc] new consumer src=Doorbell-Repeater-50CF
20:18:41.962 debug [exec] run rtsp args=ffmpeg,-hide_banner,-v,error,-fflags,nobuffer,-flags,low_delay,-timeout,5000000,-user_agent,go2rtc/ffmpeg,-rtsp_flags,prefer_tcp,-i,rtsp://127.0.0.1:8554/Doorbell-Repeater-50CF?audio&source=ffmpeg:Doorbell-Repeater-50CF%23audio%3Dopus,-c:a,libopus,-application:a,lowdelay,-min_comp,0,-vn,-user_agent,ffmpeg/go2rtc,-rtsp_transport,tcp,-f,rtsp,rtsp://127.0.0.1:8554/ID
20:18:42.003 debug [rtsp] new consumer stream=Doorbell-Repeater-50CF
20:18:42.003 debug [streams] start producer url=homekit://IP:37345?
20:18:43.784 debug [exec] run rtsp launch=1.822400997s
20:18:43.784 debug [streams] start producer url=ffmpeg:Doorbell-Repeater-50CF#audio=opus
20:19:18.114 debug [streams] stop producer url=ffmpeg:Doorbell-Repeater-50CF#audio=opus
20:19:18.116 debug [rtsp] handle error=EOF
20:28:09.387 debug [webrtc] new consumer src=Doorbell-Repeater-50CF
20:29:36.689 debug [webrtc] new consumer src=Doorbell-Repeater-50CF
You can check active streams in the go2rtc WebUI.
Yes, the stream was still active after I closed the HA tab with webrtc card. I checked both streams tab and network tab and it was active.
EDIT: Streams and network tabs in go2rtc webui
Show stream info
I will reproduce and get that for you when I'm back home. Thanks!
Last night I made sure that last print in log was "[rtsp] disconnect" and the doorbell did not drain battery.
Also, when I reproduced it twice yesterday it was solved by restarting go2rtc the first time but the second time go2rtc started the stream directly after restart. The second time it was solved by restarting HA.
{
"producers": [
{
"id": 40,
"format_name": "homekit",
"protocol": "udp",
"remote_addr": "192.168.1.108:37345",
"source": "homekit://192.168.1.108:37345?client_id=b34e818d-5563-4b01-8d51-3d3acf3701ee\u0026client_private=09c45b60c04b573dde7c6afc9453f2cad6a30ce4ff56179224d9a539f767d42aae846454abb6af7070b2443a55e31e3e5f183ea55d268cc27f94d383de70000e\u0026device_id=66:7B:EC:3A:39:18\u0026device_public=91992ca6f61679b3426ffb60eb32a48c74d2f7089e73c5fd70d621d879024094",
"sdp": "{Codecs:[{CodecType:0 CodecParams:[{ProfileID:[1] Level:[0 2] PacketizationMode:0 CVOEnabled:[] CVOID:[]}] VideoAttrs:[{Width:1920 Height:1080 Framerate:30} {Width:1280 Height:720 Framerate:30} {Width:640 Height:360 Framerate:30} {Width:480 Height:270 Framerate:30} {Width:320 Height:180 Framerate:30} {Width:1280 Height:960 Framerate:30} {Width:1024 Height:768 Framerate:30} {Width:640 Height:480 Framerate:30} {Width:480 Height:360 Framerate:30} {Width:320 Height:240 Framerate:30}] RTPParams:[]}]}\n{Codecs:[{CodecType:2 CodecParams:[{Channels:1 Bitrate:0 SampleRate:[1] RTPTime:[]}] RTPParams:[] ComfortNoise:[]}] ComfortNoise:0}",
"medias": [
"video, recvonly, H264",
"audio, recvonly, ELD/16000/1",
"video, recvonly, JPEG"
],
"receivers": [
{
"id": 41,
"codec": {
"codec_name": "h264",
"codec_type": "video"
},
"childs": [
189,
244
],
"bytes": 1286001473,
"packets": 973416
},
{
"id": 45,
"codec": {
"channels": 1,
"codec_name": "aac/eld",
"codec_type": "audio",
"sample_rate": 16000
},
"bytes": 20479471,
"packets": 83348
}
],
"bytes_recv": 1306480944,
"Bitrate": 0
},
{
"id": 47,
"format_name": "rtsp",
"protocol": "rtsp+tcp",
"remote_addr": "127.0.0.1:46300 forwarded 127.0.0.1:18554",
"source": "exec:ffmpeg -hide_banner -v error -fflags nobuffer -flags low_delay -timeout 5000000 -user_agent go2rtc/ffmpeg -rtsp_flags prefer_tcp -i rtsp://127.0.0.1:18554/Doorbell-Repeater-50CF?audio\u0026source=ffmpeg:Doorbell-Repeater-50CF%23audio%3Dopus -c:a libopus -application:a lowdelay -min_comp 0 -vn -user_agent ffmpeg/go2rtc -rtsp_transport tcp -f rtsp rtsp://127.0.0.1:18554/957c702b959bf642a2e3f99d020b138b",
"url": "rtsp://127.0.0.1:18554/Doorbell-Repeater-50CF?audio\u0026source=ffmpeg:Doorbell-Repeater-50CF%23audio%3Dopus",
"sdp": "v=0\r\no=- 0 0 IN IP4 127.0.0.1\r\ns=go2rtc/1.9.7\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\na=tool:libavformat 60.16.100\r\nm=audio 0 RTP/AVP 96\r\nb=AS:64\r\na=rtpmap:96 opus/48000/2\r\na=control:streamid=0\r\n",
"user_agent": "ffmpeg/go2rtc",
"medias": [
"audio, recvonly, OPUS/48000/2"
],
"receivers": [
{
"id": 48,
"codec": {
"channels": 2,
"codec_name": "opus",
"codec_type": "audio",
"sample_rate": 48000
},
"bytes": 111576,
"packets": 780
}
],
"bytes_recv": 121048
}
],
"consumers": [
{
"id": 44,
"format_name": "rtsp",
"protocol": "rtsp+tcp",
"remote_addr": "127.0.0.1:46290",
"source": "ffmpeg:Doorbell-Repeater-50CF#audio=opus",
"sdp": "v=0\r\no=- 1 1 IN IP4 0.0.0.0\r\ns=go2rtc/1.9.7\r\nc=IN IP4 0.0.0.0\r\nt=0 0\r\nm=audio 0 RTP/AVP 96\r\na=rtpmap:96 MPEG4-GENERIC/16000/1\r\na=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=f8ec3000\r\na=control:trackID=0\r\n",
"user_agent": "go2rtc/ffmpeg",
"medias": [
"audio, sendonly, ANY"
],
"senders": [
{
"id": 46,
"codec": {
"channels": 1,
"codec_name": "aac/eld",
"codec_type": "audio",
"sample_rate": 16000
},
"parent": 45,
"bytes": 128536,
"packets": 521
}
],
"bytes_send": 136872
}
]
}
Restarted go2rtc and stream is closed.
@AlexxIT I'm experiencing the same issue, this is a serious issue because for battery-powered devices this would lead to battery quickly running out of charge
@AlexxIT I noticed that ws server is instantiated with autoping and autoclose set to false; furthermore no heartbeat is configured. https://github.com/AlexxIT/WebRTC/blob/60ea122871566b0395ace7227c090fa05541c15d/custom_components/webrtc/init.py#L259 How exactly is the ws sessions closed?
You're looking at a part of the code that doesn't relate to the problem at all.
Same here.
I guess this issue comes from go2rtc, not the WebRTC Camera.
I found that when I closed the WebRTC Camera, my whep source did not stop the connection.
I repeatedly opened and closed the HA page and noticed that the data bandwidth kept increasing.
As far as I know, WebRTC should trigger a failed event if the client goes down, but it didn’t after we closed the player.
It seems that connection peers are not being properly released on the go2rtc side, causing unnecessary network traffic.
Same here. I guess this issue comes from
go2rtc, not theWebRTC Camera.I found that when I closed the
WebRTC Camera, my whep source did not stop the connection. I repeatedly opened and closed the HA page and noticed that the data bandwidth kept increasing. As far as I know, WebRTC should trigger a failed event if the client goes down, but it didn’t after we closed the player. It seems that connection peers are not being properly released on the go2rtc side, causing unnecessary network traffic.
Yep, I am also getting the same issue.
Quick update to confirm that the issue persists