search

mrlt8 / docker-wyze-bridge

WebRTC/RTSP/RTMP/LL-HLS bridge for Wyze cams in a docker container
GNU Affero General Public License v3.0
2.66k stars 168 forks source link

All streams buffering #221

Open oParoxysm opened 3 years ago

oParoxysm commented 3 years ago

Currently running a VPS on my mining rig with a docker instance of the wyze-bridge. (Testes on two VPS's, one locally and one in a remote datacenter)

When viewing streams, they play back normally for 5-20 seconds, then buffer for a few seconds. This keeps happening on repeat, and never "steadies" out. Something else I've noticed that the time in the bottom right of the stream goes faster than actual seconds sometimes.

Any assistance would be nice, as the cameras buffer for 2-10 seconds at times, and that causes the stream to be really behind at times.

mrlt8 commented 3 years ago

Is this on the HLS or RTSP stream?

oParoxysm commented 3 years ago

Is this on the HLS or RTSP stream?

I'm using HLS and RTMP. They buffer and then skip to real time - delay. Right now I'm using HLS for my browser and RTMP inside of VLC/OBS does this.

m50 commented 2 years ago

I also noticed this, using RTSP. Additionally, I noticed that it is about 10 seconds behind real time as well. So I move in front of the camera, and 10 seconds later it appears in my dashboard.

mrlt8 commented 2 years ago

@m50 Is it much worse than what you see in the wyze app? I believe rtsp should have the least delay.

m50 commented 2 years ago

Wyze app is real time. 0 delay whatsoever. But with this, it's behind by about 10s (sometimes a little more, sometimes a little less).

oParoxysm commented 2 years ago

I also see 0 delay in the Wyze app, but when viewing the stream, the stream is always delayed at a minimum of 5 seconds. When the stream buffers, it starts playing back at 1.5x speed, then when it gets to the end of the buffer, it starts to buffer again. This infinitely repeats.

DennisGarvey commented 2 years ago

I am experiencing the same symptoms as everyone else on the latest version (1.0.3) as well

m50 commented 2 years ago

Logs:

wyze-bridge    | 🚀 STARTING DOCKER-WYZE-BRIDGE v1.0.3
wyze-bridge    | 
wyze-bridge    | 2021/11/26 20:43:36 [WyzeBridge] 📚 Using 'user' from local cache...
wyze-bridge    | 2021/11/26 20:43:36 [WyzeBridge] 📚 Using 'cameras' from local cache...
wyze-bridge    | 
wyze-bridge    | 🎬 STARTING ALL 3 CAMERAS
wyze-bridge    | 2021/11/26 20:43:36 [WyzeBridge] Starting rtsp-simple-server v0.17.8
wyze-bridge    | 2021/11/26 20:43:38 [Living Room] 🎉 Starting HD 60kB/s Stream for WyzeCam V3 "LAN mode" FW: 4.36.7.22 🔒 (DTLS) IP: 192.168.68.50 WiFi: 96%
wyze-bridge    | 2021/11/26 20:43:38 [Living Room] WARNING: [First run] Wrong resolution: 1
wyze-bridge    | 2021/11/26 20:43:38 [Living Room] WARNING: Frame not available
wyze-bridge    | 2021/11/26 20:43:38 [Bedroom] 🎉 Starting HD 60kB/s Stream for WyzeCam V3 "LAN mode" FW: 4.36.7.22 🔒 (DTLS) IP: 192.168.68.55 WiFi: 92%
wyze-bridge    | 2021/11/26 20:43:38 [Bedroom] WARNING: [First run] Wrong resolution: 1
wyze-bridge    | 2021/11/26 20:43:38 [Living Room] WARNING: Frame not available
wyze-bridge    | 2021/11/26 20:43:38 [Hallway] 🎉 Starting HD 60kB/s Stream for WyzeCam V3 "LAN mode" FW: 4.36.7.22 🔒 (DTLS) IP: 192.168.68.51 WiFi: 91%
wyze-bridge    | 2021/11/26 20:43:38 [Hallway] WARNING: [First run] Wrong resolution: 1
wyze-bridge    | 2021/11/26 20:43:38 [Bedroom] WARNING: Frame not available
wyze-bridge    | 2021/11/26 20:43:43 [RTSP][LIVING-ROOM] ✅ '/living-room' stream is UP!
wyze-bridge    | 2021/11/26 20:43:43 [RTSP][LIVING-ROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:43:43 [RTSP][HALLWAY] ✅ '/hallway' stream is UP!
wyze-bridge    | 2021/11/26 20:43:43 [RTSP][BEDROOM] ✅ '/bedroom' stream is UP!
wyze-bridge    | 2021/11/26 20:43:43 [RTSP][HALLWAY] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:43:43 [RTSP][BEDROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:43:49 [RTSP][HALLWAY] 📕 Client stopped reading
wyze-bridge    | 2021/11/26 20:43:49 [RTSP][BEDROOM] 📕 Client stopped reading
wyze-bridge    | 2021/11/26 20:43:50 [RTSP][LIVING-ROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:43:50 [RTSP][BEDROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:43:50 [RTSP][LIVING-ROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:43:55 [RTSP][LIVING-ROOM] 📕 Client stopped reading
wyze-bridge    | 2021/11/26 20:44:03 [RTSP][LIVING-ROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:44:032021/11/26 20:44:03 [RTSP][LIVING-ROOM] 📕 Client stopped reading
wyze-bridge    |  [RTSP][LIVING-ROOM] 📕 Client stopped reading
wyze-bridge    | 2021/11/26 20:44:20 [RTSP][BEDROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:44:20 [RTSP][HALLWAY] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:44:20 [RTSP][HALLWAY] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:46:49 [RTSP][HALLWAY] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:46:50 [RTSP][BEDROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:46:55 [RTSP][BEDROOM] 📕 Client stopped reading
wyze-bridge    | 2021/11/26 20:46:55 [RTSP][LIVING-ROOM] 📖 New client reading 
wyze-bridge    | 2021/11/26 20:47:00 [RTSP][HALLWAY] 📕 Client stopped reading
wyze-bridge    | 2021/11/26 20:47:07 [RTSP][LIVING-ROOM] 📕 Client stopped reading

docker-compose:

version: '2.4'
services:
  wyze-bridge:
    container_name: wyze-bridge
    restart: unless-stopped
    image: mrlt8/wyze-bridge:latest
    ports:
      - 1935:1935
      - 8554:8554
      - 8888:8888
    environment:
      - 'WYZE_EMAIL=email@me.tld'
      - 'WYZE_PASSWORD=my-password'
      - SNAPSHOT=RTSP
      - 'QUALITY=HD60'
      - NET_MODE=LAN
    volumes:
      - ./tokens:/tokens/

And here's a video of how much delay there is:

https://user-images.githubusercontent.com/3577147/143637565-d6312dad-2046-426b-8af5-3c7b76cd1b5b.mp4

And for what its worth: The light changed instantly when I clicked the button, the delay is 100% in the video.

m50 commented 2 years ago

I also noticed that if I turn on DEBUG_FRAMES, the logs get spammed with:

wyze-bridge    | 2021/11/26 20:43:30 [Hallway] WARNING: Frame not available
wyze-bridge    | 2021/11/26 20:43:30 [Bedroom] WARNING: Frame not available
wyze-bridge    | 2021/11/26 20:43:30 [Living Room] WARNING: Frame not available
xconverge commented 2 years ago

Same problems as others reporting here (I understand this issue predates 1.0.3 but it seems relevant?), I did a little bit of bisecting

1.0.0 looks good 1.0.1 looks good 1.0.2 looks good (albeit with the memory leak after a few days or hours) 1.0.3 buffering every ~5 seconds as mentioned here

mrlt8 commented 2 years ago

The "Frame not available" error is related to AV_ER_DATA_NOREADY, which usually means a poor connection to the camera:

The data is not ready for receiving yet.

1.0.3 will break out of that loop if it receives 500 or more consecutive AV_ER_DATA_NOREADY since the rtsp-simple-server connection will break if it does not receive any data.

Is there a delay if using a single camera?

DennisGarvey commented 2 years ago

I used to be on a really old version of this project and old camera firmware but when I brought everything up to date I started having issues, no change in wifi strength.

xconverge commented 2 years ago

@mrlt8 FWIW (and I think we might be mixing a few issues here, hard to say) I experience the constant buffering with a single camera only in my setup

m50 commented 2 years ago

Is there a delay if using a single camera?

Yeah, I tried filtering to only support one camera, and the delay was exactly the same.

DennisGarvey commented 2 years ago

I am also noticing that when it lags, the rtsp stream displays them out of order, the timestamp would jump between frames 5 seconds before and current frames.

m50 commented 2 years ago

Well, I switched to webrtc card and my delay is gone. There is still some delay, but it's nothing compared to the picture card.

So for people using this with HA: I highly recommend trying that card if you are having lag.

Correction: Buffering still happens, but the delay is gone. So it sometimes skips ahead by like a second, but far less frequently.

xconverge commented 2 years ago

The separate problems I see in this issue are 1) constant buffering and frame skipping in newer versions and 2) delay compared to wyze app

xconverge commented 2 years ago

@mrlt8 do you want me to open up a separate issue? 1.0.4, 1.0.3 and 1.0.2 are all pretty unusable and I want to help get the data needed to resolve it.

I have 1 V3 camera, and either get ~5 second skips every ~10 seconds in the latest version or buffering every few seconds in 1.0.2. Tested HLS and RTSP, both are unusable

I have 0 errors or warnings or messages in the log

2022/01/09 17:18:27 [camera1] 🎉 Starting HD 120kB/s Stream for WyzeCam camera1 "LAN mode" FW: 4.36.8.15 🔒 (DTLS) IP: xxx.xxx.xxx.xxx WiFi: 79%
mrlt8 commented 2 years ago

I think this might have something to do with the buffer which was also causing that memory leak issue.. I'll try to play around with it some more.

Could you also try to physically reboot the camera? I've noticed some weird issues communicating with the cameras that will sometimes go away after a reboot.

xconverge commented 2 years ago

I think this might have something to do with the buffer which was also causing that memory leak issue.. I'll try to play around with it some more.

Could you also try to physically reboot the camera? I've noticed some weird issues communicating with the cameras that will sometimes go away after a reboot.

I agree that it seems related to the the part of the code with that recent buffer/memory leak

Sorry, I decided to just try the RTSP FW for the V3 and so far it has been solid, I will poke back in if I have issues and try to get you the data you need. A few other people seem to be having similar problems so maybe someone else has an active/problematic setup that can help a bit

bittles commented 2 years ago

So was running this with the home assistant addon on the RTSP firmware and was working perfectly. So, I decided if I wasn't going to use sound I might as well upgrade to the latest firmware and take advantage of DTLS and further firmware upgrades. Upgraded one camera that was easy to reach and decided to do the others later since I need a ladder to get to them. The DTLS firmware camera then would stream fine for 10-12 seconds, then skip/stutter for a 4-5 second break. Been like that for 2-3 weeks now as I tried to sort out the issue but couldn't.

Then came across this. Decided to stop the addon and recreate in a Portainer stack pulling version 1.0.0. DTLS firmware camera better, but still not as smooth as RTSP firmware camera. Rebooted DTLS firmware camera, put fresh_data=true in the stack and re-created. Perfectly smooth. No stuttering or skips and performance of DTLS firmware camera and RTSP firmware camera are on par.

SomebodySysop commented 2 years ago

Then came across this. Decided to stop the addon and recreate in a Portainer stack pulling version 1.0.0. DTLS firmware camera better, but still not as smooth as RTSP firmware camera. Rebooted DTLS firmware camera, put fresh_data=true in the stack and re-created. Perfectly smooth. No stuttering or skips and performance of DTLS firmware camera and RTSP firmware camera are on par.

Been having stutter problem with DTLS myself: https://github.com/mrlt8/docker-wyze-bridge/issues/275#issuecomment-1022870100

My fix was to revert to earlier non-DTLS firmware. How did you fix the problem? I see put fresh_data=true in the stack and re-created but don't understand what that means.

I am running Portainer. My docker-wyze-bridge stack says: "This stack was created outside of Portainer. Control of this stack is limited", but I can edit it. Just don't know where I would put "fresh_data=true". Little help?

CB954 commented 2 years ago

I think this might have something to do with the buffer which was also causing that memory leak issue.. I'll try to play around with it some more.

Could you also try to physically reboot the camera? I've noticed some weird issues communicating with the cameras that will sometimes go away after a reboot.

I tried rebooting the camera. Still did not resolve the issue.

Ceer123 commented 2 years ago

I have the same issue. Plays fine for about 10 seconds and then 3-5 seconds of buffering (Wyze timestamp frozen). Tried with just one camera and still saw the issue.

SomebodySysop commented 2 years ago

I have the same issue. Plays fine for about 10 seconds and then 3-5 seconds of buffering (Wyze timestamp frozen). Tried with just one camera and still saw the issue.

I believe this is an issue between DTLS and wifi connectivity. I live in a densely populated area, and have this problem with almost all of my Wyze V3 cams that are outside. I have reduced the buffering | stuttering by reverting the firmware to a non-DTLS version: https://github.com/mrlt8/docker-wyze-bridge/issues/275#issuecomment-1022870100

Buffering has reduced from every 10-15 seconds to every 20-30 seconds. Significant improvement, but not eliminated.

I suggest, as a test, you try reverting to firmware version 4.36.3.19 to see if there is any difference in performance.

tcnasc commented 2 years ago

Just tried this today and had the same issues in all my 3 cameras (2 v2 and Doorbell): the video would freeze every 10s and then recover skipping the next 5s. When I reverted to v1.0.1 the problem was gone. All my cameras are in the latest FW (from the main Wyze stream, not RTSP)

tcnasc commented 2 years ago

Tested v1.1.0 with 1 doorbell and this problem persists. It seems a bit better, freezing every 20-30s for around 5-10s, but it's still there. Reverted to 1.0.2 and it works fine. Also, on 1.1.0 I had to change IGNORE_RES to 3 instead of 4 in 1.0.2

fgarcia78 commented 2 years ago

Having similar problems with 1.0.4 and the recently deployed 1.1.0. Reverted container to 1.0.2. and it's now working rock solid for several minutes (getting almost the same performance as Wyze app): no AV_ER_DATA_NOREADY errors or dropped frames. I have three v3 cams with latest FW and i'm running this with just one of them.

I'm testing this on Win10 using Docker Desktop with WSL2 backend (!!) ... just fiddling with this to eventually migrate to a Raspberry Pi or HPE dedicated server with Linux.

mrlt8 commented 2 years ago

Does increasing the MAX_NOREADY value to something like 300 help?

v1.1.x is also dropping frames until it receives a keyframe to prevent the corrupt frames/time glitches, so we may have to tweak that a bit more.

@tcnasc v1.1.x should already ignore 3 if IGNORE_RES is not set. Can you try running the container without IGNORE_RES?

https://github.com/mrlt8/docker-wyze-bridge/blob/d899495e6ba8b421cffbd54c5232e35c4b2d92cd/app/wyzecam/iotc.py#L414

tcnasc commented 2 years ago

@mrlt8 You're right, I don't need to set IGNORE_RES anymore with 1.1.0 I tested with MAX_NOREADY=300 and the issue is still there. I'm running on Pi OS by the way Enabling the debug logs I noticed that when the stream breaks, the Frame Not Available counter starts increasing up to 40-60 and then returns to constant 1 which is when the stream starts working again. So it looks like the frame not available is actually a consequence and not the cause of the stream breaks.

tcnasc commented 2 years ago

Just tested v1.1.2 and the buffering problem is still there. Even with MAX_NOREADY=0, unfortunately Had to revert to v1.0.2 again :(

mrlt8 commented 2 years ago

When you say buffering, do you mean that the video will skip a few seconds?

v1.1.2 now has a KEEP_BAD_FRAMES option, which, when set to true, will keep frames which may be missing a keyframe, but could potentially fill in those gaps.

tcnasc commented 2 years ago

The stream is lost for 5-10 seconds (VLC even shows it's 'loading' spinning icon) and then resumes (skipping the lost period) I could try to play with KEEP_BAD_FRAMES but then again, v1.0.2 doesn't have this problem so I'm not sure if there are indeed bad frames.

Ceer123 commented 2 years ago

Just tested with v1.1.2 and didn't see a change with any of these tests 1.1.2 with no settings change 1.1.2 with KEEP_BAD_FRAMES checked 1.1.2 with MAX_NOREADY set to 0

I still see the wyze timestamp skip about 6-7 seconds every 10 or so seconds.

mrlt8 commented 2 years ago

Thanks for the info @Ceer123, I think I might know where it might be getting stuck now.

mrlt8 commented 2 years ago

Could someone test the dev build? It should work more like the older versions, but may also have the same memory leak issue.

tcnasc commented 2 years ago

Just tested the dev build and it's working without buffering!

Ceer123 commented 2 years ago

I ran the dev for a couple hours and can confirm the streams are working fine with no buffering. It also appears the memory is increasing as expected. image

mrlt8 commented 2 years ago

Thanks for the graph @Ceer123, I was noticing a similar leak as well.

I pushed a commit https://github.com/mrlt8/docker-wyze-bridge/commit/2a2bc6ef93bf952c22a6b7f904e646bd85f16646 to the dev branch to use the depreciated avClientSetMaxBufSize, and, from what I can tell so far, it doesn't seem to leak as bad as the newer method with ram usage staying under 200mb.

mrlt8 commented 2 years ago

avClientSetMaxBufSize in the last commit also seems to suffer from the memory leak.

I pushed another commit https://github.com/mrlt8/docker-wyze-bridge/commit/49488d31ad2b9c175288a2ecf1e1db48a8f038d7 to the dev branch that should attempt to clear the buffer every 500 frames. I've been running it for the past half hour or so, and memory usage seems to be hovering at or below 100mbs.

Feedback would be appreciated!

quhar commented 2 years ago

I'm also experiencing the same issue. Stream stops for 10 seconds every 30-60 seconds. I enabled DEBUG_FRAMES and saw a lot of WARNING: Dropping old key frame messages whenever stream was paused. I just pulled dev Docker image and it's night and day. I see almost no pauses in streaming (roughly 1s "slowdowns" every 10-20s). Lag between wall time and Wyze timestamp is ~1-2s.

Ceer123 commented 2 years ago

Looks good on the latest dev branch commit. Video is good and memory looks good for two hours. I will leave this running. image

mrlt8 commented 2 years ago

Awesome!

(roughly 1s "slowdowns" every 10-20s)

Is the slowdown visible in the app? I wonder if it's the av_client_clean_local_buf that's running every 500 frames that is causing it to slowdown which would be 500/20 or 500/15 so about every 25~30 seconds?

quhar commented 2 years ago

Hmm, today I don't see any pauses. Stream is stable, with low lag to wall time. Maybe it was coming from cameras as it was dark and they were running in night mode. I'll check it once it gets dark. But anyway, it is much much better. Thanks!

tcnasc commented 2 years ago

Using v1.2.0 and working great now. Thank you so much @mrlt8! Excellent job, this bridge is awesome

mrlt8 commented 2 years ago

@quhar Any more issues with the slowdown?

I believe I've narrowed down the memory leak to the audio getting buffered even though we're not using it. Disabling the audio at connection seems to help, and we wouldn't need to clear the buffer manually which could potentially help _if that is what is causing the slowdown.

quhar commented 2 years ago

I'm running v1.2.0 and everything is almost smooth. I see small "jitter". Every few sec (but no pattern here, sometimes it's 5s sometimes it's 10s) there is brief pause. It looks like some seconds on Wyze timestamp last for 1.5s. I'm using mpv player to stream data from the server. When I display stream stats it looks that buffer fill is not fast enough. Buffer starts with 1s, then over time drops to 0 (there is when there is a brief pause in the video) and get's filled to ~1s and cycle repeats. I don't see this effect with Wyze app. I was testing it with KEEP_BAD_FRAMES enabled and disabled. Setting DEBUG_LEVEL=debug shows a lot of Frame not available:

Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:03 szafka 2d9346724609[1608]: 2022/02/25 08:05:03 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [2/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [2/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [3/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:04 szafka 2d9346724609[1608]: 2022/02/25 08:05:04 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Back Yard Cam] Frame not available [1/100]
Feb 25 00:05:05 szafka 2d9346724609[1608]: 2022/02/25 08:05:05 [wyzecam.iotc][DEBUG][Baby Cam] Frame not available [1/100]

Are there any other options I can tweak to get more info? My current setup is below. 

  wyze-bridge:
    container_name: wyze-bridge
    restart: unless-stopped
    image: mrlt8/wyze-bridge:latest 
    volumes:
      - /srv/wyze-bridge/tokens:/tokens/
    ports:
      - 8554:8554
      - 8888:8888
    environment:
      - WYZE_EMAIL=##############
      - WYZE_PASSWORD=##############
      - NET_MODE=LAN
      - QUALITY=HD120
      - RTSP_READTIMEOUT=60s
      - RTSP_WRITEIMEOUT=60s
      - KEEP_BAD_FRAMES=True
      - DEBUG_FRAMES=True

Thanks for the latest fixes and great work. In general streams are of good quality.

mrlt8 commented 2 years ago

Interesting. We may need to play around with the FFMPEG commands.

RUHavingFun commented 2 years ago

Been having a similar issue. Currently I am running only two cams per RPi4 4GB 64bit Buster. Setup is:

services:
    wyze-bridge:
        container_name: wyze-bridge
        network_mode: host
        restart: always
        pull_policy: always
        image: mrlt8/wyze-bridge:latest
        environment:
            - NET_MODE=LAN
            - FRESH_DATA=true
            - WYZE_EMAIL=***
            - WYZE_PASSWORD=***
            - QUALITY=HD120
            - MAX_NOREADY=100
            - RTSP_PATHS_ALL_READUSER=***
            - RTSP_PATHS_ALL_READPASS=***
            - RTSP_PROTOCOLS=tcp
            - FILTER_NAMES=CAM Front, CAM Garage

Will add a 3rd again soon to see it introduces instability again.

SomebodySysop commented 2 years ago

I don't have any numbers, but I can attest to a change I see visually after updating to latest build. I've got 6 Wyzecams running on the bridge under Ubuntu Linux. I had 9, but have slowly been replacing them with wired cams due to this very issue. Before this update, I would have "skips" in the video streams -- that is, I'd see a person walking for a few seconds, then they would disappear from video. With this latest update, with that same person walking, I might see a slowdown in their movement, but they never just "disappear". Still some image shadowing, but overall a more consistent stream than before.

I am in a densely populated urban area, so some wifi interference is expected. This latest bridge build appears to have improved my overall streaming results. Thank you!

version: '2.4' services: wyze-bridge: container_name: wyze-bridge restart: unless-stopped image: mrlt8/wyze-bridge:latest # Use a prebuilt image

build: # Uncomment to build from source

    #     context: ./app # Uncomment to build from source
    #     # dockerfile: Dockerfile.arm # Uncomment to build for arm
    ports:
        - 1935:1935
        - 8554:8554
        - 8888:8888
        - 9997:9997 # Expose port for API
    environment:
        - RTSP_READTIMEOUT=120s
        - RTSP_APIADDRESS=0.0.0.0:9997
        - RTSP_API=yes            
        - DOCKER_HOST=192.168.1.219
        - WYZE_EMAIL=***
        - WYZE_PASSWORD=***
        - FILTER_NAMES=WyzeCam301, WyzeCam302, WyzeCam303, WyzeCam308, WyzeCam307, etc...           
        - FRESH_DATA=true