various fixes and improvements to use wyzecam in other projects

[koush]

these are various fixes I needed for the wyze plugin in scrypted.
https://github.com/koush/scrypted

[mrlt8]

Thanks @koush, I'm a huge fan of scrypted! Is there a link for the plugin?

[koush]

Right here:
https://github.com/koush/scrypted/tree/main/plugins/wyze

Happy to let you take over if you're interested. I don't have many Wyze cams or your depth of knowledge on this hardware.

There is/was still quite a bit of instability, and here are my findings so far:

• tutk library gets into a bad state if used for multiple streams (fixed by using multiprocessing in scrypted)
• camera can randomly stop sending video and permanently hang tutk (fixed by observing steady stream of video packets)
  *stream quaility seems to lag behind the native app and docker wyze bridge. if I set the bitrate too high, there seems to be quite a bit of instability. I think this was due to expected fps? does querying for a frame too often crash the cam?

Also, where is this tutk library from? Seems to be a leak from many years ago.

[mrlt8]

Yeah, the multiple stream issue seems to be a bug in the version of the library that we're using. It used to be fine with the older version of the SDK that's floating around, but that version doesn't support the newer authentication and AV methods.

The tutk library we're currently using is slightly newer than the one floating around and was downloaded from http://srvm.tutk.com/srw/. If someone can provide access to a newer version of the SDK, we might be able to get around that multi-stream bug.

The official app seems to constantly query for frames until avRecvFrameData2 returns an error and will do a Thread.sleep(50L);. While this works, it often caused the CPU to spike, so I've been adding a sleep between requests. I'll have a look at the plugin to see if there's anything we can do to get it to at least match what we're getting in the bridge.

[koush]

I see. I took a peek at the code and I see that there's two sleeps in there, and assumptions about the sleep time based on frame rate. I think it could be improved by using an exponential moving average to auto calculate the optimal sleep based on data receive rate. I'm not sure how my usage differs from wyze bridge, but I'm guessing something is causing it to not read fast enough and then there might be a buffer overlow in tutk? No idea tbh.

[koush]

Using an extremely short sleep to time the frequency at which video is received, the interval is quite irregular:

data 0.0437319278717041
data 0.03609728813171387
data 0.07113933563232422
data 0.051522016525268555
data 0.0422368049621582
data 0.05867743492126465
data 0.057097673416137695
data 0.04649662971496582
data 0.03806781768798828
data 0.04826188087463379
data 0.04770827293395996
data 0.057645320892333984
data 0.04692673683166504
data 0.06259512901306152
data 0.051737070083618164
data 0.04256296157836914
data 0.03540396690368652
data 0.04108238220214844
data 0.06243085861206055
data 0.06062436103820801
data 0.04956221580505371
data 0.040741682052612305
data 0.04000544548034668
data 0.050453901290893555
data 0.11232495307922363
data 0.05274009704589844
data 0.0013821125030517578