go2rtc
go2rtc copied to clipboard
AlexxIT
2-way audio with Dahua CGI HTTP interface
Hello,
I have a Dahua VTO2202F-P-S2 which unfortunately doesn't support the ONVIF Profile T (at least it didn't work in my tests).
I wonder if it's reasonable to suggest supporting additional methods for playing the audio in the camera/doorbell. For example, this doorbell exposes a small API which allows me to play audio on it:
https://s3.amazonaws.com/amcrest-files/AMCREST_CGI_SDK_API.pdf (search for Post Audio)
I can reproduce it with something like:
curl --digest -verbose --request POST --url 'http://admin:[email protected]/cgi-bin/audio.cgi?action=postAudio&httptype=singlepart&channel=1' --header 'Content-Type: Audio/G.711A' --data-binary '@DoorBell.wav'
So I wonder if it should be possible to pipe the audio from browser to this API in order to achieve 2-way audio.
- Refs https://github.com/AlexxIT/go2rtc/issues/49#issuecomment-1252946386
/cc @luzik
Yeah, latency i low and we are ready to build video doorbell intercom. Switching audio codec is required. Please refer https://github.com/blakeblackshear/frigate/discussions/2572
Sometimes it's unnecessary to have Profile T. Camera just should response in RTSP SDP that it have separate media for back audio. You can enable rtsp trace logs for check it. Or you can see it in info link, like in this comment #49
This is what I have:
streams:
"vto":
- rtsp://admin:[email protected]/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
- ffmpeg:rtsp://admin:[email protected]/cam/realmonitor?channel=1&subtype=0#audio=opus
[
{
"media:0": "video, sendonly, 96 H264/90000",
"media:1": "audio, sendonly, 97 L16/16000",
"media:2": "application, sendonly, 107 VND.ONVIF.METADATA/90000",
"media:3": "audio, recvonly, 97 L16/16000",
"receive": 213012,
"remote_addr": "192.168.1.40:554",
"send": 0,
"track:0": "96 H264/90000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://192.168.1.40:554/cam/realmonitor?channel=1\u0026subtype=0\u0026unicast=true\u0026proto=Onvif/"
},
{
"media:0": "audio, sendonly, 96 OPUS/48000/2",
"receive": 16808,
"remote_addr": "[::1]:43964",
"send": 0,
"track:0": "96 OPUS/48000/2, sinks=1",
"type": "RTSP server producer",
"url": "rtsp://localhost:8554/c17fa603dd6051c1a9da4cc4981af203",
"user_agent": "Lavf59.16.100"
},
{
"remote_addr": "udp4 host 192.168.1.15:56431",
"send": 230073,
"type": "WebRTC server consumer",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
}
]
But no audio is played back in the doorbell.
Switching audio codec is required. Please refer https://github.com/blakeblackshear/frigate/discussions/2572
@luzik Right, I know it (since it was I that wrote it). But on my tests, it makes no difference. It does not matter which codec I select. Can you please elaborate it a little? My firmware seems to be very similar to yours.
Wow, it actually works! I just needed to select G.711 8000 instead of 16000:
For completeness this is my final go2rtc configuration:
streams:
vto:
- rtsp://admin:[email protected]/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
@felipecrs I am using the Amcrest AD410, my audio options are:
So far I have tried AAC and G.711A without success, but I have suspicion that my reverse proxy may not be working fully since the webrtc stream itself is also not showing
It should be G.711A with Sampling Frequency of 8000. Do you have the option of setting the sampling frequency?
I was previously trying with 16000 too, but it only works with 8000.
In the go2rtc WebUI, when you click in Info for your camera stream, it should show what's the current sampling frequency there. Feel free to share the info here.
As far as I can tell there is no option in Amcrest Surveillance Pro to adjust the sampling rate, this is my debug info:
[
{
"media:0": "video, sendonly, 96 H264/90000",
"media:1": "audio, sendonly, 8 PCMA/8000",
"media:2": "application, sendonly, 107 VND.ONVIF.METADATA/90000",
"media:3": "audio, recvonly, 104 MPEG4-GENERIC/16000, 103 MPEG4-GENERIC/8000, 102 PCMU/16000, 0 PCMU/8000, 101 L16/16000, 97 L16/8000, 100 PCMA/16000, 8 PCMA/8000",
"receive": 177552130,
"remote_addr": "192.168.50.151:554",
"send": 0,
"track:0": "8 PCMA/8000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://192.168.50.151:554/cam/realmonitor?channel=1\u0026subtype=0\u0026proto=Onvif/"
},
{
"media:0": "video, recvonly, 96 H264/90000",
"media:1": "audio, recvonly, 97 PCMA/8000",
"receive": 0,
"remote_addr": "172.17.0.11:44376",
"send": 177544162,
"track:0": "97 PCMA/8000, sinks=1",
"type": "RTSP server consumer",
"url": "rtsp://192.168.50.106:8554/front_doorbell_cam",
"user_agent": "Lavf59.27.100"
}
]
Interesting, your "media:3" contains lots of codecs, including the desired one (PCMA/8000). I don't know how to interpret this, maybe @AlexxIT knows.
This is mine, btw:
[
{
"media:0": "video, sendonly, 96 H264/90000",
"media:1": "audio, sendonly, 0 PCMU/8000",
"media:2": "application, sendonly, 107 VND.ONVIF.METADATA/90000",
"media:3": "audio, recvonly, 0 PCMU/8000",
"receive": 607585,
"remote_addr": "192.168.1.40:554",
"send": 29520,
"track:0": "0 PCMU/8000, sinks=1",
"track:1": "0 PCMU/8000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://192.168.1.40:554/cam/realmonitor?channel=1\u0026subtype=0\u0026unicast=true\u0026proto=Onvif/"
},
{
"receive": 26240,
"remote_addr": "udp4 host 192.168.1.15:52633",
"send": 608578,
"type": "WebRTC server consumer",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
}
]
Here is what it looks like when I set the encoding to AAC:
[
{
"media:0": "video, sendonly, 96 H264/90000",
"media:1": "audio, sendonly, 97 MPEG4-GENERIC/8000",
"media:2": "application, sendonly, 107 VND.ONVIF.METADATA/90000",
"media:3": "audio, recvonly, 104 PCMU/16000, 0 PCMU/8000, 103 PCMA/16000, 8 PCMA/8000, 102 L16/16000, 101 L16/8000, 100 MPEG4-GENERIC/16000, 97 MPEG4-GENERIC/8000",
"receive": 54114512,
"remote_addr": "192.168.50.151:554",
"send": 0,
"track:0": "97 MPEG4-GENERIC/8000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://192.168.50.151:554/cam/realmonitor?channel=1\u0026subtype=0\u0026proto=Onvif/"
},
{
"media:0": "video, recvonly, 96 H264/90000",
"media:1": "audio, recvonly, 97 MPEG4-GENERIC/8000",
"receive": 0,
"remote_addr": "172.17.0.11:38860",
"send": 54112016,
"track:0": "97 MPEG4-GENERIC/8000, sinks=1",
"type": "RTSP server consumer",
"url": "rtsp://192.168.50.106:8554/front_doorbell_cam",
"user_agent": "Lavf59.27.100"
}
]
added unicast
[
{
"media:0": "video, sendonly, 96 H264/90000",
"media:1": "audio, sendonly, 97 MPEG4-GENERIC/8000",
"media:2": "application, sendonly, 107 VND.ONVIF.METADATA/90000",
"media:3": "audio, recvonly, 104 PCMU/16000, 0 PCMU/8000, 103 PCMA/16000, 8 PCMA/8000, 102 L16/16000, 101 L16/8000, 100 MPEG4-GENERIC/16000, 97 MPEG4-GENERIC/8000",
"receive": 11451207,
"remote_addr": "192.168.50.151:554",
"send": 0,
"track:0": "97 MPEG4-GENERIC/8000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://192.168.50.151:554/cam/realmonitor?channel=1\u0026subtype=0\u0026unicast=true\u0026proto=Onvif/"
},
{
"media:0": "video, recvonly, 96 H264/90000",
"media:1": "audio, recvonly, 97 MPEG4-GENERIC/8000",
"receive": 0,
"remote_addr": "172.17.0.11:55786",
"send": 11450631,
"track:0": "97 MPEG4-GENERIC/8000, sinks=1",
"type": "RTSP server consumer",
"url": "rtsp://192.168.50.106:8554/front_doorbell_cam",
"user_agent": "Lavf59.27.100"
}
]
and with G.711U:
[
{
"media:0": "video, sendonly, 96 H264/90000",
"media:1": "audio, sendonly, 0 PCMU/8000",
"media:2": "application, sendonly, 107 VND.ONVIF.METADATA/90000",
"media:3": "audio, recvonly, 104 MPEG4-GENERIC/16000, 103 MPEG4-GENERIC/8000, 102 PCMA/16000, 8 PCMA/8000, 101 L16/16000, 97 L16/8000, 100 PCMU/16000, 0 PCMU/8000",
"receive": 49855998,
"remote_addr": "192.168.50.151:554",
"send": 0,
"track:0": "0 PCMU/8000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://192.168.50.151:554/cam/realmonitor?channel=1\u0026subtype=0\u0026unicast=true\u0026proto=Onvif/"
},
{
"media:0": "video, recvonly, 96 H264/90000",
"media:1": "audio, recvonly, 97 PCMU/8000",
"receive": 0,
"remote_addr": "172.17.0.11:53156",
"send": 49853694,
"track:0": "97 PCMU/8000, sinks=1",
"type": "RTSP server consumer",
"url": "rtsp://192.168.50.106:8554/front_doorbell_cam",
"user_agent": "Lavf59.27.100"
}
]
I am using the Amcrest AD410
My AD410 works fine with the default G.711U. No need to mess with the frequency.
@NickM-27 I'm using an Amcrest AD410 with this, I've got my audio encode set to G.711A via the Amcrest Surveillance Pro app.
This is the info output for my setup with the 2-way audio:
[
{
"media:0": "video, sendonly, 96 H264/90000",
"media:1": "audio, sendonly, 8 PCMA/8000",
"media:2": "audio, recvonly, 8 PCMA/8000",
"receive": 650155,
"remote_addr": "192.168.0.25:554",
"send": 18232,
"track:0": "8 PCMA/8000, sinks=1",
"track:1": "8 PCMA/8000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://192.168.0.25:554/cam/realmonitor?channel=1\u0026subtype=0\u0026/"
},
{
"receive": 16960,
"remote_addr": "udp4 host 192.168.0.60:64688",
"send": 651354,
"type": "WebRTC server consumer",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Firefox/104.0"
}
]
That's really weird then, wonder why mine is different.
What URL are y'all using and what does the full encode look like? This is my current settings
This is the encode screen for the AD410 that works for me. Its actually G.711U on mine.
So the other thing is I had an unrelated issue with my AD410 that required amcrest support to send me newer firmware (dated 2021-06-10). I wonder if that explains the differences here.
Mine is till 2021-02-20
[
{
"media:0": "video, sendonly, 96 H264/90000",
"media:1": "audio, sendonly, 0 PCMU/8000",
"media:2": "application, sendonly, 107 VND.ONVIF.METADATA/90000",
"media:3": "audio, recvonly, 104 MPEG4-GENERIC/16000, 103 MPEG4-GENERIC/8000, 102 PCMA/16000, 8 PCMA/8000, 101 L16/16000, 97 L16/8000, 100 PCMU/16000, 0 PCMU/8000",
"receive": 5408228,
"remote_addr": "10.100.1.x:554",
"send": 89460,
"track:0": "0 PCMU/8000, sinks=1",
"track:1": "8 PCMA/8000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://10.100.1.143:554/cam/realmonitor?channel=1\u0026subtype=0\u0026unicast=true\u0026proto=Onvif/"
},
{
"receive": 79520,
"remote_addr": "udp4 host 10.100.1.x:44734",
"send": 5401282,
"type": "WebRTC server consumer",
"user_agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"
}
]
Mine is till 2021-02-20
Okay cool, that's what mine looks like so it probably isn't that then. Given that it is not working, seems it is my reverse proxy using cloudflare tunnel (which also doesn't show a webRTC feed, but does show the recording light on the browser tab).
I use cloudflare as well. I don't use the cloudflared addon. I have it setup myself.
Were you playing around with sending audio snips to the bell? I've had that hang the port before if timeouts weren't set properly. Maybe just try rebooting the bell...
but does show the recording light on the browser tab
That really isn't meaningful though. That will turn on by accessing any stream in go2rtc right now.
I have everything running in native docker. I have a cloudflare tunnel which points to nginx proxy manager which points to the docker container port 1984
2-way audio works just fine for me. :)
Does the camera stream work for you? Either way that is good to know.
Were you playing around with sending audio snips to the bell? I've had that hang the port before if timeouts weren't set properly. Maybe just try rebooting the bell...
I have before but not recently, restarted anyway and will give it another go.
That really isn't meaningful though. That will turn on by accessing any stream in go2rtc right now.
You might be referring to something different. The light on macOS showing that the mic is being used doesn't turn on when viewing via local, or any other stream type with remote besides webRTC.
Does the camera stream work for you? Either way that is good to know.
Yeah, 100%
You might be referring to something different. The light on macOS showing that the mic is being used doesn't turn on when viewing via local, or any other stream type with remote besides webRTC.
When using go2rtc, it will always request your microphone even if not using. Don't trust it.
You might be referring to something different. The light on macOS showing that the mic is being used doesn't turn on when viewing via local, or any other stream type with remote besides webRTC.
I was just saying that viewing any go2rtc stream (2 way audio or not) the permission request will happen which means the light will turn on.
@felipecrs <- what he said
Yeah, 100%
Okay, well the fact that my stream doesn't work means that is probably why 2-way talk doesn't work either. I will work on fixing that.
When using go2rtc, it will always request your microphone even if not using. Don't trust it.
I was just saying that viewing any go2rtc stream (2 way audio or not) the permission request will happen which means the light will turn on.
Thanks, other streams like MSE don't pull the microphone audio is what I meant. But yeah I tried webRTC from another camera which doesn't support this and it still does use the microphone so my bad on that one