-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When go2rtc self-requests a source capable of backchannel, it breaks backchannel #1133
Comments
I am working around it at the moment with: streams:
vto:
# H264, PCMA/8000, 2-way audio
- rtsp://admin:8EiPuNd6pzjR686_@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
# copy AAC track from vto_hd
- rtsp://127.0.0.1:8554/vto_hd?audio=aac
vto_hd:
# H264, AAC/16000
- rtsp://admin:8EiPuNd6pzjR686_@192.168.1.40/cam/realmonitor?channel=1&subtype=1
# copy PCMA track from vto
# - rtsp://127.0.0.1:8554/vto?audio=pcma
- rtsp://admin:8EiPuNd6pzjR686_@192.168.1.40/cam/realmonitor?channel=1&subtype=0#media=audio |
Good afternoon. Tell me, does your sound become quieter and interrupted? |
go2rtc simply doesn't detect the backchannel (sendonly) track, and that's why 2-way audio doesn't work. Whatever other symptom is irrelevant. |
BTW I'm testing this more and even with the workaround, sometimes go2rtc simply "forgets" about the Which makes using the VTO doorbell with go2rtc impossible at this point. |
EDIT: This is off-topic and a different, device-related issue. Hm... I actually understand now. When someone calls the doorbell, like when someone presses it, the doorbell closes the RTSP stream momentarily. And go2rtc tries to get the connection again but this time it gets without |
@AlexxIT I don't know how feasible it is, but it could probably be solved if go2rtc would attempt to reload the sources if a consumer is requesting microphone but there is no |
Yes, yes, I’ve already tried to write this several times. |
Another option is maybe #52, maybe CGI doesn't have the same limitation. Or maybe in such case you can code some additional logic to handle when the doorbell is being called, only for CGI source. |
RTSP backchannel has two fallbacks in case of any problems. You can increase log level for rtsp module to trace. Check this: Lines 241 to 249 in 686fb37
And this: Lines 126 to 140 in 686fb37
|
How will he fix it? So that everything works. |
Or you just accept your device's firmware problems. RTSP backchannel is a new technology for camera developers. My new Dahua camera has no such problems. |
I have a Hikvision DS-KV6113-WPE1 calling panel. Are you suggesting we throw it away? |
Thank you, I will collect this information to continue the investigation. In fact I am causing some of this confusion because I was mentioning several issues after working around the first. I will focus on the first problem I mentioned, which is the issue description. This one does not appear to be caused by the device itself. Therefore, @AlexxIT, I think it may be possible to replicate the issue using your current Dahua camera. But let me do things on my side first. Also, @TokarevSergey, AFAIK Hikvision works fine using ISAPI. There was even a fix to ensure connections are closed recently in go2rtc. Regardless, let's try to keep this topic straight to a single issue. If you have something not working as expected with Hikvision, I suggest you open a different issue. |
Thanks, I've already opened a bunch of topics. Perhaps I lack the experience to explain all this correctly. |
@AlexxIT I tried reproducing the problem with RTSP debug, but unfortunately there's nothing special going on there: api:
origin: '*'
log:
rtsp: debug
streams:
vto:
# H264, PCMA/8000, 2-way audio
- rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
# copy AAC track from vto_hd
- rtsp://127.0.0.1:8554/vto_hd?audio=aac
vto_hd:
# H264, AAC/16000
- rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=1
# copy PCMA track from vto
- rtsp://127.0.0.1:8554/vto?audio=pcma
webrtc:
candidates:
- 192.168.1.10:8555
- stun:8555
This specific issue (not the one about ringing the doorbell) has no relationship with the device itself. Basically, I have Then, if I try to get 2-way audio with Just to highlight, if I try to do 2-way audio directly with Finally, I found a workaround to this problem which is to have a third stream just for 2-way audio and not consume it from api:
origin: '*'
log:
rtsp: debug
streams:
vto:
# H264, PCMA/8000
- rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0
# copy AAC track from vto_hd
- rtsp://127.0.0.1:8554/vto_hd?audio=aac
vto_hd:
# H264, AAC/16000
- rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=1
# copy PCMA track from vto
- rtsp://127.0.0.1:8554/vto?audio=pcma
vto_2_way_audio:
# H264, PCMA/8000, 2-way audio
- rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
webrtc:
candidates:
- 192.168.1.10:8555
- stun:8555 At least I am unblocked now. It is a bit inconvenient because then the |
trace. Not debug |
Ops. Here is the trace: |
And here is the trace if I just open Which works as expected. For comparison. |
Well. 1
2
|
It worked! And it makes total sense. So here's the working config: streams:
vto:
# H264, PCMA/8000, 2-way audio
- rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
# copy AAC track from vto_hd
- rtsp://127.0.0.1:8554/vto_hd?audio=aac
vto_hd:
# H264, AAC/16000
- rtsp://admin:pass@192.168.1.40/cam/realmonitor?channel=1&subtype=1#backchannel=0
# copy PCMA track from vto
- rtsp://127.0.0.1:8554/vto?audio=pcma Thanks a lot for the patience. |
It was very tricky to figure out that this was actually caused by go2rtc.
Here is my config:
In fact, I have a script to output the stream rather than using it directly because of #49, but I am removing it from this test to simplify things.
Also, my password is leaked but that is ok, I changed already. That's because I could not figure out how to remove it from the info API from go2rtc so it would appear in the video anyway.
Here is the problem:
chrome_tLNTWxaf4t.mp4
Basically, if I open
vto
first, everything works ok. I can 2-way audio with it normally. Notice the sendonly track.However, if I open
vto_hd
first, then I can no more do 2-way audio with thevto
stream.I think go2rtc should attempt to discover again more tracks if 2-way audio is requested. In fact, I don't understand why it only discovers the recvonly tracks when I request
vto_hd
.The text was updated successfully, but these errors were encountered: