I don’t think so… at least not with this current phase of the RTSP enablement
1 Like
when will we get updates for other devices? its been quite awhile. is it hard to implement or is only 1 person working on this? just wondering.
2 Likes
I just bought 2 Wyze Cam Pan v3 because I saw there is RTSP support for them now.
Both devices showed a firmware update available for 4.50.16.5654 that states it includes the RTSP support. After updating both cameras, they only show 4.50.15.4800 and say they are up to date.
When I look at https://support.wyze.com/hc/en-us/articles/360024852172-Release-Notes-Firmware#Accordion-wyze-cam-pan-v3-firmware-30 it says the 4.50.16.5654 was released on February 2nd, but does not provide a link to manually download it.
What’s going on, was this released or not???
It has been put on hold as there were bugs and issues with it.
1 Like
I think Wyze just pushed out 4.36.16.6114 (beta) a moment ago as I saw it pop up on my app. Updating one of my V3 cameras running on 4.36.16.5055 and hoping it fixes some issues I have been experiencing.
You are correct, 4.36.16.6114 (beta) for V3 and 4.52.9.6119 (beta) for V4. Just waiting for an official announcement from Wyze in the Beta thread.
1 Like
Sadly no RTSP for v4, as of firmware 4.52.9.6119.
Interesting case. If VLC can play the RTSP stream but Blue Iris cannot, that usually suggests the stream itself is at least partially valid, and the issue may be on the client compatibility side.
I’m actually the developer of SmartRTSP, a native app for viewing RTSP / ONVIF cameras on iPhone, iPad, and Mac, and this kind of inconsistency is exactly why I started building it. In theory RTSP should be straightforward, but in practice different cameras and clients often behave very differently.
Would be curious whether the issue here is related to auth, SDP parsing, codec negotiation, or Wyze’s RTSP beta implementation specifically.
I spent a long time tracking down an issue with one out of 5 v3’s.
I have 5 Wyze v3 cameras (one is a Wyze Cam Floodlight v1 which uses a v3 internally) all running the same beta RTSP firmware, feeding into Frigate NVR. Four worked perfectly. The fifth, the Floodlight, had a working preview thumbnail but the live view would just spin forever.
The root cause: that camera’s RTSP stream advertises a PCMU audio track in its SDP response but then sends zero audio bytes and zero audio packets. The other 4 cameras all had audio flowing. The RTSP stack appears to hardcode the audio track in the SDP regardless of whether the mic is actually producing data. The firmware doesn’t care and advertises the track anyway.
This causes real problems downstream. Any NVR or player that tries to sync audio with video will stall or break. In Frigate specifically, ffmpeg’s segment muxer hung waiting for audio frames that never arrived, so no recordings were written and the process leaked memory until it consumed 1.3GB and ate all available RAM. The live view broke because go2rtc passed the phantom audio track to the browser’s MSE player, which stalled on audio sync.
The fix was to pipe the stream through ffmpeg with -an before go2rtc ever sees it, using an exec: source that strips the track entirely. Various go2rtc-level audio filters (#audio=no, #video=h264, etc.) did not work, the empty track still passed through.
The real bug is in the firmware. If the mic is disabled when integrated with the floodlight or non-functional, the RTSP stack should either omit the audio track from the SDP or send silent frames. Advertising a track and then sending nothing is out of spec and breaks standards-compliant clients.
1 Like
See my response after your post re SDP.
Welcome to the Forum, @YuanyeGe! 
This doesn’t address the final part of your comment, but since you mentioned Blue Iris in the first part, I’d note that some users have reported success by setting Model to VLC-compatible RTSP, as noted here:
This seems to be another instance of a client behaving differently, as you described.
1 Like
Hi @Alanant,
- How did you disable the mic so that no audio is sent to the RTSP? What the settings you change in the APP?
Does this issue only happen in Floodlight v1 or happen on both v3 and Floodlight v1? - Could you also submit a log for this?
Fld v1 uses an external mic, I guess it’s related to this.
@WyzeZZ I did further testing today. I started with a factory reset before re-pairing. Same result. Its conclusive that the camera advertises an audio track (PCMU/8000) in its RTSP SDP (Session Description Protocol) negotiation, but then sends zero audio data. Every other v3 camera on my network advertises the same audio track and actually sends audio packets.
I’m using the camera’s through Frigate which uses WebRTC through go2rtc, which negotiates both video and audio tracks based on what the camera advertised. The browser sets up both tracks and waits, video arrives fine, but audio never comes. The player stalls indefinitely waiting for the audio stream.
My workaround is to pipe the camera’s RTSPS stream through ffmpeg with -an (strip audio) before it reaches go2rtc. This removes the phantom audio track entirely, so WebRTC only negotiates video and playback works immediately.
Its clear that the fault lies with a firmware/manufacturer RTSP implementation bug, not a hardware issue. The problem is that the firmware’s RTSP server incorrectly includes an audio media line in its SDP response when it has no intention of sending audio data. A correct RTSP implementation should either:
-
Send the audio data it advertises, or
-
Not advertise the audio track at all
It looks like Wyze uses a generic RTSP stack (SmolRTSP, visible in the SDP) and doesn’t properly configure it to match the device’s actual capabilities. A firmware update from Wyze could fix it.
Audio works fine via the Wyze app through their proprietary Tutk/P2P protocol. The RTSP beta firmware is a separate code path, and for the floodlight variant, they’re advertising the audio track in SDP but failing to actually pipe the mic data into the RTSP stream. I assume that during setup, choosing “floodlight” probably triggers a different firmware configuration path that changes how the audio track is handled, possibly reserving the audio channel for the siren/speaker functionality or for two-way talk through the floodlight base, but not actually streaming microphone audio over RTSP.
A conclusive test would be to reset again and set the camera up as a v3 and not choose the floodlight.
1 Like
imo, if u have v3 cameras just flash thingino and be done with it, true onvif and rtsp fw, I did it to my three v3 cameras and not looking back, easier to flash than I thought it would be
1 Like
vincom,
We can flash Panv3s with this? I thought there was something with the chip being burned to not allow any 3rd party flashing.
He’s only talking about Cam V3. Cam Pan V3 has secure boot enabled so the only way to do it is to replace and solder another Ingenic T31 chip (without secure boot). That’s a lot of work to get it working.
Confirmed the issue is with the Floodlight.
If you are only using v3 or pan v3, things will be fine.
Trying to fix this issue..
2 Likes