Open kevkid opened 11 months ago
WebRTC is still a work in progress. Can you try the rtsp stream instead?
go2rtc:
streams:
back_side:
- rtsp://<bridge-ip>:8554/front-porch-cam
- rtsp://<bridge-ip>:8554/front-porch-cam-sub # optional sub-stream
# or use ffmpeg if the video is too glitchy:
back_side_2: ffmpeg:rtsp://<bridge-ip>:8554/front-porch-cam
I'm currently working on integrating go2rtc directly into the bridge, but still need to work out some issues.
I am also having issues feeding my Wyze cams into Frigate with the urls provided by docker-wyze-bridge. The URLs in the Camera details information button alone are not recognized by ffmpeg/Frigate. Do they need usernames and passwords? What am I missing?
2023-08-21 03:47:21.071701083 [2023-08-20 20:47:21] watchdog.side-house-cam-v3 ERROR : Ffmpeg process crashed unexpectedly for side-house-cam-v3. 2023-08-21 03:47:21.071717231 [2023-08-20 20:47:21] watchdog.side-house-cam-v3 ERROR : The following ffmpeg logs include the last 100 lines prior to exit. 2023-08-21 03:47:21.071733953 [2023-08-20 20:47:21] ffmpeg.side-house-cam-v3.detect ERROR : [tcp @ 0x558d50ff00] Connection to tcp://username.duckdns.org:8554?timeout=5000000 failed: Connection refused 2023-08-21 03:47:21.072525009 [2023-08-20 20:47:21] ffmpeg.side-house-cam-v3.detect ERROR : rtsp://username.duckdns.org:8554/side-house-cam-v3: Connection refused 2023-08-21 03:47:21.802404193 [2023-08-20 20:47:21] frigate.video ERROR : side-house-cam-v3: Unable to read frames from ffmpeg process.
@sanderz19 it looks like you're trying to connect to the stream over the WAN username.duckdns.org
. Do you have port forwarding enabled? I would suggest using the local IP or the loopback address if running on the same machine to avoid unnecessary network complications.
Thank you @mrlt8! I used the local IP of my HA/RPi, and now it's working.
WebRTC is still a work in progress. Can you try the rtsp stream instead?
go2rtc: streams: back_side: - rtsp://<bridge-ip>:8554/front-porch-cam - rtsp://<bridge-ip>:8554/front-porch-cam-sub # optional sub-stream # or use ffmpeg if the video is too glitchy: back_side_2: ffmpeg:rtsp://<bridge-ip>:8554/front-porch-cam
I'm currently working on integrating go2rtc directly into the bridge, but still need to work out some issues.
Oh, okay, I was wondering why it was so fiddly. I actually got two of the cameras to work with webrtc. Here is the format:
go2rtc:
streams:
back_side: webrtc:http://<bridge-ip>:5011/signaling/front-porch-cam?kvs#format=wyze
but inexplicably, my other two do not. There is no reason either, as they have the same conditions as the other two that do connect (same ap, good and bad signal, same versions).
I find the webrtc stream to be better quality and is more stable when it works.
@mrlt8 interesting. Do you need any help from go2rtc side?
Thank you @AlexxIT, but I think I mostly need to rewrite the way we pipe the video and audio into ffmpeg/go2rtc and the start/stop calls.
any update on this?
@mrlt8 is using webrtc stream still work in progress? Curious if there have been any improvements. Also is the first post still how we send the webrtc stream to frigate?
@kevkid I can confirm that opening container port 5000 on the wyze-bridge allows me to get two WebRTC streams going. When I tried to get the third stream going, nothing I do seems to work.
@mrlt8 could this be related to how audio and video pipe to ffmpeg/go2rtc?
Curious, why use webRTC instead of RSTP into Frigate? It seems like there's many ways to get there, I'm assuming there's some advantage?
@g13092 webrtc directly streams from the camera to the device by creating a p2p connection. This allows for near "video call" levels of latency
I am using this bridge to feed into a go2rtc stream input. I am a little unsure as to how we get the proper url? Seems like I have to echo a command into it?
Here is what my stream looks like:
When visiting:
http://<bridge-ip>:8889/front-porch-cam
I am greeted with the actual webrtc stream. But I have no idea how I would feed this into frigate?