AlexxIT
Dahua VTO support
Browser is asking for microphone permission, but no audio from VTO and unmute button is disabled
api:
base_path: "/go2rtc"
streams:
vto:
- rtsp://admin:[email protected]/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
[
{
"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": 824840,
"remote_addr": "192.168.124.30:554",
"send": 0,
"track:0": "96 H264/90000, sinks=1",
"type": "RTSP client producer",
"url": "rtsp://192.168.124.30:554/cam/realmonitor?channel=1\u0026subtype=0\u0026unicast=true\u0026proto=Onvif/"
},
{
"remote_addr": "udp4 host 192.168.123.33:63426",
"send": 826301,
"type": "WebRTC server consumer",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.4976.0 Safari/537.36"
}
]
v=0
o=- 8819968399131000794 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS mUTzunk2m8gOBSbMpIqZr9ZW7amqcT2Uu8h0
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 35 36 127 122 125 107 108 109 124 121 120 119 114 37
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:cSCj
a=ice-pwd:azQ5DYFApCx3rzPQWvEqknTA
a=ice-options:trickle
a=fingerprint:sha-256 2A:0A:DC:2B:B9:B5:CC:A3:07:E0:98:E7:B3:65:7A:2B:98:5E:AA:AE:0E:76:DB:71:3F:52:3D:E8:55:2B:F8:F7
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:102 VP9/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 profile-id=1
a=rtpmap:123 rtx/90000
a=fmtp:123 apt=102
a=rtpmap:35 AV1/90000
a=rtcp-fb:35 goog-remb
a=rtcp-fb:35 transport-cc
a=rtcp-fb:35 ccm fir
a=rtcp-fb:35 nack
a=rtcp-fb:35 nack pli
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=124
a=rtpmap:120 red/90000
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=120
a=rtpmap:114 ulpfec/90000
a=rtpmap:37 flexfec-03/90000
a=rtcp-fb:37 goog-remb
a=rtcp-fb:37 transport-cc
a=fmtp:37 repair-window=10000000
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:cSCj
a=ice-pwd:azQ5DYFApCx3rzPQWvEqknTA
a=ice-options:trickle
a=fingerprint:sha-256 2A:0A:DC:2B:B9:B5:CC:A3:07:E0:98:E7:B3:65:7A:2B:98:5E:AA:AE:0E:76:DB:71:3F:52:3D:E8:55:2B:F8:F7
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:mUTzunk2m8gOBSbMpIqZr9ZW7amqcT2Uu8h0 9654a211-5d7a-4500-8034-3b17b1c6c7a7
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:1443778823 cname:5sgtTCGio9Mf4sP8
a=ssrc:1443778823 msid:mUTzunk2m8gOBSbMpIqZr9ZW7amqcT2Uu8h0 9654a211-5d7a-4500-8034-3b17b1c6c7a7
a=ssrc:1443778823 mslabel:mUTzunk2m8gOBSbMpIqZr9ZW7amqcT2Uu8h0
a=ssrc:1443778823 label:9654a211-5d7a-4500-8034-3b17b1c6c7a7
6webrtc.html:1 Uncaught (in promise) DOMException: Failed to execute 'addIceCandidate' on 'RTCPeerConnection': The remote description was null
The camera is outputting a format that is incompatible with webrtc. Probably AAC. So transcode it to something webrtc friendly or go into your camera settings and change it to a compatible format. If its like my amcrest, you can change it to G.711 so you don't need to transcode.
Alternatively, this would work:
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&unicast=true&proto=Onvif#audio=opus
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/WebRTC_codecs#supported_audio_codecs
Both send and receive tracks has L16 codec.
L16 is not AAC, but also doesn't supported by WebRTC. It's possible to receive audio with transcoding via FFmpeg.
But send audio (from microphone) with transcoding is not supported yet.
So Dahua VTO2211G do not allow to change audio codec via browser UI. Maybe there is a way using ONVIF, GET param or dahua api ?
Documentation show that device support G.711Mu; G.711u; PCM audio compression https://www.dahuasecurity.com/my/products/All-Products/Video-Intercoms/IP-Series/Villa-Door-Station/Pro-Series/VTO2211G-WP
vlc shows it as PCM S16 BE (s16b) and ffprobe Stream #0:1: Audio: pcm_s16be, 16000 Hz, 1 channels, s16, 256 kb/s
VTO do accept audio via API in ulaw. I believe that VTO supporting g.711 while using SIP protocol
Hmm, interesting ..there is a way to change audio codec using Onvif
https://github.com/blakeblackshear/frigate/discussions/2572
There's likely a way to change it. I can't change it with Amcrest tools but I could change mine with this:
https://dahuawiki.com/ConfigTool
So yeah, it's working. I did used this Happytime onvif client and I hope this settings will stay for ever. If not I will reopen this issue, and ask for help with automating this change.
[ { "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": 8279516, "remote_addr": "192.168.124.30:554", "send": 993960, "track:0": "0 PCMU/8000, sinks=1", "track:1": "0 PCMU/8000, sinks=1", "type": "RTSP client producer", "url": "rtsp://192.168.124.30:554/cam/realmonitor?channel=1\u0026subtype=0\u0026unicast=true\u0026proto=Onvif/" }, { "receive": 883680, "remote_addr": "udp4 host 192.168.123.33:61346", "send": 8292693, "type": "WebRTC server consumer", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.5 Safari/605.1.15" } ]
Yeah, latency i low and we are ready to build video doorbell intercom, the only problem is to switch audio codec in programming way. I believe that this could be in scope of this project :)
It is possible to change parameters without onvif client. To get possible audio/video parameters: http://admin:[email protected]/cgi-bin/configManager.cgi?action=getConfig&name=Encode For example to change audio bitrate to 8khz: http://admin:[email protected]/cgi-bin/configManager.cgi?action=setConfig&Encode[0].MainFormat[0].Audio.Depth=8
I have VTO2211G. It should work on other models. ps: microphone in chrome doesn't work without https connection
That's a fantastic news for me, because my vto2211g did go to its defaults "L16/16000". Does go2rtc can give support for such behave ? ..I mean if camera returning L16 try such action and try reconnect
This approach is a little intrusive, perhaps some kind of automatic codec conversion would be a little better. Refs:
- #56
Yeah, You are right, but as conversion make use of CPU, maybe "force_vto_codec=true" is a way to go ?
I think the ideal solution would be to:
- Report the issue to Dahua, ask them to either make the audio codec selectable from the admin page or prevent it from reverting back to the original codec after some time
But I do understand that it's very unlikely that they would provide any support. Another option would be to look for alternative firmwares, like OpenIPC (which may be already compatible).
That's because, supposedly, this is a camera-specific requirement (other cameras/doorbells allows you to set the codec from their UI).
force_vto_codec=true
If I'm not mistaken, this is an ONVIF configuration (not something specific to VTO), which could potentially mean it would work for other cameras, from other manufactures even. Maybe a better name would be try_adjusting_onvif_audio_codec=true.
Since the VTO seems to retain the audio codec configuration for at least some days, a workaround for now is to create a script that fixes the codec and configure it to run automatically every day at midnight in Home Assistant, for example.
to change bitrate from console:
curl --digest -u "admin:pass" -g "http://192.168.1.110/cgi-bin/configManager.cgi?action=setConfig&Encode[0].MainFormat[0].Audio.Depth=8"
@felipecrs dahua stops stream when trying to change bitrate, but continue stream if bitrate is the same already. So I think it's better to execute script before start streaming in go2rtc.
I tried something like:
vto:
- exec:curl --digest -u "admin:pass" -g "http://192.168.1.110/cgi-bin/configManager.cgi?action=setConfig&Encode[0].MainFormat[0].Audio.Depth=8"
- rtsp://admin:[email protected]/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
vto:
- exec:curl --digest -u "admin:pass" -g "http://192.168.1.110/cgi-bin/configManager.cgi?action=setConfig&Encode[0].MainFormat[0].Audio.Depth=8";ffmpeg -i rtsp://admin:[email protected]/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif -vcodec copy -c copy -rtsp_transport tcp -f rtsp {output}
You can use echo source. This is bash script that should print (echo) link to the stream. So you can change codec there.
https://github.com/AlexxIT/go2rtc#source-echo
I wrote simple script to check bitrate parameter before start stream. I included sleep to give dahua time to restart rtsp stream.
#!/bin/bash
array=`curl -s --digest -u "admin:pass" -g "http://192.168.1.110/cgi-bin/configManager.cgi?action=getConfig&name=Encode"`
value="table.Encode[0].MainFormat[0].Audio.Depth=16"
if [[ " ${array[@]} " == *"$value"* ]]; then
curl -s --digest -u "admin:pass" -g "http://192.168.1.110/cgi-bin/configManager.cgi?action=setConfig&Encode[0].MainFormat[0].Audio.Depth=8"
sleep 2
fi
@AlexxIT if I add several strings to source block like
vto:
- echo: ....
- ffmpeg: ....
are there executed sequentially or it is bad idea?
@bonuzzz you need to convert them all to echo. For example, your first echo should return the rtsp stream string, your second one should return the ffmpeg stream string. (I think)
By the way, I don't know if my VTO is different than yours or not, but the setting I need to adjust is:
table.Encode[0].MainFormat[0].Audio.Frequency=16000
Instead of Depth=16
This seems to be working well for me. @luzik I suggest you try it too.
- Create the file
/config/scripts/get_vto_stream.sh - Place the following contents on it, replace the host and password with your values:
#!/bin/bash
creds="admin:pass"
host="192.168.1.40"
# Attempt to change sampling rate. It won't harm if it's already set.
curl --silent --digest --user "${creds}" --globoff \
"http://${host}/cgi-bin/configManager.cgi?action=setConfig&Encode[0].MainFormat[0].Audio.Frequency=8000" >&2
echo "rtsp://${creds}@${host}/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif"
- Give it execution permission:
chmod +x /config/scripts/get_vto_stream.sh - Set your
go2rtc.yaml:
streams:
vto:
- echo:/config/scripts/get_vto_stream.sh
@felipecrs
By the way, I don't know if my VTO is different than yours or not, but the setting I need to adjust is:
table.Encode[0].MainFormat[0].Audio.Frequency=16000Instead of Depth=16
Of course frequency. Thanks. I didn't always get mic working in chrome, so tested several options besides frequency. I have vto2211g model. I advice to add sleep command to your script between switching frequency and strart streaming, because dahua is not always finished restart own rtsp stream during 60 sec which go2rtc waits for them. And my script also checking current parameter. ps: 2 sec is just a sample there. may be it need more
Yeah, for me it's working fine this way (without the sleep). :)
https://user-images.githubusercontent.com/29582865/193347672-56102a1f-3a7a-43b8-ac9b-bfdf4e6b30c2.mp4
In the video you can see that the codec is wrong (in VLC). Then, opening the stream from go2rtc fixes it quickly. I'm sure it worked because I can hear myself from the microphone (which you can't hear in the video).
By the way I'm using the newest firmware released by Dahua, it's 2022-08-13 V4.600.0000000.0.R.
@felipecrs I have old 2021-07-14 V4.500.0000001.0.R could you send the link for new fw please?
saw your video again. you also didn't restart go2rtc. It's great
My model is different than yours...
Mine is:
https://www.dahuasecurity.com/products/All-Products/Video-Intercoms/IP-Series/Villa-Door-Station/Pro-Series/VTO2202F-P-S2
Yours is:
https://www.dahuasecurity.com/products/All-Products/Video-Intercoms/IP-Series/Villa-Door-Station/Pro-Series/VTO2211G-WP
(I think)
But there is a newer fw for you: V4.511.0000000.0.R.220523
Just head to the Downloads -> Firmware in the link above.
Thanks. I updated firmware, but unfortunately nothing is changed and audio/mic is not stable as I see in your video
I am using second stream as frigate source, and frequency change is not enough in my case, so I wrote simple one minute crontab with
curl -s --digest -u "admin:pass" -g "http://IP/cgi-bin/configManager.cgi?action=getConfig&name=Encode" |grep 'table.Encode.0..MainFormat.0..Audio.Compression=G711' || curl -s --digest -u "admin:pass" -g "http://IP/cgi-bin/configManager.cgi?action=setConfig&Encode[0].MainFormat[0].Audio.Compression=G711&Encode[0].MainFormat[0].Audio.Frequency=8000&Encode[0].ExtraFormat[0].Audio.Compression=AAC"