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.64k stars 166 forks source link

Bitrate mismatch with firmware 4.36.11.4679 #975

Open agrieco opened 1 year ago

agrieco commented 1 year ago

I have a handful of Wyzecams hooked up to wyze-bridge. I mostly have v3 cameras.

One of my v3 cameras is misbehaving. The error message is: [lake-basement] Wrong bitrate=120 does not match 180 [lake-basement] Setting bitrate=180

I noticed this was the only camera I had that was on firmware: 4.36.11.4679 which is odd. I tried to check the app for firmware upgrades and I don't see any for the other v3 cameras. Not sure what is going on.

Any ideas? This doesn't appear to be a benign messge- streaming from this cam is spotty at best.

[WyzeBridge] šŸ  Home Assistant Mode šŸš€ DOCKER-WYZE-BRIDGE v2.3.16 [WyzeBridge] šŸ“š Using 'auth' from local cache...

mrlt8 commented 1 year ago

You'll see this if you open the camera stream in the wyze app because the app will request a lower bitrate 120 for HD and 60 for SD. The bridge defaults to using a bitrate of 180 and, since we're pulling the same stream as the app, it will try to maintain the desired bitrate and you'll see that message if the camera switches to a different bitrate.

You can adjust the desired bitrate that the bridge uses in the config or by sending a command over the REST API/MQTT.

agrieco commented 1 year ago

Thanks for the prompt response. I opened the app for sure, but the other cameras aren't popping this error (the ones on the older release). Is there a way to force the camera back to 180 instead of changing the bridge config?

Anc0dia commented 1 year ago

I have the same error with my v3 using the same firmware version. Changing the bitrate in the config doesn't work as it just keeps reporting the bitrate is 120 and is wrong as it doesn't match the config value.

I also can't change the bitrate using API commands, it says successful but nothing changes.

If I roll back to firmware 4.36.10.4054 I can change the bitrate again. The issue also exists in the beta firmware 4.36.11.5859.

edit: it also does this with my v3 pro fw ver 4.58.11.4847. I haven't rolled the firmware back yet to see when it stopped working

mrlt8 commented 1 year ago

The bridge is attempting to change the bitrate when you see Setting bitrate=180.

You should be able to get the current bitrate value with the API using:

http://<bridge ip>:5000/api/<cam-name>/bitrate

And adjust it using:

http://<bridge ip>:5000/api/<cam-name>/bitrate/180
Anc0dia commented 1 year ago

Yes, but it doesn't work with the newer firmware, The bitrate doesn't actually change so it keeps trying over and over. If you issue the command using API it says successful however it doesn't change the bitrate. If I roll the firmware back to .4054 it all works as expected.

if I put BI250 in my config for side camera and try to adjust to 250 using api:

[side] Wrong bitrate=120 does not match 250 [side] Setting bitrate=250 [front2k] Wrong bitrate=255 does not match 250 [front2k] Setting bitrate=250 [side] [CONTROL] Attempting to GET: bitrate [side] Wrong bitrate=120 does not match 250 [side] Setting bitrate=250 [side] [CONTROL] Response: {'command': 'bitrate', 'payload': '1,2,3,4,5,21,22,27,50', 'value': 120, 'status': 'success', 'response': 120} [WyzeBridge] 192.168.200.215 - - [28/Aug/2023 01:56:37] "GET /api/side/bitrate HTTP/1.1" 200 - [side] Wrong bitrate=120 does not match 250 [side] Setting bitrate=250

[side] [CONTROL] Attempting to SET: bitrate=250 [front2k] Wrong bitrate=255 does not match 250 [front2k] Setting bitrate=250 [side] [CONTROL] Response: {'command': 'bitrate', 'payload': '250', 'value': '250', 'status': 'success', 'response': 2} [WyzeBridge] 192.168.200.215 - - [28/Aug/2023 02:00:04] "GET /api/side/bitrate/250 HTTP/1.1" 200 - [front2k] Wrong bitrate=255 does not match 250 [front2k] Setting bitrate=250 [side] Wrong bitrate=120 does not match 250 [side] Setting bitrate=250

mrlt8 commented 1 year ago

Ok, so after a bunch of debugging I think I finally found the issue with the .11 firmware.

I mistakenly thought the issue was coming from the command to change the bitrate, but it seems to be working as expected and the firmware just isn't sending back the correct bitrate in the K10020 response #825 which is what we were using to update info about the camera including the bitrate. This is why you'll continually get the wrong bitrate message on 4.36.11.x fw.

Not sure if this is a bug in the firmware or an intentional change, but we should be able to use K10050 to lookup the bitrate. One downside is that K10050 will only return the video parameters so we'll still need to make additional requests to update the rest of info.

Anc0dia commented 1 year ago

I don't think it is changing the bitrate - I just rolled back the firmware on one of my v3 and used the same config (BI255) when I check the playback the bandwidth used (displayed in the app) during playback shows around 120-130 KB using the new firmware and around 200-210 using the old firmware. - same config, same scene. Is there another way to verify?

Anc0dia commented 1 year ago

I updated to the latest firmware and the error still persists, (fw 11.5859)

[back] bitrate=120 does not match 255 Requesting frame_size=0, bitrate=255, fps=0 [back] bitrate=120 does not match 255 Requesting frame_size=0, bitrate=255, fps=0

mrlt8 commented 1 year ago

Hmm, I'll have to look into that.

Was it working with 11.4679?

Anc0dia commented 1 year ago

I was on 10.4054 and decided to test 11.5859 since it was just released, but since I had the camera down I just tried 11.4679 and it gives the same error.

It also gives the error on my v3 pro @ 11.4874. I haven't tried older firmware yet.

mrlt8 commented 1 year ago

The v2.3.17 of the bridge fixed the issue for me on 11.5614. Is the bridge able to set the correct bitrate when it connects to the camera or does it error out right away?

Anc0dia commented 1 year ago

I run this in docker on a Debian server so just to eliminate issues there I tried it using the add-on in Home Assistant & it worked. So in order for it to work on my Debian machine I need to add this to my compose file:

        - FFMPEG_FLAGS=-avoid_negative_ts make_zero -fflags nobuffer -flags low_delay -strict experimental -fflags +genpts+discardcorrupt+igndts -rw_timeout 5000000 -use_wallclock_as_timestamps 1

I can then change the bitrate on my v3 camera with the 11.4679 firmware. I still can't change the bitrate on the v3 pro with firmware 4.58.11.4847

mrlt8 commented 1 year ago

hmm, I don't think the ffmpeg commands should affect the bitrate stuff since that is coming from a different tutk command.

We're only checking for the 11.x firmware on the v3 cams, so I'll have to update the script to also use the newer methods for the v3 pro.