Occasional Stutter in Camera Display

[tbrausch]

I have a question that is not easily asked unless I briefly describe the entire setup for my 4 V3 Wyze Cams. Since I am using several addons, I'm not sure the appropriate forum to post this, but I will try here first.

My Setup

1. First of all, I am running wyze_mini_hacks on all 4 cameras and have the rtsp function enabled for LOW_RES (640x360). I use this stream for the detection role in frigate and it works flawlessly with extremely low cpu usage. The HIGH_RES streams in wyze_mini_hacs tend to have a lot of issues with tearing and pixelation in the video, so I have this disabled.

2. I am also running the Wyze Bridge addon with all 4 wyze cameras configured to get a high resolution rtsp stream. I use the rtsp streams from Wyze Bridge in frigate for the recording and rtmp roles.

3. I also have the go2rtc addon installed to get low latency WebRTC display for all cameras in Home Assistant. The frigate rtmp streams are used as the source streams for go2rtc.

Results

1. I have frigate configured to record from all 4 cameras when motion is detected. When viewing the recordings, there are no issues whatsoever. There is no stuttering, no tearing, and no skipping of frames.

2. When viewing the cameras in Home Assistant, there is extremely low latency on the cameras (less than 1 second). However, the display for all of the cameras occasionally stutter - the video stops for a short time (around a 1/4 to 1/2 second) and then either jumps forward to realtime, or plays faster for a short time to catch up. I have also tried to display the cameras directly from the Wyze Bridge rtsp stream (via go2rtc) with the same results.

3. My frigate recordings previously exhibited the same issue with stuttering. To fix this I changed the FFMPEG input_args in frigate from

input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -rtsp_transport tcp -timeout 5000000 -use_wallclock_as_timestamps 1

to

input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -rtsp_transport tcp -timeout 5000000

I read about this change in the frigate forums, tired it, and it solved my problem - not sure why - I must confess to being a newbie with regards to FFMPEG.

My Question
In frigate the rtsp source streams come from Wyze Bridge, so I am trying to understand why recordings work flawlessly, but realtime display of the video stream does not. The frigate documentation states that the rtsp stream is passed unchanged as a rtmp output stream. So I'm wondering if there are ffmpeg flags I can set in Wyze Bridge or go2rtc that would help. I know this is a vague question, but I'm hoping that someone else is using the same addons with success and that they can share their experience with me.

[mrlt8]

That's a good question. The default config is currently using:

 - FFMPEG_FLAGS=-fflags +genpts+flush_packets+nobuffer+bitexact -flags +low_delay

I wonder if we might be able to tweak some of those flags or if it's an issue with the camera sending/resending the frames in bursts?

[foureight84]

Yea I think it's wyze firmware that is mostly the issue. But so far wyze-bridge has been the most reliable connection for my V3's. The wz_mini_hacks are only being used to prevent firmware upgrades and night vision from dropping fps. I am not sure if go2rtc will make things any better when the underlying problem might be the firmware. But it might simplify the setup a bit.

It seems that the iCamera process likes to phone home a lot as reported by a few users and it doesn't like not being able to and would reset itself. wz_mini_hacks has a patch that prevents iCamera from doing that but given that I lose connections every other hour for a minute or so, I would rather have the stuttering but more stable recording with wyze-bridge.

[tbrausch]

FYI: Version 4.36.2.5 of the V3 Wyze firmware was the last to not require access to the internet. I have installed this version to all my V3 cameras and once the cameras are booted up, I can disable internet access to the cameras via my router and everything still works fine - Wyze Bridge as well as wyze_mini_hacs RTSP. I can actually reboot the cameras after disableing the internet access and everything still works except they do not have access to an NPT time server - so the cameras then have the wrong timestamp. I hope to research setting up my own time server on a local Windows PC to get around this limitation.

[foureight84]

FYI: Version 4.36.2.5 of the V3 Wyze firmware was the last to not require access to the internet. I have installed this version to all my V3 cameras and once the cameras are booted up, I can disable internet access to the cameras via my router and everything still works fine - Wyze Bridge as well as wyze_mini_hacs RTSP. I can actually reboot the cameras after disableing the internet access and everything still works except they do not have access to an NPT time server - so the cameras then have the wrong timestamp. I hope to research setting up my own time server on a local Windows PC to get around this limitation.

That's good to know. I will switch that firmware and see how that goes.

[mrlt8]

Not sure if it will help, but we should be able to set the time on the camera over the tutk protocol cbbcc98

[tbrausch]

That would be great! Since you referenced a commit does this mean it might be available in the next release?

[tbrausch]

I just received another V3 camera from Wyze (had a small gift certificate to use) and I have set this camera up just like the others (see above posts). The funny thing is, this camera works perfectly - there are no dropped frames or stutttering when displaying the video feed in 1080P. All four others cameras exhibit problems. Has Wyze changed something under the hood in the newer V3 cams?

[foureight84]

I just received another V3 camera from Wyze (had a small gift certificate to use) and I have set this camera up just like the others (see above posts). The funny thing is, this camera works perfectly - there are no dropped frames or stutttering when displaying the video feed in 1080P. All four others cameras exhibit problems. Has Wyze changed something under the hood in the newer V3 cams?

What firmware version is it running? Also if you have wz mini hacks running on it, you can see more details about the hardware description under the ~/.configs directory. Here's my readout:

[root@WCV3-PORCH:~]# cat .product_config

[XIAOMI]
CONFIG_INFO=2CAA8EFA8010|||1080

[TYPE]
PRODUCT_MODEL=WYZE_CAKP2JFUS
PRODUCT_TYPE=camera

[HUALAI]
FACTORY_TEST=0000
BOARD_TEST=0FFF
...
HARDWARE_VER=T00A0000

[tbrausch]

As I mentioned above, I am running Version 4.36.2.5 of the V3 Wyze firmware which was the last to not require access to the internet. Output from .product_config:

[XIAOMI]
CONFIG_INFO=D03F274F137E|||0000

[TYPE]
PRODUCT_MODEL=WYZE_CAKP2JFUS
PRODUCT_TYPE=camera

[HUALAI]
FACTORY_TEST=0000
BOARD_TEST=0FFF
...
HARDWARE_VER=P00A0000

Looks like a difference in the HARDWARE_VER but I could not find any info on the internet about it. When I get a chance I will try the wyze_mini_hacks 1080P RTSP on it and see if I get the tearing and pixelation on the new camera.

Note: I just tried the wyze_mini_hacks 1080P RTSP on the new camera and it still has the same issues as the older V3s.

[foureight84]

Interesting. Maybe they did update the hardware and the result is better performance that you're seeing.

[tbrausch]

Afraid not - I just checked the other 4 cameras and 2 have the hardware version P00A0000 and 2 have the version T00A0000. Maybe the new camera is just having a good day :-)