Help Fix bitrate and super slow errors #1194
Comments
airbornetrooper82573
changed the title
|
Can you try the latest dev build to see if that helps with the stability of the streams? |
|
I switched to dev and same thing. Still getting bitrate does not match and super slow errors. I can't even get streams to play on the bridge web GUI and definitely not Home app. I did change the rtsp url to rtsp://wb:thekeythatisdisplayedatthebottomofthebridgegui@192.168.1.215:8554/driveway-v4 |
|
I figured out the web gui part, I had my truenas server's IP as the WB_IP. I can see the feeds on WB gui fine now. Still can't get it to show up in Scrypted or Home app. |
|
hmm, what kind of cam is back-yard-cam? I'm not sure where FYI, the bridge will generate a random API key on startup if you don't define one or it doesn't find one in the local directory. environment:
...
- WB_API=MyCustomAPIKeyor volume mount the token directory: environment:
...
volumes:
- /path/to/store/tokens/on/host:/tokensand it will reuse the same data on subsequent starts. |
|
I added the custom key. In scrypted, I'm leaving user/pass blank and putting in rtsp://wb:mycustomkey@192.168.1.215:8554/driveway-v4 and still no snapshot or anything. The back-yard-cam is a v3. |
|
can you open rtsp://wb:mycustomkey@192.168.1.215:8554/driveway-v4 in another media player like VLC? |
|
It's not loading in VLC |
|
What about just |
|
I got both ways to work in VLC. I think my phone changed rtsp to rtps and I did't catch it. In scrypted do I put in wb for username and my api as password and put the plain RTSP stream URL in? |
|
I would try the plain RTSP url with the credentials in the fields since it has that option and will make it easier to maintain in the future. |
|
I did that for all 3 cameras and still not working on scrypted or Home. [Back Yard Cam] rebroadcast error Error: rtsp socket closed |
|
I can only get the RTSP feed to work in Scrypted if I set WB_AUTH=False |
* Tweak AV sync and ffmpeg cmd #1175 #1196 #1194 #1193 #1186 * Catch AccessTokenError * don't drop timestamp #1175 #1196 #1194 #1193 #1186 * Don't use_wallclock_as_timestamps #1175 #1196 #1194 #1193 #1186 * keep audio in sync #1175 #1196 #1194 #1193 #1186 * Ignore whitespaces in api key/id #1188 * Remove quotes from credentials #1158 * HA Add FORCE_FPS option #1161 * FORCE_FPS option for all cameras #1161 * changelog
|
This seems tangentially related, but I'm getting the same error as mentioned above. I've had the issue for a while, but haven't had time to dig into it. It's a Cam v3, with the light socket add-on.
|
|
@WarrenSchultz are you running the latest version of the bridge? |
|
@mrlt8 Correct. I've tried both More details: |
|
That bug should have been fixed a while ago. Can you confirm you're running |
|
|
|
Thanks @WarrenSchultz! Does the Can you try manually changing the bitrate? |
|
Command successful, same error |
|
Hmm, can you reboot the problematic camera to see if that helps? |
|
I have this bitrate error no matter what bitrate I set. It's always complaining it doesn't match. Had it for a long time over several versions. I thought it was normal as everything works regardless. T |
|
Hmmm, does it actually seem to be setting the correct bitrate even thought camera is reporting the wrong bitrate? @letrain02 are you also running the beta firmware? And did the error start after updating to v1.9.x or after switching to the beta firmware? Would appreciate if you could try the following API endpoints to see if the camera is returning the correct bitrate somewhere: |
|
Not running beta firmware. Sorry. I used my mobile device and missed several comments in this thread. I noticed the bitrate and super slow in the issue. I get the super slow error initially when starting the container, but those subside after the cameras drop connection and come back online. But the bit rate issue always stays. Edit: bridge is 2.9.10
edit:2 all show bitrate 40 being returned. for me. {"command":"bitrate","payload":null,"response":40,"status":"success","value":40} |
Rebooted the camera, restarted docker container so everything is "clean", and this is the only camera in use to simplify debugging. In order: |
|
@letrain02 is it only the panv3s that have the issue? @WarrenSchultz Can you tell if the quality seems to change when adjusting the bitrate over the api? |
It's very odd, the traffic seems to be bursty instead of constant, and I'm not seeing the time counter increment smoothly by the second either. (Although this may be related to the issue we're looking at here?) I added another couple cameras which are also v3s. One is attached to a garage door controller, and one is a standalone. |
|
Thanks, are the other v3s also running the beta firmware? Could you see if the |
|
Yep, all the v3s are running the latest beta firmware. I just tried the edge container, and same results. |
|
So, I happened to have a new cam in box that I updated to 4.36.10.7146, and got this error instead: |
|
One last bit of info. Updated that cam up to the highest non-beta offered in the app, 4.36.11.8391, and I'm not seeing the message there. |
pano is pan v2. but yes it appears its only pan cameras; v3 and v2 with bitrate issue. my stationary v3's dont appear to have the bitrate complant, and appear correct when checking api {"command":"bitrate","payload":"","response":30,"status":"success","value":30}-v3 stationary. the stationary v3's do get super slow warning... i just blame my wifi and metal buildings though. edit: i tried edge and still that same. |
|
@mrlt8 so for fun i changed bitrate to SD40.... the v3-pans stopped complaining, but the v3 sationary cameras now complain that its not 30 bitrate.
|
|
Thanks for the feedback @letrain02 @WarrenSchultz! The It seems like wyze might be removing the ability to get the bitrate value from the camera on the latest firmware releases..? Could you try If that doesn't work, then we might just have to ignore the bitrate value entirely. |
If I understood properly, I accessed that URL, which returned the following. This was the result in the console: |
|
Thanks @WarrenSchultz Still looking to see if might be some issue decoding the responses from the camera. |
|
@mrlt8 Thinking further about this, since I did see a different version of that error on an earlier firmware during the upgrade process for the new cam, I'm wondering if it's some weird regex wonkiness going on with certain combinations of characters/values/etc. |
|
update from me. i moved some wifi nodes around, changed wyze-bridge to HD60, had a few mismatch errors at first, but letting it run all night (ondemand=false), and no errors, the logs are incredibly quite. not sure if it just didn't like SD30, or if it was just a wifi issue (too many collisions on 2.4ghz)... i have have some superslow warnings occasionally and my pano-v2 drops, and then complains. its most likely wifi for that as i moved some things around. |
|
Any improvement with adjusting the bitrate value on v2.9.12? Note: the actual bitrate response will not change since the camera doesn't seem to return the correct value. |
|
@mrlt8 It says it's pulling 180 when initializing, but the log continues to show the warning.
|
|
@WarrenSchultz could you try the edge branch to see if that gets rid of the log spam? |
|
@mrlt8 Yup, log spam is gone. Oddly, Frigate is getting 401 errors trying to pull from the cameras now though. Haven't had time to dig into why that would be. |
|
@mrlt8 Ah, fixed in the latest code. Some of the auth stuff changed I see. |
|
So to go back to the other part of the OP's issue, the "super slow" reports are odd, given the high wifi signal strength. What is the metric used to issue that warning? |
|
The timestamp returned with each video frame is drifting behind the current time on the bridge. Is it worse on the latest version? |
|
Had some power flickers last night, it's possible that something was up with the wireless after all that. |
I have 2 V4 cams and 1 v3. I'm getting these errors now and I'm not sure how to fix them. I can't seem to load the feeds on my iPhone anymore either.
My compose:
version: '2.4'
services:
wyze-bridge:
container_name: wyze-bridge
network_mode: host
restart: unless-stopped
image: mrlt8/wyze-bridge:latest
ports:
- 1935:1935 # RTMP
- 8554:8554 # RTSP
- 8888:8888 # HLS
- 8889:8889 #WebRTC
- 8189:8189/udp # WebRTC/ICE
- 5000:5000 # WEB-UI
environment:
# [OPTIONAL] (Can be set in the WebUI):
- WYZE_EMAIL=myemail
- WYZE_PASSWORD=mypass
- API_ID=my api ID
- API_KEY=my api key
# [OPTIONAL] IP Address of the host to enable WebRTC e.g.,:
- WB_IP=192.168.1.50
- ON_DEMAND=False
- IGNORE_OFFLINE=true
- FPS_FIX=true
- IGNORE_RES
My errors:
[WyzeBridge] 192.168.1.102 - - [13/May/2024 17:08:44] "GET /signaling/front-porch-cam?webrtc HTTP/1.1" 200 - [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 23%) FW: 4.52.3.9455 🔒 [front-porch-cam] Re-encoding audio for compatibility with WebRTC in MTX [front-porch-cam] 🔊 Audio Enabled - AAC_ELD > LIBOPUS/16,000Hz [front-porch-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] [front-porch-cam] [video] super slow [front-porch-cam] WARNING: clear buffer [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] [video] super slow [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] [video] super slow [WyzeBridge] ✅ '/front-porch-cam stream is UP! (3/3) [WyzeBridge] 📖 New client reading from front-porch-cam [front-porch-cam] [video] super slow [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [WyzeBridge] 📕 Client stopped reading from front-porch-cam [front-porch-cam] WARNING: Audio pipe closed [front-porch-cam] Stream stopped [WyzeBridge] ❌ '/front-porch-cam' stream is down [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [WyzeBridge] ❌ '/front-porch-cam' stream is down [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 25%) FW: 4.52.3.9455 🔒 [front-porch-cam] [Exception] Unable to identify audio. [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 24%) FW: 4.52.3.9455 🔒 [front-porch-cam] [Exception] Unable to identify audio. [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 23%) FW: 4.52.3.9455 🔒 [front-porch-cam] [Exception] Unable to identify audio. [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 21%) FW: 4.52.3.9455 🔒 [front-porch-cam] Re-encoding audio for compatibility with WebRTC in MTX [front-porch-cam] 🔊 Audio Enabled - AAC_ELD > LIBOPUS/16,000Hz [front-porch-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] WARNING: Still waiting for first frame. Updating frame size. [front-porch-cam] Requesting frame_size=3, bitrate=180, fps=0 [front-porch-cam] WARNING: Audio pipe closed [front-porch-cam] [Exception] Did not receive a frame for 20s [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 25%) FW: 4.52.3.9455 🔒 [front-porch-cam] Re-encoding audio for compatibility with WebRTC in MTX [front-porch-cam] 🔊 Audio Enabled - AAC_ELD > LIBOPUS/16,000Hz [front-porch-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] [front-porch-cam] [video] super slow [front-porch-cam] WARNING: clear buffer [WyzeBridge] ✅ '/front-porch-cam stream is UP! (3/3) [WyzeBridge] 📖 New client reading from front-porch-cam [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] WARNING: Audio pipe closed [front-porch-cam] Stream stopped [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [WyzeBridge] ❌ '/front-porch-cam' stream is down [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [WyzeBridge] 📕 Client stopped reading from front-porch-cam [WyzeBridge] ❌ '/front-porch-cam' stream is down [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 25%) FW: 4.52.3.9455 🔒 [front-porch-cam] Re-encoding audio for compatibility with WebRTC in MTX [front-porch-cam] 🔊 Audio Enabled - AAC_ELD > LIBOPUS/16,000Hz [front-porch-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] [WyzeBridge] ✅ '/front-porch-cam stream is UP! (3/3) [WyzeBridge] 📖 New client reading from front-porch-cam [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] WARNING: clear buffer [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0The text was updated successfully, but these errors were encountered: