Dahua VTO support #49
Comments
|
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: 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 vlc shows it as PCM S16 BE (s16b) VTO do accept audio via API in ulaw. I believe that VTO supporting g.711 while using SIP protocol |
|
Are you sure you can't change codec via camera Web UI?
|
|
|
|
Hmm, interesting ..there is a way to change audio codec using Onvif |
|
There's likely a way to change it. I can't change it with Amcrest tools but I could change mine with this: |
|
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. [ |
|
@luzik is 2-way audio working for you? |
|
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. I have VTO2211G. It should work on other models. |
|
That's a fantastic news for me, because my vto2211g did go to its defaults "L16/16000". |
|
This approach is a little intrusive, perhaps some kind of automatic codec conversion would be a little better. Refs: |
|
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:
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).
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 |
|
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: |
|
You can use echo source. This is bash script that should print (echo) link to the stream. So you can change codec there. |
|
Wow. This is brilliant. The possibilities are endless! |
|
I wrote simple script to check bitrate parameter before start stream. I included sleep to give dahua time to restart rtsp stream. |
|
@AlexxIT if I add several strings to source block like are there executed sequentially or it is bad idea? |
|
@bonuzzz you need to convert them all to |
|
By the way, I don't know if my VTO is different than yours or not, but the setting I need to adjust is: Instead of Depth=16 |
|
This seems to be working well for me. @luzik I suggest you try it too.
#!/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"
streams:
vto:
- echo:/config/scripts/get_vto_stream.sh |
Of course frequency. Thanks. I didn't always get mic working in chrome, so tested several options besides frequency. |
|
@Heronimonimo I am just seeing your message now. Are not you missing the proper parameters in the RTSP link? Mine looks like this: And if I remove |
|
Info about Dahua url was in very first docs: |
@felipecrs check below, you just need to call the following URLs (on your browser for example): |
|
Hm... that's funny. When I call such endpoints |
@felipecrs appologies I just noticed the URLs were wrong.. can you check again? (edited above) |
|
Well, the only difference between you and me is that I set only Compression and Frequency, you also change Depth and Bitrate. Anyway. Let's see if things changes for you after the newest firmware. |
|
@felipecrs I can confirm that you need to change all of those to make a real change in the backchannel codec (i was trying to simplify before writing the post, and that's why it got broken). Did the firmware upgrade, 2 way audio seems to be working but didnt' confirm with the monitor (VTH5321GB) which I also upgraded since its late here. However, looks promising, since there's no more garbled sound coming from it (that's the problem I was having after changing the codec in the VTO). |
|
@felipecrs I'm curious, what is the second channel for and why do you change it to AAC? |
|
Oh, that's not necessary for you if you don't use Frigate. Frigate needs an AAC audio track for recordings. Adjusting the substream to output in AAC prevents me from having to do the conversion with ffmpeg and thus saves me some good CPU cycles. |
|
Hello, Can You send all of the Your config files? Like: |
|
Hi everyone - I have Dahua VTO2311R-WP doorbell and I'm struggling to achieve a solution like:
Is that configuration possible to achieve? I'm usually quite good with configuring stuff like that, but to be honest learning curve is a bit too steep over here for me, and I feel a bit lost 😄 Currently feature no 1 and 3 (frigate and DMSS) are up and running in my setup, so it's down to implementing feature no 2 without breaking behavior of the other ones 😛 Currently I have go2rtc version 1.7.1 installed with Frigate. My go2rtc config is: and the info from VTO: As far as I understand I have to change the audio codec? |
|
Working config for DHI-VTO2202F-P-S2 with 2 way audio on HD or SD, and SIP with 2 way audio+video: If you use the app for the VTO, these settings will be changed on demand and the go2rtc streams will break. Note the script uses different credentials for the configuration and for the stream. #!/bin/bash
set -euo pipefail
readonly admincreds='adminuser:adminpass'
readonly onvifcreds='onvifuser:onvifpass'
readonly host='192.168.0.123'
readonly path="${1}"
params=""
params+="&Encode[0].MainFormat[0].Audio.Compression=G.711A" # Chrome WebRTC backchannel codec restrictions.
params+="&Encode[0].MainFormat[0].Audio.Frequency=8000" # Chrome WebRTC backchannel codec restrictions.
params+="&Encode[0].MainFormat[0].Audio.Bitrate=64"
params+="&Encode[0].ExtraFormat[0].Audio.Compression=AAC" # For use with Frigate
params+="&Encode[0].ExtraFormat[0].Audio.Frequency=16000"
params+="&Encode[0].ExtraFormat[0].Audio.Bitrate=64"
params+="&Encode[0].MainFormat[0].Video.GOP=4" # Optional, read considerations
curl --fail --silent --show-error --digest --globoff --user "${admincreds}" \
"http://${host}/cgi-bin/configManager.cgi?action=setConfig${params}" >&2
echo "rtsp://${onvifcreds}@${host}${path}"streams:
vto_sd_2wayaudio:
# MainFormat: PCMA/8000, 2-way audio, H264
- echo:/config/vto_setup_stream.sh /cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
vto_hd_2wayaudio:
# ExtraFormat: H264. Must be first to be served to the client by default.
- echo:/config/vto_setup_stream.sh /cam/realmonitor?channel=1&subtype=1&unicast=true&proto=Onvif#media=video#backchannel=0
# MainFormat: PCMA/8000, 2-way audio, H264. Currently no way of disabling video stream while keeping 2 way audio?
- echo:/config/vto_setup_stream.sh /cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
vto_hd_frigate:
# ExtraFormat: MPEG4-GENERIC/16000, H264
- echo:/config/vto_setup_stream.sh /cam/realmonitor?channel=1&subtype=1&unicast=true&proto=Onvif#media=audio+video#backchannel=0You can of course reuse stream connections, but keep in mind backchannel will not be redirected. My personal configuration streams:
vto:
# ExtraFormat: MPEG4-GENERIC/16000 (ACC), H264. Frigate without transcoding.
- echo:/config/vto_setup_stream.sh /cam/realmonitor?channel=1&subtype=1&unicast=true&proto=Onvif#media=audio+video#backchannel=0
# Conversion from best source (ACC) to opus for WebRTC support.
- ffmpeg:vto#audio=opus#async
# MainFormat: PCMA/8000, 2-way audio, H264. 2 way audio last resort, so regular WebRTC or Frigate client does not block backchannel for other 2way audio client
- echo:/config/vto_setup_stream.sh /cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
vto_fast:
# MainFormat: PCMA/8000, 2-way audio, H264
- echo:/config/vto_setup_stream.sh /cam/realmonitor?channel=1&subtype=0&unicast=true&proto=OnvifConsiderations:In this camera MainStream is intended for low quality real time and ExtraStream (SubStream in the WebUI) for HD recording. Using 2 way audio:Only MainStream or ExtraStream can receive an audio stream at a given time. If you open a stream to MainStream and another one to ExtraStream, the second one will not have the audio backchannel, and you will have to both close the first one and reconnect the second one to switch. SIP is like a extra connection using MainStream, same quirks apply. If you use Frigate, make sure it is not using your 2 way audio channel with
|
|
This was a really great summary, @miguelangel-nubla. I am also hopeful that 2-way audio through CGI can help overcome some of these limitations, especially the need of configuring codecs, the slowness of backchannel audio stream, and perhaps even the concurrency problem. |
sorry I am somewhat of a newbe when it comes to go2rtc and all this so please baer with me. I have read this whole thread as well as others and still I have several questions. Doorbell: DHI-VTO2202F-P-S2 1.) I don't get at all where exactly to put the script - where exactly do I have to put it - when edit the yaml as you mentioned above go2rtc gives me 3 streams but whenever I click on one I get this shows the cam live with buttons for answering call and declining call as well as increase and decrease volume. this sort of works... Can someone please help me out. Thank you all for your understanding you're doing great work! |
|
I'd say 2-way audio with VTO just can't be done reliably right now with go2rtc. I'm also observing severe delays. Maybe this situation will improve with #52. |
|
well i would accept the delay as far as it is somewhat working |
|
i am sorry maybe i misunderstood - do you mean if i change the rtsp stream to multipart the 2 way audio might(?) work? |
|
No, I just said that maybe someday go2rtc will allow to perform 2-way audio through Dahua's CGI interface, and then it may work better. 2-way audio through backchannel with the VTO is already possible. Scroll up in the conversation, many people proposed working solutions. |
|
I need physical access to Dahua with this CGI. Tried to add support remotely without big success. |
|
If you tried to work with a VTO, I'd recommend you first try with a regular Dahua 2-way audio camera. VTO's firmware is a true mess. (I don't have any regular cameras though) |
If you happen to live in the neighborhood (so to say) I could send mine to you (if I get it back in working condition) |
|
Just to set expectations of newcomers to this thread: I am not aware of any reliable approach to use go2rtc (with something like WebRTC card) to replace a SIP-based system for 2-way audio communication with a Dahua VTO. Today I tried putting together everything I've learned about this to make it work (so far I have been using the SIP card as daily driver), and unfortunately I stumbled upon: #1133 |
|
@miguelangel-nubla, one thing I realized is that if I set: AAC to 8000Hz, the VTO will in fact serve 16000. If I set 16000 like you are doing, it will serve 32000Hz. I suggest you test it as well, I suppose your goal was to have AAC/16000 with your config above and not AAC/32000. So, I ended up with: Because:
Another realization is that restarting the doorbell is enough for it to reset back the audio codecs to the defaults. This is my current script for reference: #!/bin/bash
#
# This script fixes the VTO audio codecs before supplying the stream url to go2rtc.
#
# Examples:
#
# ./fix_vto_codecs.sh rtsp://user:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
# ./fix_vto_codecs.sh rtsp://user:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=1
#
set -euo pipefail
if [[ -n "${DEBUG:-}" ]]; then
set -x
fi
readonly vto_stream_url="${1}"
vto_host_with_creds="${vto_stream_url#"rtsp://"}"
vto_host_with_creds="${vto_host_with_creds%%"/"*}"
readonly vto_host_with_creds
query="action=setConfig"
# PCMA: good for webrtc and 2-way audio
query+="&Encode[0].MainFormat[0].Audio.Compression=G.711A"
# AAC: good for Frigate
query+="&Encode[0].ExtraFormat[0].Audio.Compression=AAC"
readonly query
curl --fail --silent --show-error --digest --globoff \
"http://${vto_host_with_creds}/cgi-bin/configManager.cgi?${query}" |
grep -q OK
echo -n "${vto_stream_url}"
Here is my go2rtc: streams:
vto_two_way_audio:
# H264, G.711A, 2-way audio
- echo:/config/scripts/fix_vto_codecs.sh rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
vto:
# H264, G.711A
- echo:/config/scripts/fix_vto_codecs.sh rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0
# AAC
- rtsp://127.0.0.1:8554/video_porteiro_hd?audio=aac
vto_hd:
# H264, AAC
- echo:/config/scripts/fix_vto_codecs.sh rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=1
# PCMA
- rtsp://127.0.0.1:8554/video_porteiro?audio=pcmaDon't trust it 100% yet. I now converted my home to use 2-way audio with go2rtc rather than using SIP, so let me test for some days and I will post the results back here (but obviously everything I said is working ATM). I am using the Frigate Card dev version, but I have ran into several issues so I prefer not to share it here until things are solved there. |
|
I am satisfied with my current setup. I am not using VTH nor the Dahua app to answer the doorbell, I am only using Home Assistant itself. I am documenting it here: https://github.com/felipecrs/dahua-vto-on-home-assistant |
|
I just added a video demonstration on how it's working for me. |
AlexxIT
added
enhancement
Browser is asking for microphone permission, but no audio from VTO and unmute button is disabled
The text was updated successfully, but these errors were encountered: