2-way audio with Dahua CGI HTTP interface #52

felipecrs · 2022-09-20T22:16:18Z

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:pass@192.168.1.40/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.

The text was updated successfully, but these errors were encountered:

felipecrs · 2022-09-20T22:17:59Z

Refs Dahua VTO support #49 (comment)

/cc @luzik

luzik · 2022-09-21T05:20:22Z

Yeah, latency i low and we are ready to build video doorbell intercom. Switching audio codec is required. Please refer
blakeblackshear/frigate#2572

AlexxIT · 2022-09-21T12:25:34Z

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

felipecrs · 2022-09-21T12:39:22Z

This is what I have:

streams:
  "vto":
    - rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
    - ffmpeg:rtsp://admin:pass@192.168.1.40/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
blakeblackshear/frigate#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.

AlexxIT · 2022-09-21T12:53:01Z

So you just need to change codecs. Like @luzik did.

felipecrs · 2022-09-21T13:05:24Z

Wow, it actually works! I just needed to select G.711 8000 instead of 16000:

felipecrs · 2022-09-21T13:05:58Z

Thanks a lot guys!

felipecrs · 2022-09-21T16:41:45Z

For completeness this is my final go2rtc configuration:

streams:
  vto:
    - rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif

NickM-27 · 2022-09-21T16:56:42Z

@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

felipecrs · 2022-09-21T16:58:17Z

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.

felipecrs · 2022-09-21T16:59:17Z

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.

NickM-27 · 2022-09-21T17:00:10Z

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"
  }
]

felipecrs · 2022-09-21T17:02:06Z

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"
  }
]

felipecrs · 2022-09-21T17:04:53Z

BTW I noticed you are missing unicast=true in your RTSP URL.

NickM-27 · 2022-09-21T17:05:45Z

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"
  }
]

calisro · 2022-09-21T17:46:32Z

I am using the Amcrest AD410

My AD410 works fine with the default G.711U. No need to mess with the frequency.

conorlap · 2022-09-21T17:46:59Z

@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"
  }
]

NickM-27 · 2022-09-21T17:58:57Z

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

calisro · 2022-09-21T17:59:09Z

This is the encode screen for the AD410 that works for me. Its actually G.711U on mine.

NickM-27 · 2022-09-21T18:01:00Z

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.

calisro · 2022-09-21T18:03:51Z

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"
  }
]

conorlap · 2022-09-21T18:05:40Z

My settings, and my Firmware is 1.000.0000000.7.R.210220

NickM-27 · 2022-09-21T18:07:00Z

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).

felipecrs · 2022-09-21T18:07:54Z

I use the cloudflared addon and 2-way audio works just fine for me. :)

calisro · 2022-09-21T18:08:04Z

I use cloudflare as well. I don't use the cloudflared addon. I have it setup myself.

calisro · 2022-09-21T18:10:17Z

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.

NickM-27 · 2022-09-21T18:44:52Z

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.

felipecrs · 2022-09-21T18:47:21Z

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.

calisro · 2022-09-21T18:47:59Z

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

NickM-27 · 2022-09-21T18:51:24Z

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

NickM-27 · 2022-09-21T18:57:57Z

Okay so can confirm it is something with my NPM setup. If I point cloudlfare right at go2rtc webRTC and the two way talk work great. Thank y'all for all the info, time to figure out why NPM was messing with stuff

felipecrs · 2023-10-16T02:27:19Z

@AlexxIT, my friend, @felpsnew, has a Intelbras Mibo camera.

Historically, Intelbras cameras are just rebranded Dahuas.

His camera supports two-way audio, but unfortunately not through ONVIF Profile T.

When he configures the go2rtc with an URL like:

rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif

The output is:

{
  "producers": [
    {
      "type": "RTSP active producer",
      "url": "rtsp://192.168.5.11/cam/realmonitor?channel=1\u0026subtype=0\u0026unicast=true\u0026proto=Onvif/",
      "remote_addr": "192.168.5.11:554",
      "user_agent": "go2rtc/1.8.1",
      "sdp": "v=0\r\no=- 2229913047 2229913047 IN IP4 0.0.0.0\r\ns=Media Server\r\nc=IN IP4 0.0.0.0\r\nt=0 0\r\na=control:*\r\na=packetization-supported:DH\r\na=rtppayload-supported:DH\r\na=range:npt=now-\r\nm=video 0 RTP/AVP 96\r\na=control:trackID=0\r\na=framerate:20.000000\r\na=rtpmap:96 H264/90000\r\na=fmtp:96 packetization-mode=1;profile-level-id=4D0029;sprop-parameter-sets=Z00AKY2NQDwBE/LNwEBAUAAAjKAAFfkAQAA=,aO44gAA=\r\na=recvonly\r\nm=audio 0 RTP/AVP 97\r\na=control:trackID=1\r\na=rtpmap:97 MPEG4-GENERIC/16000\r\na=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1408\r\na=recvonly\r\nm=application 0 RTP/AVP 107\r\na=control:trackID=4\r\na=rtpmap:107 vnd.onvif.metadata/90000\r\na=recvonly\r\n",
      "medias": [
        "video, recvonly, H.264 Main 4.1",
        "audio, recvonly, MPEG4-GENERIC/16000",
        "application, recvonly, VND.ONVIF.METADATA"
      ],
      "receivers": [
        "96 H264, bytes=772597, senders=1",
        "97 MPEG4-GENERIC/16000, bytes=24050, senders=0"
      ],
      "recv": 805239
    }
  ],
  "consumers": [
    {
      "type": "WebRTC/WebSocket async passive consumer",
      "remote_addr": "tcp4 prflx 192.168.5.51:51831 related :0",
      "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36",
      "medias": [
        "video, sendonly, VP8, RTX, VP9, H264, AV1, RED, ULPFEC, FLEXFEC-03",
        "audio, sendonly, OPUS/48000/2, RED/48000/2, G722/8000, PCMU/8000, PCMA/8000, CN/8000, TELEPHONE-EVENT/48000, TELEPHONE-EVENT/8000, L16, PCML"
      ],
      "senders": [
        "102 H264, bytes=772597, receivers=1"
      ],
      "send": 781267
    }
  ]
}

I.e. no backchannel. Maybe his camera is based on an old Dahua firmware, but there is no updates available.

I suspect this would also be the case for some Dahua old models too.

For this reason, I am reopening this issue if you don't mind (let me know otherwise).

I think a cgi source for two-way audio like isapi would be great, and maybe it would be a little smoother even for newer Dahua cameras as compared to RTSP.

Here is the CGI HTTP API documentation:

https://s3.amazonaws.com/amcrest-files/AMCREST_CGI_SDK_API.pdf

And I was able to play some audio through it with:

curl --digest -verbose --request POST --url 'http://admin:pass@192.168.1.40/cgi-bin/audio.cgi?action=postAudio&httptype=singlepart&channel=1' --header 'Content-Type: Audio/G.711A' --data-binary '@DoorBell.wav'

AlexxIT · 2023-10-16T03:58:00Z

This can't be used as live audio because it's static audio file

felipecrs · 2023-10-16T04:18:03Z

Right, there is another API for multipart audio files... I am not sure if that one can be used instead.

felipecrs · 2023-10-16T04:19:47Z

11.2.2 Example for multipart
The RUL of transmit a multipart、channel 1 audio stream(encoded with G.711 A-law) is:

http: //<ip>/cgi-bin/audio.cgi?action=postAudio&httptype= multipart &channel=1

example:

POST /cgi-bin/audio.cgi?action=postAudio&httptype= multipart &channel=1 HTTP/1.1
Content-Type: multipart/x-mixed-replace; boundary=<boundary>
--<boundary>
Content-Type: Audio/G.711A
94
Content-Length: 800
<Audio data>
--<boundary>

AlexxIT · 2023-10-16T10:04:54Z

Hm. Multipart can be used for live backchannel

felipecrs · 2024-05-22T18:53:04Z

@AlexxIT in case you want to try this again, I can give you direct access to two of my cameras. The Dahua VTO, and another camera which is close so that you can hear your own audio from it.

felipecrs · 2024-05-22T20:06:21Z

Another thing, in case you really have no interest of implementing this yourself, I remember you said once you tried to make this work but it didn't work.

If you have the draft code still, and you can push it to some branch, I can try to work on top of it. Otherwise I'd even not know how to start.

AlexxIT · 2024-05-23T07:53:33Z

I'm happy to announce that I was able to buy two different models of doorbells at a very good price.
Hopefully soon I'll have time to do some experiments with them.

felipecrs · 2024-05-23T12:27:54Z

That's amazing! Congratulations on your new acquisitions!

isegals · 2024-05-30T06:53:06Z

I'm happy to announce that I was able to buy two different models of doorbells at a very good price. Hopefully soon I'll have time to do some experiments with them.

It's intresting what doorbells you have?

Cr4z33 · 2024-06-02T12:43:55Z

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

Sorry for "grave digging" this post, but what software is that?

I've got already an AD410 and I am waiting for the video doorbell of Dahua posted in the OP.

AlexxIT added the enhancement New feature or request label Sep 21, 2022

felipecrs closed this as completed Sep 21, 2022

felipecrs mentioned this issue Sep 21, 2022

Possibility to talk with doorbell rroller/dahua#181

Open

calisro mentioned this issue Sep 21, 2022

API Doc to Send Audio For RTSP Back Channel #57

Closed

felipecrs reopened this Oct 16, 2023

felipecrs mentioned this issue Oct 16, 2023

Support L16 audio codec for backchannel #696

Open

felipecrs mentioned this issue Nov 28, 2023

Dahua VTO support #49

Open

AlexxIT mentioned this issue Nov 30, 2023

Two-way audio working? roleoroleo/yi-hack-Allwinner-v2#762

Closed

AlexxIT added the dahua Dahua cameras, VTO, SIP label May 21, 2024

felipecrs mentioned this issue May 22, 2024

When go2rtc self-requests a source capable of backchannel, it breaks backchannel #1133

Closed

2-way audio with Dahua CGI HTTP interface #52

2-way audio with Dahua CGI HTTP interface #52

Comments

felipecrs commented Sep 20, 2022 • edited Loading

felipecrs commented Sep 20, 2022

luzik commented Sep 21, 2022

AlexxIT commented Sep 21, 2022

felipecrs commented Sep 21, 2022

AlexxIT commented Sep 21, 2022

felipecrs commented Sep 21, 2022

felipecrs commented Sep 21, 2022

felipecrs commented Sep 21, 2022

NickM-27 commented Sep 21, 2022

felipecrs commented Sep 21, 2022

felipecrs commented Sep 21, 2022

NickM-27 commented Sep 21, 2022

felipecrs commented Sep 21, 2022 • edited Loading

felipecrs commented Sep 21, 2022

NickM-27 commented Sep 21, 2022 • edited Loading

calisro commented Sep 21, 2022 • edited Loading

conorlap commented Sep 21, 2022

NickM-27 commented Sep 21, 2022

calisro commented Sep 21, 2022 • edited Loading

NickM-27 commented Sep 21, 2022 • edited Loading

calisro commented Sep 21, 2022 • edited Loading

conorlap commented Sep 21, 2022

NickM-27 commented Sep 21, 2022

felipecrs commented Sep 21, 2022 • edited Loading

calisro commented Sep 21, 2022

calisro commented Sep 21, 2022 • edited Loading

NickM-27 commented Sep 21, 2022

felipecrs commented Sep 21, 2022 • edited Loading

calisro commented Sep 21, 2022 • edited Loading

NickM-27 commented Sep 21, 2022 • edited Loading

NickM-27 commented Sep 21, 2022

felipecrs commented Oct 16, 2023 • edited Loading

AlexxIT commented Oct 16, 2023

felipecrs commented Oct 16, 2023

felipecrs commented Oct 16, 2023

AlexxIT commented Oct 16, 2023

felipecrs commented May 22, 2024

felipecrs commented May 22, 2024

AlexxIT commented May 23, 2024

felipecrs commented May 23, 2024

isegals commented May 30, 2024

Cr4z33 commented Jun 2, 2024 • edited Loading

felipecrs commented Sep 20, 2022 •

edited

Loading

felipecrs commented Sep 21, 2022 •

edited

Loading

NickM-27 commented Sep 21, 2022 •

edited

Loading

calisro commented Sep 21, 2022 •

edited

Loading

calisro commented Sep 21, 2022 •

edited

Loading

NickM-27 commented Sep 21, 2022 •

edited

Loading

calisro commented Sep 21, 2022 •

edited

Loading

felipecrs commented Sep 21, 2022 •

edited

Loading

calisro commented Sep 21, 2022 •

edited

Loading

felipecrs commented Sep 21, 2022 •

edited

Loading

calisro commented Sep 21, 2022 •

edited

Loading

NickM-27 commented Sep 21, 2022 •

edited

Loading

felipecrs commented Oct 16, 2023 •

edited

Loading

Cr4z33 commented Jun 2, 2024 •

edited

Loading