Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bitrate Selection appears to be broken #1070

Open
fjrichman opened this issue Dec 28, 2023 · 9 comments
Open

Bitrate Selection appears to be broken #1070

fjrichman opened this issue Dec 28, 2023 · 9 comments

Comments

@fjrichman
Copy link

fjrichman commented Dec 28, 2023

So no matter what bitrate I select using the environment options for Docker it seems the cameras just send the bitrate they want.

I was trying to match the cameras to the SD option in the app which the Wiki says is HD60. However setting the cameras to anything other than 200 or 180 for bitrate respectively always throws the following errors. They even occur when the app is closed so it isn't like the app is requesting a different bitrate that is somehow overriding it.

[backyard-bedroom-view] bitrate=200 does not match 60
Requesting frame_size=0, bitrate=60, fps=0
[backyard-kitchen-view] bitrate=200 does not match 60
Requesting frame_size=0, bitrate=60, fps=0
[driveway-cam] bitrate=180 does not match 60
Requesting frame_size=0, bitrate=60, fps=0

Edit: All 3 are v3 Pan Camd

@jdeath
Copy link

jdeath commented Dec 29, 2023

I found the v3 Pan will complain if not set to HD120. Manually set its quality to that. Not sure why it does not like the default HD180

@mrlt8
Copy link
Owner

mrlt8 commented Dec 30, 2023

Can you post the firmware version? There seems to be a bug in newer versions of the firmware where the camera isn't reporting the correct bitrate.

@jdeath
Copy link

jdeath commented Dec 30, 2023

Firmware and other details below. Thanks for checking. Also posted logs #1037 as been much less stable since adding this camera.
[WyzeBridge] [+] Adding Basement Hall [HL_PAN3]
[basement-hall] 📡 Getting 120kb/s HD stream (H264/20fps) via LAN mode (WiFi: 68%) FW: 4.50.4.7252 🔒 (DTLS) (2/3)
[basement-hall] WARNING: Skipping smaller frame at start of stream (frame_size=1)

@fjrichman
Copy link
Author

fjrichman commented Dec 30, 2023

Mine are all on 4.50.4.7252 as well.

Also uncertain why the one requires a different bitrate than the other two since the only difference between the three is the drive cam is further out from wifi.

@mrlt8
Copy link
Owner

mrlt8 commented Jan 1, 2024

Thanks for the feedback. can someone try the dev branch to see if the bitrate is updating?

@jdeath
Copy link

jdeath commented Jan 1, 2024

Forced homeassistant addon to use dev image:
DOCKER-WYZE-BRIDGE v2.6.0 [x86_64] DEV BUILD [2024-01-01t13:39:55.260z] ec0a46a
[WyzeBridge] [+] Adding Basement Hall [HL_PAN3]
[basement-hall] 📡 Getting 180kb/s HD stream (H264/15fps) via LAN mode (WiFi: 50%) FW: 4.50.4.7252 🔒
[basement-hall] WARNING: Skipping wrong frame_size at start of stream [frame_size=1]

I forced bitrate to 180 and removed bitrate override and no bitrate errors either way! Thanks.

A few of my cameras are taking their time coming up and saw some new error messages, but the bitrate on the v3Cam seems fixed. I did see one bitrate error on another camera, but it fixed itself. Not sure why my cameras are not stable. I'll let it sit for a few hours.

[video] super slow
[garage] WARNING: clear buffer
[side-door] [Exception] Did not receive a frame for 20s
[garage] [Exception] Did not receive a frame for 20s
but then it does try to restart the connection and they eventually came up.

[WyzeBridge] ❌ '/side-door' stream is down
Connection closed by remote. Closing connection.
[side-door] [-20015] AV_ER_SESSION_CLOSE_BY_REMOTE
[side-door] 📡 Getting 180kb/s HD stream (H264/20fps) via LAN mode (WiFi: 74%) FW: 4.25.1.316 🔒
[side-door] Re-encoding using libx264 [transpose='clock']
[side-door] WARNING: Skipping wrong frame_size at start of stream [frame_size=4]

[garage] [CONTROL] ERROR - error=AssertionError('Please call _connect() first!'), cmd='_bitrate'
[garage] [Exception] Did not receive a frame for 20s

@mrlt8
Copy link
Owner

mrlt8 commented Jan 1, 2024

Thanks! Some of those errors are related to the sync changes in the dev branch.

mrlt8 added a commit that referenced this issue Jan 11, 2024
* Drop late audio frames to keep sync #388

* show running architecture

* Don't log failed tutk if stream is down #990

* Use valid FPS for sleep #388

* Refactor

* Adjust sleep_interval #388

* Increase sleep time between frames #388

* Set larger buf size #388

* add SLEEP_INTERVAL_FPS #388

* Adjust sleep interval #388

* use genpts #388

* avoid conflicting names with errno module

* refactor _audio_frame_slow

* LOW_LATENCY mode

* show github SHA on dev build

* substream support and more refactoring #388

* div tag for jittery video in Firefox #1025

* Re-encoding audio for WebRTC/MTX

* reduce sleep time for audio thread #388

* Target firefox for jittery video fix in css #1025

* Use K10050GetVideoParam for FW 4.50.4.x #1070

* Use K10006 for newer doorbell #742 and refactor

* Reduce audio pipe flushing #388

* show gap when audio out of sync #388

* don't include ARCH in version

* Update iotc.py

* reset frame_ts on clock sync

* update auth api

* Restructure and cleanup

* remove unneeded files

* update path

* Forget alarm/siren state #953 #1051

* use addon_config for Home Assistant

* Additional refactoring to auth api

* don't skip keyframes #388

* Update ffmpeg.py

* delay audio when ahead #388

* format iotc logging so we know what cam is late

* drop late video frame and speed up audio #388

* Add Floodlight V2

* Set default sample rate for all cams

* Delay audio by 1 second if ahead of video #388

* tweak ffmpeg buffer #388

* Retain MQTT Discovery Message #920

* Update change log

Special thanks to @carlosnasillo!
@drone540
Copy link

drone540 commented Feb 8, 2024

@mrlt8
Don't know if this is related to the reported issue, but I have noticed a bit rate issue when trying to use SD30. It will always use the last set HD bitrate.

For example if i run with no bitrate set at all then set SD30. it will request 180 bitrate (the default I guess) and give this error:

wyze-bridge  | [cam] bitrate='180' does not match 30
wyze-bridge  | [cam] Requesting frame_size=1, bitrate=30, fps=0

If I run HD60 then SD30:

wyze-bridge  | [cam] bitrate='60' does not match 30
wyze-bridge  | [cam] Requesting frame_size=1, bitrate=30, fps=0

If i run HD120 then SD30:

wyze-bridge  | [cam] bitrate='120' does not match 30
wyze-bridge  | [cam] Requesting frame_size=1, bitrate=30, fps=0

Actually hmm some further testing shows that even HD60 to SD30 can result in 120 so I guess it's not even consistent.

wyze-bridge  | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam on 192.168.1.28
wyze-bridge  | [WyzeBridge] 192.168.1.101 - - [08/Feb/2024 04:57:41] "GET /api/sse_status HTTP/1.1" 200 -
wyze-bridge  | [cam] 📡 Getting 30kb/s SD stream (H264/20fps) via LAN mode (WiFi: 73%) FW: 4.36.9.139 🔒
wyze-bridge  | [WyzeBridge] ✅ '/front-window-cam stream is UP! (3/3)
wyze-bridge  | [WyzeBridge] 📖 New client reading from cam
wyze-bridge  | [cam] bitrate='120' does not match 30

Seems like SD30 is broken?

This is on a WyzeCam V3 running firmware: 4.36.9.139

Also can SD also use higher bitrates then 30? Such as SD40? for possibly higher quality 360p?

@fjrichman
Copy link
Author

Apparently I forgot to comment on this again. The update did fix the issues I was having originally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants