Could a list of 2 way audio supported cameras be created? Aka, a list of known-working cameras with go2rtc 2 way audio

[distinctjuggle]

Title, basically. It's not always easy to tell if cameras support ONVIF Profile T compliant 2 way audio or not, and I think there'd be a lot of merit to having a list of community maintained, known working cameras in the Wiki here, or something similar.

For example, Reolink has ONVIF compliant 2 way audio for their CX-410/810, and for their Doorbell cameras. However, they have other products which support only proprietary 2 way audio methods. Hikvision doesn't support ONVIF compliant 2 way audio, but does have go2rtc supported 2 way audio functionality via ISAPI go2rtc integration.

It would be really nice if there was a list of cameras where feedback could be entered for 2 way audio functionality, as well as other go2rtc related config and functionality. I've got some Hikvision cameras which require a bit of a special config to function, and that could also make it to the wiki.

[srocupado]

Great ideia

[AlexxIT]

Nothing good can come of this. Even cameras that work well can fail due to firmware issues. Examples a known for Reolink, TPLink Tapo, Dahua, DVRIP, etc.

[distinctjuggle]

Nothing good can come of this.

Well that seems extremely harsh. Of course good things can come from this. People can have a basic idea of which cameras should and shouldn't have support. I don't have to purchase a camera to see if two way audio works, I can check with the community first in an efficient manner. I don't have to try to search for issues related to my camera and only get mixed/inaccurate/not helpful results - eg my Hik having weird issues, I can just look in the list and see what's there as a starting point.

Instead of creating potentially duplicate issues, I can easily see what information is available on the list as a starting point, before other action.

Even cameras that work well can fail due to firmware issues. Examples a known for Reolink, TPLink Tapo, Dahua, DVRIP, etc.

Isn't that more of a reason to have the list than to not have it? There are examples known for Tapo devices not functioning on certain firmwares, so the Wiki entry should contain entries for which firmwares work and which don't. That gives the user a better understanding of what to expect before they run into problems/buy the camera, not afterwards.

I checked the issues here before I purchased a Tapo, but because I didn't find a single very specific issue, I didn't see that Tapos had a firmware issue in the latest versions which didn't allow them to function properly with go2rtc in even a basic capacity, much less with 2 way audio support. Therefore, I ended up creating an issue which didn't resolve the problem, and had to return the camera. A big waste of time for everyone involved, including you. This could've been avoided with a basic list of known devices, and those device limitations.

---

It should result in less issues being created for go2rtc for compatibility related discussions, but even to your point, in no way does the list imply 100% guaranteed compatibility. No one expects professional guarantees of device support from a FOSS project, and those extremely few who do will expect it regardless of a list like this being present.

Example: I can avoid Tapo products due to their firmware issues and lack of proper open standards before I purchase one. I can avoid Reolink models that only support proprietary 2 way audio. I can see that X model supports ONVIF 2 way audio with firmware update Y. I can confirm whether this Dahua camera supports ONVIF 2 way audio before I purchase it. I can see about this Hikvision issue and the proper config steps necessary to get it working before I purchase it. That results in less headache for literally everyone involved, including those who provide support for issues here.

---

I don't see any drawbacks to this idea. All you really have to do is link to a community maintained list of cameras and promote the idea, and allow others to fill in the rest. The exact implementation of the list doesn't really matter so long as the community can contribute to it with some method. What's your argument against it?

[AlexxIT]

I don't mind if someone wants to make such a list and maintain it. I don't want a person to spend their money and come to me asking why it doesn't work.

Maybe a list that has camera model, hardware revision, firmware version makes sense. For cameras like roborock the date of operation and go2rtc version makes sense. Because the manufacturer can change the logic on the server.

[rowskilled14]

I'd be happy to maintain a list for this purpose, but on the condition that it is, "officially unoffically" supported. What I mean by that term is that I'd like some way for people to actually know it exists. In the main go2rtc readme page, it'd be nice to have a link to it with a brief description, etc. Something that people could find with various ctrl+f's for supported devices, recommended devices, known device status, or similar phrases. Maybe not those exact terms given your stated concern, but just something which gets the desired point across and would be easy for them to find in the top ish section of the readme somewhere. It'd also be nice to have you and others point people towards the list when appropriate (aka, someone makes an issue post while testing out a new camera model which isn't already on the list, etc). Or, at least point me towards that issue/thread when they come up so I can manually add things to the list, ask users for feedback, etc.

The purpose of this would be twofold:

1. It'd help people to actually get some use out of it. It doesn't do any good to keep the list if people don't know it exists and therefore cannot use it.
2. It'd encourage people to contribute towards it with their camera feedback. I'll happily add my camera experiences to the list, but that only goes so far. It wouldn't be much of a list, nor very useful, if it only has 3-4 brands of entries with limited models.

---

Would you be fine with pointing people towards it when appropriate? Eg - A paragraph/section(ish) in the readme (explaining that it is not officially maintained by go2rtc and there are no guarantees made by go2rtc, but is instead community supported, the purpose of it as a general guidance and not a hard and fast truth, and a link to a page on how to contribute perhaps), and perhaps pointing people to the list when you see a new brand and/or model walk through the issues page (or tagging me to the thread). I'm not trying to make this into a bigger deal than it should be, but I would just like a bit of confidence that if I go down this path that it's not in vain (for the previous two listed reasons).

---

If that's fine by you, do you have any thoughts on the best way to keep up with this data? I could see several arguments for different implementation options, but the idea that stands out the most to me is as follows:

I create a separate github repo for the task. It'd basically just be a readme/wiki page, but the issues/discussion tools would allow others to contribute their changes in an organized fashion. This would have the benefit of 100% account compatibility with all who make issues on this go2rtc repo for go2rtc requests/problems/etc. There'd be no need to create an example on fandom.com for example with a traditional wiki style website. I could also tie it loosely into Frigate as well for similar reasoning, especially given the go2rtc tie in (though I recognize they are separate projects - I will consult with them as well of course, maybe even separating the two entirely somehow). I can get a basic "site" layout with my own entries added before you make any readme changes here, of course.

---

My thoughts on what the list looks like exactly might change a bit, but on the top of my head it could look something like this template:

Template Example (click me)

brand

category

model:

short_description_and_overview

• Feature a
  • status
• Feature b
  • status
• Feature c
  • status
• Known stream URLs:
  • RTSP Main Stream: rtsp://<user>:<password>@<ip_address>:<port>/h264Preview_01_main
  • RTSP Sub Stream: rtsp://<user>:<password>@<ip_address>:<port>/h264Preview_01_sub
  • FLV Streams - etc

Example_config:

blah blah blah

Description_of_config

Alternate_config:

blah blah blah

Description_of_alternate_config

API_endpoints:

• Toggle day/night profile: example_API_endpoint_here
• etc

Additional information:
only if needed

---

And here's an example with a real camera (subject to change):

Reolink Example (click me)

Reolink:

Wireless Cameras:

Reolink Video Doorbell WiFi

A doorbell camera from Reolink. Comes in Wi-Fi and PoE versions, with identical functionality otherwise. A popular self-hosted offline only option, with no major quirks other than Reolink's RTSP stream as noted below. Can be setup via Ethernet interface and 12V power jack (even on Wi-Fi version).
Features:

• 2 Way Audio:
  • Functional with go2rtc from firmware (would find firmware version and/or date for live - for this example I know it's in an issue somewhere in go2rtc) X onwards (Date: xxxx-xx-xx), via ONVIF Profile T compliant backchannel.
• RTSP Stream
  • A mixed bag as is typical for most Reolink cameras. Some users report it works fine, others prefer the RTMP/FLV over HTTP stream for better reliability
• RTMP Stream / FLV over HTTP Stream:
  • Works for most users without too much fuss

Camera Stream Endpoints/URLs:

• RTSP:
  • Main Stream: rtsp://<user>:<password>@<ip_address>:<port>/h264Preview_01_main
  • Sub Stream: rtsp://<user>:<password>@<ip_address>:<port>/h264Preview_01_sub
  • Note: Default port is 554 for RTSP
• RTMP / FLV over HTTP:
  • Main Stream: http://<user>:<password>@<ip_address>/flv?port=<port>&app=bcs&stream=channel0_main.bcs&user=<user>&password=<password>
  • Sub Stream: http://<user>:<password>@<ip_address>/flv?port=<port>&app=bcs&stream=channel0_sub.bcs&user=<user>&password=<password>
  • Note: Default FLV port is 1935

Example config:

Reolink_Doorbell:
      - ffmpeg:http://admin:[email protected]/flv?port=1935&app=bcs&stream=channel0_main.bcs&user=admin&password=Password#video=copy#audio=copy#audio=opus
      - rtsp://admin:[email protected]:554/h264Preview_01_main
      - ffmpeg:Reolink_Doorbell#audio=opus#audio=copy

This config is known to work with go2rtc and Frigate for two way audio on this device. It primarily utilizes the RTMP/FLV stream for basic streaming, but allows for using the RTSP stream when two way audio is needed thanks to go2rtc.

---

I'd also include a general page (main readme probably) with some expectations on my end of things. I'd heavily stress and emphasize that go2rtc doesn't maintain the list, and that go2rtc isn't to blame for firmware changes breaking things (eg Tapo, at least in the past - I'm not sure of their current status). I'd stress that users should check with known firmware versions, and have an issue page for each camera so people can chime in with changes, updates, additional information, etc. I could slightly pivot the list to be almost more of a general IP Camera help page than something that is 100% only for go2rtc. I'd still primarily target go2rtc, since my stack is Frigate, but it'd be positioned in such a way so that it'd help people regardless of what NVR or NVR-helping software they use. So, all cameras would include a go2rtc config, but the information included with it wouldn't only help go2rtc users. That might help to alleviate your concerns slightly.

What are your thoughts? I understand your hesitation with a list which can come across as providing, "official support" and I'd like to help address that as best possible while still "advertising" (for lack of a better word - obviously I have no financial interest in this) the list. Do you think the last change I mentioned would help in this issue?

[scorpion870]

Excellent idea @distinctjuggle and @rowskilled14 , i was about to suggest/request the same thing! (but first i need to have atleast my own first two way camera working). Trust me, you may do it or not, but i definitely WILL make such a list, i purchased a domain just to use as blog for my home lab lessons, because i have started as non IT side noob and set my home lab, so i just want to document atleast my own experiences, A CCTV camera setup is integral part of every home network these days, and if there is a place (apart from reddit etc), where people can even share their working experiences, it can even be like a Testimonial for Alex great work! (And yes, i totally understand his concerns, i would be hesitant too if i were him, as there could be possible needless legal and moral issues if he starts, that is the last thing a busy software engineer needs, BUT, if some other people start, and it is a community contribution, sharing of working experiences, there is no Corporate or Political entity that can stop it. As i see it, The starting intention is definitely good, the plan seems reasonable and feasible, (it is almost like Proton or WINE edition for Go2RTC for IP Cameras for now), So yes, atleast i am all for it, and i will keep checking this post, All the best!

[AlexxIT]

A separate repository seems reasonable. I don't mind mentioning references to it in readme or issues.

[rowskilled14]

Sounds good! I'll get started on a setup in the next few days and will update you when I have something.