@dcmsjc - that is a very cool idea! Do you know how well the Pi handles multiple connections to it? Is there documentation or examples of people replacing entire AP’s with this by chance?
I personally would rather have a Pi AP instead of spending $40-100 on a dedicated AP - so many more use cases that you can tackle with the Pi!
How do you know this, I’m curious.
On a side note, I understand that Live555 would be a RTSP server that would sit in between the Wyze cam RTSP stream, and BlueIris - is that correct? If so, we are then expected to install a server because Wyze can’t get their implementation to work properly? 
On a side, note, I found this link, I made the changes last night, will wait and see how long before the stream(s) freeze up with these settings in BI: Display Wyze Cam on Dashboard through Blue Iris - SharpTools.io (web) - SharpTools Community
Set up my 2 cameras as 1 and 2 in the camera field.
Wow, that’s really good info. I will need to find some time to test some of this stuff out as you recommend. the reduction would be more than good on my side, I really need to free up many gigs of space, each time I tried I would get larger files so your results are encouraging.
Will also need to schedule the encoding, I usually use my laptop for most video encoding, but have a small tower with a Xeon 12xx series CPU I can use instead to offload the laptop (which is my daily use system).
Much thanks here!!!
Perhaps it’s the networking substrate; I find that the connection is more robust when I use a RaspberryPi3B+ as an access point than my Apple Airport Express.
That is what is in the firmware source they released.
It has been such a wonderful project!! Unfortunately, never did
get sound to work properly.
Let’s hope that the next RTSP build has some audio improvements! It’s been fun stopping by at your stream though and a great example of what you can do with the base RTSP!
any work on getting better frame rates? 15fps causes to much motion blur. We need DBL that 30fps
There is some discussion in this thread about issues with some clients losing their connections with this camera.
I’m running into the same issue with another project using a docker container. The container sees the wyze camera have an issue so it restarts the ffmpeg process but the camera doesn’t reconnect.
If I restart the actual container is connects fine and works until something causes the stream to die again.
Does anyone have any idea how to resolve this issue?
Why would the container killing the ffmpeg process and restart, not work but restarting the actual container work?
@albertjmulder - frame rates are set in the firmware (15 fps daylight, 10 fps night) and RTSP can always go lower, but not higher. I don’t think we’ll see 30fps on v1/v2 of the cams but I could be mistaken - might be a good feature request to make if it doesn’t already exist.
@tom - What is this a container of? Any specific application by chance (i.e. Zoneminder, MotionEye, et cetera)?
It’s frigate and I use it with Home Assistant.
It is solid with my Amcrest camera but the Wyze camera keeps crapping out.
When the feed died we tried pausing it for 10 seconds but it didn’t help. I’m hoping it’s a matter of making it wait longer or some different ffmpeg args.
The hardware itself can handle up to 40 fps, but Wyze caps it to conserve bandwidth, since it still sends clips to the cloud.
IMO, would be nicer to control resolution & bitrate as well, it is pretty low right now, and disable cloud clips if the user modifies the default values.
I also personally would like this - like you said the chipset is the Ingenic T20 which has a encoder that supports 3MP 1080P content @ 40 fps. It’d be nice to have this as an option at least for the RTSP build.
I looked at your log files you had posted and the ffmpeg command line looks solid.
As an experiment - have you tried rebooting the WyzeCam instead of the container to see if that fixes the issue?
I have had issues with drops and it turns out usually that the cam takes a different IP address even though I’ve setup DHCP reservations. It’d be really nice if we had a static IP assignment option for our cams…
The camera is keeping its IP.
When it gets into this state, I can still view the stream with VLC player.
Have you tried using ffmpeg manually from the command line to do the same thing instead of VLC?
Example: “ffmpeg -rtsp_transport tcp -i rtsp://username:password@10.0.1.226/live -c copy -f avi testfile.avi”
VLC to my recollection uses UDP as the default streaming protocol unless you override it. If you manually do ffmpeg and it fails and works with VLC, then changing VLC would be my next step to see if there is a TCP vs UDP issue (you could even try changing ffmpeg to udp as well - just change tcp to udp in the command line).
Interesting, I have also had this problem a few time. I’ve had many many devices on my network, and they have always held their IP when I have created DHCP reservations, the Wyze cam is the only device that doesn’t (sometimes)…
Can you guys add this as a wish list item where people can vote? I would def vote for this, would love to bump up the FPS, would be nice to have this configurable… is Wyze even working on another RTSP build, I haven’t read anything that states so…
