Since resource limitations are stated as the reason for slow
development, is there any possibility that Wyze will open-source the
RTSP firmware and allow others to help develop it?
Opinion: I highly doubt it. The firmware contains base Wyze capabilities and features that they use with their platform, services, and application. If they open sourced this, they would be exposing more information about their architecture.
There would be obvious benefits to an open source architecture, but it would require a lot of effort on behalf of Wyze with little benefit (and potentially even more adverse consequences) in the short term.
There are many issues beyond this as well, and as we’ve been taught with the android fragmentation that occurred in the market, we don’t want multiple sources for our Wyze devices. Because Wyze is truly a hardware company and not really a platform company (at least for now), I don’t see this happening.
I really liked your post “handicapped intentionally”. Personally I’ve given up on Wyze cams and RTSP. For many of the same reason you gave, I do not want my cameras on the internet. Using RTSP but requiring them to constantly be connected to their servers, is a non-starter for me…especially after the latest breach. For me no matter what I do they will all drop out at some point.
How is your system working after a couple of days of tweaking your set up?
Thanks @Wize - I’m really trying to balance the modern day needs with a generally more secure infrastructure. I know that Wyze did not really initially intend for their cameras to possibly be used in the manner that I have in mind, but they are close.
I personally really like the Wyze app - so does my wife. It takes a lot of the guesswork out of the equation and provides a good balance. I also don’t really use the free motion capture service. I found it fairly limiting without the complete motion capture and I’m really not interested in another subscription. The way of the world is changing however with SaaS offerings all the rage for investors. The addition of RTSP allows me to have that middle ground - I do the motion capture, I configure how I want my alerts, I choose where my data is saved. It’s more control that power users of any device in the modern world should be asking for as data is the new currency for any technology company.
Wyze needs to do a bit more here to finally button the RTSP up. They need to make it not require internet service is probably the biggest need after initial setup. There are complexities here as well - how do you manage it after this has occurred? Do we really want another HTTP login on our network to do so? These are the questions and vision that should be tackled IMO.
As for my adventure, a week in with 12 cameras, I have been very happy with the configuration once I was able to stabilize the infrastructure. I have a total of 4 AP’s intentionally in my house that cover each side and on the main floor and basement. The are positioned in high use areas, and I like the control of knowing what I’m connected to in order to improve my wireless performance. I don’t have to worry about meshes, WDS, or many of the modern schemes of unifying a SSID name. If I’m in the basement I connect to that AP. If there’s an issue, I know it’s generally that AP to start debugging. It just works more commonly then not.
I also don’t use crazy expensive hardware to accomplish this…all of the AP’s I bought were Facebook Marketplace AP’s that cost me $25-$35 each…
Because of this, RTSP works really well as I can pair a camera up with the closest SSID. I don’t have a single one that is below a 95% signal value in the app.
I have had only a single incident so far with a camera that was odd, but more then likely not related to RTSP. All of my cameras have 32GB cards and all are recording constantly. One camera became unresponsive from both the app and the RTSP stream. I tried rebooting it from the app and that also did not work. I finally had to power cycle it and that solved the issue. I have not had any other problems - no random disconnects or unstable video. I’ve noticed the cams switch from 15 fps to 10 fps when night mode is enabled, but that’s about it.
One thing Wyze should do is integrate MFA into the app as a setting for each open. They should also use a service instead of SMS. If they did that, and you’re not using their motion capture, the type of data the cameras would send would be diagnostic centric and shouldn’t be revealing. If you’re running Windows 10, you’re already probably giving this to Microsoft and probably a lot more…a balance and openness is really what Wyze has to tackle to make themselves a trusted company. I think they can do this, which is why I took the risk and decided to move forward as I do feel that I can secure the majority of the issues with a little elbow grease if needed.
I do think you’re going to have this with any cloud based security camera though…the ultimate question is who gives you the most control of your data in your home? That’s what I look for, but others may have a different priority. To each their own :).
I’ve been using the RTSP Firmware on my V2 Wyzecam to live stream wild owls that live in an owl box on my property.
-We are unable to interface the Wyze cam to Streamlabs OBS to get sound. We need to have sound for this channel to be optimized - the owls are constantly chattering and an important part of this channel.
-Sound does not work on VLC either.
Does anyone have any ideas on how I can make things preform better or what the cause might be? Is it the RTSP firmware?
Please view my twitch stream, you can see what I am talking about. Ill post the link below. Thanks!
Have you tried to turn on the sound and then restart the camera from the app?
@HootHouseLivestream - how are you currently sending the Wyze video feed to Streamlabs OBS?
I give a hoot and I’m talon you I can help
Hi Kenmaples, thank you for your reply - yes we did try that. Still looking for other options.
Thanks for the additional help. Please let me know if you have any other ideas.
Just got another test Camera in today - going to experiment with slobs and I’ll post an update.
— Edit for Update —
@HootHouseLivestream - results below.
Note - all tests done with a signal strength of 90%+ on a AP that is directly connected to a computer through Ethernet - there are no bandwidth issues.
OK - so here’s what I’ve tested:
- RTSP Stream Direct - adding an RTSP stream into SLOBS from a Wyze camera introduces a very definitive “choppy” sound (audio, pause, audio, pause). This was the worst quality audio that I was able to reproduce. There are no settings in SLOBS that allows you to control this…changing the quality from HD to SD also does not impact or improve the audio.
- VLC Player - Using VLC directly to the stream, the audio quality is substantially better. There are no constant chops, but there are some audio drops (skipping, not chopping). I did notice where audio would completely cut out as well, and I’d need to restart VLC to get the audio to start back up again. This was an intermittent issue.
- VLC Media Source - SLOBS also has a VLC Media Source if you install the 64-bit of VLC. I created a playlist with the RTSP stream and added it. It opened in SLOBS, but it still exhibited the same audio issues as the media source in the first bullet.
- FFMPEG - I also did a direct FFMPEG RTSP --> MP4 using the following command “ffmpeg -rtsp_transport tcp -i rtsp://ElectroStrong:email@example.com/live -c copy -f avi testfile.avi” - the audio seemed better then that of VLC but I was unable to get FFMPEG to convert the RTSP stream into an RTMP stream so I could not connect it as a media source. FFMPEG did also exhibit the audio problem where the audio would intermittently cut out completely.
Like @HootHouseLivestream stated - from the app it was always perfect. I’ve never really noticed it as my setup really focuses on video and audio is secondary. It looks like the European 8-bit PCM G.711 (A-law algorithm) is being used instead of the μ-law algorithm which is more commonly used in North America and Japan. I doubt this is the root cause, but as these are NA devices maybe it would make sense to align to the μ-law algorithm? I’d personally prefer to see an mpeg encoding of audio using MPEG4 formats (as we are already using x264 for video - RFC 6184 proposed covers that for video, RFC 5691 covers AAC).
This may not fix the SLOBS issue, as either a media source or a vlc media source both gave choppy output.
Has anyone else experimented with the audio in more detail beyond these types of tests?
Great!! Thank you
Great effort doing tests there; hope Wyze could investigate and found something they could develop on the RTSP firmware to make it better.
Thanks again. As a temporary fix we plugged an audio cable from a cheap tablet into the mic jack on the laptop to pump in sound from the Tiny Cam Pro app. It works but I don’t like it.
Please continue developing with RTSP support in mind! The nerds, geeks, techies here are the same ones that get asked monthly or even weekly “what security cameras should I buy?” The app is good, but we need something that will continue to grow with our security camera needs - especially for rural areas with poor Internet access.
I love Wyze cams, but its even better if we can record to our own NAS/NVR along with Amcrest, Reolink, etc.
Thanks. The developers need to pay more attention to streaming features!
Totally agree with you!
I’ve been trying to use the RTSP firmware but found that, for me at least, it wasn’t working. I use an application called MotionEye on a linux system which has motion detection, recording, alerting, etc. I found that the data stream was continually freezing so that the video was unusable when recorded. Haven’t found anyway to make it work.
Reverted my cameras to beta “stock” firmware for now. Still have one camera running RTSP.
@WildBill what was your signal strength in the Wyze app?
What type of hardware ran the motionEye daemon? Was it an armhf or x64 architecture? Was it plugged in via ethernet or also connecting via WiFi?
I run 12 cams right now through Zoneminder, which is also a Linux security system. It uses ffmpeg for streaming which also looks to be the same for motioneye.
System is as follows:
Ubuntu 18.04 64bit
wired GB ethernet
Camera signal strength is 82%