Closed towerhand closed 3 months ago
And obviously, the two way audio doesn't work from the go2rtc dashboard either.
Why not simply:
streams:
doorbell:
- rtsp://admin:{FRIGATE_RTSP_PASSWORD}@192.168.40.2:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
?
Also, make sure Frigate is not consuming this stream during your test. I suggest you try with go2rtc standalone and later migrate your findings to Frigate.
If you really want to use the 2-way audio capable stream in Frigate as well, make sure to set ?backchannel=0
when consuming it in the Frigate detect or record roles, as realized in https://github.com/AlexxIT/go2rtc/issues/1134#issuecomment-2129496238.
Thanks, I'll try that this weekend. How are you quickly and easily accessing the separate stream for the two-way audio only when needed?
In the following link you can see my frigate.yaml, and then you can see that I have one exclusive stream only for 2-way audio communication. This stream isn't used anywhere, except in my Home Assistant Frigate Card where I want the 2-way audio to happen.
I know Amcrest is Dahua under the hoods, but I don't know to how extent the same things apply. For example, I don't think you need to tinker with audio codecs (fix_vto_codecs.sh
) like I do.
Probe can discover two way audio. It works fine. Are you sure you using HTTPS in your browser?
Thanks for your feedback. It looks like I read too much trying to set this up and overcomplicated things. It turned out the doorbell stream was giving wrong user/pass due to the "proto=Onvif" setting, but I removed it and now it seems to work. I'll do more testing tomorrow.
Once again, thanks for the assistance. For future reference since I found a lot of conflicting information. The two-way audio works with these settings for the Amcrest AD410, go2rtc version 1.9.3, and Frigate version 0.14.0.
streams:
doorbell:
- rtsp://admin:pass@ip:554/cam/realmonitor?channel=1&subtype=0#backchannel=0
- rtsp://admin:pass@ip:554/cam/realmonitor?channel=1&subtype=0
- ffmpeg:doorbell#audio=aac
doorbell_sub:
- rtsp://admin:pass@ip:554/cam/realmonitor?channel=1&subtype=1
- ffmpeg:doorbell_sub#audio=aac
Are you basically saying that your doorbell doesn't support proto=Onvif
?
Are you basically saying that your doorbell doesn't support
proto=Onvif
?
II couldn't it to work with the "proto=Onvif" because it kept giving me wrong user/pass, even with VLC. So, it looks like the AD410 doesn't support it unless I'm missing something, but I'm not sure what else to do to confirm.
I think there's no secret. If:
rtsp://admin:pass@ip:554/cam/realmonitor?channel=1&subtype=0
Is working in VLC but:
rtsp://admin:pass@ip:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
Is not, then I guess AD410 doesn't support it.
Fortunately, go2rtc's documentation doesn't suggest using unicast=true&proto=Onvif
anywhere for Amcrest, so I don't think any documentation change is due.
I'm using Frigate as an NVR, and I have been struggling to get the 2-way audio on the AD410 for a while since it is recommended to use the #backchannel=0 for the button to work correctly, but I have been reading that having a separate stream with &unicast=true&proto=Onvif will allow the 2-way audio to work too. However, it doesn't work with these settings:
Go2rtc probe info:
Probe with the 2-way working, but the backchannel=0 removed:
I got some assistance from Nick (Frigate contributor), who suggested I create an issue here since it appears to be a go2rtc problem. I would appreciate some help in getting it fully working.