I think the issue I’ve been having with frigate is more related to Wyze’s implementation of rtsp.
I killed the ffmpeg process on both cameras and the other (non-Wyze) camera resumed with no issues.
When I changed the ffmpeg args to use ‘udp’ the image resumes after I kill the process. However, the image moves around a lot. In VLC player it’s steady.
It very well could be regarding the implementation of RTSP, but then same way you are streaming video with frigate is used with other applications such as MotionEye and Zoneminder.
I have 12 cameras with Zoneminder and I do not have the drop/reconnect issues that you have…they all spawn a TCP ffmpeg process to connect, and if wifi drops they reconnect without issue.
What I have noticed with Wyze cams vs others is that they do seem very picky when it comes to the signal that they connect with…I transitioned all of my camera’s to 802.11n as I had random drop out issues.
What is the RTSP version of firmware that your are running?
They are using Live555, which is a pretty standard RTSP server.
I am thinking it has more to do with either the kernel they are using, or it is how they go about setting everything up.
I really wish they would pipe all the error messages to the microSD card instead of /dev/null
firmware: 4.28.4.41
do those program show the ffmpeg args they are using?
frigate has the ability to modify and additional args so hopefully it’s a matter of finding the correct combination.
I cannot get the exact command line for Zoneminder. The documentation shows to test RTSP using the command I published earlier above.
Zoneminder may be doing something extra to fix the stream if it drops.
@UserCustomerGwen Can someone from Wyze chime in? Are there any settings in the rtsp server of the camera which could kill the tcp connections if the stream dies?
It seems like the tcp connection doesn’t timeout.
It could, but if you look at the source code, you’ll see that libavcodec is used with some pretty vanilla settings.
To top that off, I have used Blue Iris, Zoneminder, MotionEye, ContaCam, Ffmpeg, VLC, and TinyCam with TCP RTSP and none of them have exhibited an issue with the RTSP stream. I’m not saying that there isn’t a possibility that there is an RTSP service issue on the Wyze cams, but I am saying that it’s highly unlikely that it’s the root cause.
As you are using a container, and restarting the container fixes the issue, I would think that something with the container could also be the issue. Are you using docker? I personally have had networking issues using docker in the past and changed to bare metal for my needs.
Here’s additional information I posted on the Home Assistant page
In frigate, I killed the stream. I then restarted the camera.
When ffmpeg restarted and the camera connected, the stream picked up and moved along.I see the following which seems like the timeout value is off but I don’t know if that means it truly is off or it’s simply not set.
tcp 51944 0 e5c7d5da9709:48254 10.0.0.32:554 ESTABLISHED 1301/ffmpeg off (0.00/0/0)
Are you suggesting that the issue with the RTSP stream timeout is not on the Wyze side? I wish there was some sort of USB to Ethernet adapter that the Wyze cam can use in order to figure out if it’s the wireless connection that would be the issue affecting these timeouts.
I’m using only 2 WC2s in BI5 and Amcrest (via Ethernet) and the Amcrest has never timed out. It’s apples and oranges since one is wired the other 2 are wireless, but I have solid signal on both cameras via the Wyze app (when frozen on RTSP).
Do the IOS/Android apps use some sort of keepalive that fixes any possible timeouts (even though I’ve experienced connection issues even on the apps from time to time) that RTSP doesn’t?
If you don’t kill the stream but just restart the camera, does it start working? I noticed that you did two actions (kill process and then restart camera) - if you just reboot the camera does it act the same as just killing the process (and if you do both it works)?
Blockquote
Are you suggesting that the issue with the RTSP stream timeout is not on the Wyze side?
I am.
At the same time I’m also not trying to say it’s also a possibility that something is flawed with the RTSP implementation, but I personally think it’s not that. Not being someone that has direct access to the Wyze source code or has the time to reverse engineer the firmware pretty much makes me base my assumptions off of experience and other confirmed posts in this thread.
When I start with my situation, which I’ve documented for the challenges that I faced, through all of the software configurations I never had a TCP specific RTSP non+connection issue with 12 cameras running through 3 different brand AP’s. In fact, I was able to use multiple TCP RTSP streams on one camera to multiple computers at the same time. I have had Zoneminder running now for 45+ days recording motion that is around 400GB with no reconnect issues. I’ve had plenty of issues - but found most to be related to network configuration and the limitations of 802.11x that most businesses face with a large data load over wifi. But that doesn’t mean that my use case matches others which is also why I agree it could be the RTSP service on the Wyze cam but I’d need to setup a reproducible scenario.
I also absolutely agree with you that it would be wonderful to have a hard wire to rule out wifi centric issues. Maybe the next version or a firmware update will support this capability.
I’ll see if I can get an answer to that one. 
I looked into this and I’m told that you can kill the TCP connection by turning RTSP off and back on.
Thanks for your patience!
Vote for what
Could some of the issues discussed in this thread be related to the version of Live555 being so old?
Is Wyze looking at using a more recent version?
2020-03-24T13:23:06.646414579Z s=Session streamed by "wyze"
2020-03-24T13:23:06.646515630Z i=live
2020-03-24T13:23:06.646560513Z t=0 0
2020-03-24T13:23:06.646623886Z a=tool:LIVE555 Streaming Media v2017.10.28
It is actually exposure time, not frame rate, that causes motion blur. The two are inter-dependent but not always tied together. For example, the maximum exposure time at 20 fps would be 50 ms, and the maximum frame rate with a 100 ms exposure time would be 10 fps, but the frame rate for 50 ms exposure time can be anything less than or equal to 20 fps, and the exposure time for 20 fps can be anything less than or equal to 50 ms.
Shorter exposure time reduces blur at the expense of light, which basically mean less detail. Longer exposure time can produce better detail but is more susceptible to blur.
Does anyone know, is the ability to provide static/snapshot images of the RTSP feed on the development roadmap? Or does the RTSP feed support multiple clients yet (so I could setup a client that just generates snapshots)?
You can have multiple clients on an RTSP stream - I have a couple of mine running with Zoneminder and MotionEye and have had any problems
You can have multiple clients on an RTSP stream - I have a couple of mine running with Zoneminder and MotionEye and have had any problems
I agree with this. Its not so much a camera problem, but more the quality of the connection between your camera and WiFi AP, and whether it can manage having 2 RTSP streams coming from the camera at once. I had it running for a little while and it worked, but I found it got a little choppy with high motion scenes. It could have been under-powered hardware since I had both streams going to the same test server in different docker containers, but it felt like it was insufficient bandwidth. The irony is that 2 streams took up less than 5Mbps, so it shouldn’t have been a bandwidth issue either.
You could try and use an RTSP proxy to get the WiFi stream onto your LAN and then split it out from that point onward. I tried Live555, but didn’t like its output stream as it was re-encoded and lost some quality in the process. It may be correctable if you tweak its settings but I couldn’t be bothered.