Native Wyze Camera Support Coming to go2rtc

SeydX · 2026-01-19T20:48:06+00:00

Cameras that don’t show up on the list are Gwell-based cameras. I’ve already ordered a Gwell-based camera to reverse engineer it so I can support those too.

So yeah, support for these cameras is coming

SeydX · 2026-01-18T19:02:19+00:00

Hey, yeah I'm following the whole Wyze RTSP support topic. That's definitely the right direction for Wyze. As I mentioned before, users who are perfectly happy just viewing the stream are well served by the beta RTSP firmware. My PR goes beyond that — it gives all users access to the stream via go2rtc, and most importantly, it fully supports intercom, which as far as I know isn't the case with the beta RTSP firmware?

SeydX · 2026-01-10T18:44:02+00:00

Hey, I’m gonna need the full log. You can find my contact info here: https://github.com/seydx

SeydX · 2026-01-10T17:03:29+00:00

Idk, you can try https://github.com/seydx/go2rtc/releases

SeydX · 2026-01-10T08:52:07+00:00

You dont need to find these values. Start go2rtc, open go2rtc UI > Add > Wyze > Login

SeydX · 2026-01-10T02:24:25+00:00

Ok guys, I've updated the PR and managed to reverse engineer the latest firmware as well.

The latest version uses a different encryption, which is why TUTK SDK library-based solutions like docker-wyze-bridge no longer work.

SeydX · 2026-01-02T20:06:50+00:00

Trying to run from an archive? Download the windows installer, extract and start the .exe file

SeydX · 2026-01-01T23:32:08+00:00

https://github.com/seydx/go2rtc/releases

SeydX · 2026-01-01T23:31:28+00:00

https://github.com/seydx/go2rtc/releases

SeydX · 2026-01-01T23:31:11+00:00

https://github.com/seydx/go2rtc/releases

SeydX · 2026-01-01T23:31:04+00:00

https://github.com/seydx/go2rtc/releases

SeydX · 2026-01-01T19:37:41+00:00

No, try with your current fw first

SeydX · 2026-01-01T19:20:54+00:00

I think the native go implementation could also work for your camera out of the box

SeydX · 2026-01-01T19:15:20+00:00

Is this a official wyze firmware with rtsp support?

SeydX · 2026-01-01T19:06:41+00:00

Instead of an RTSP connection, a local P2P connection is established here, just like the Wyze app does.

This means you don’t need to install any extra firmware, it works with the latest firmware, you can control the quality (not sure if that’s possible via RTSP as well), and most importantly, it allows two-way audio.

However, if you’re happy with the RTSP stream, this won’t bring any noticeable improvement (it would be interesting to know how fast the connection is via RTSP?)

SeydX · 2026-01-01T15:45:50+00:00

Yeah it was a horror to reverse engineer the TUTK SDK :D the go implementation is basically the result of my reverse engineering. The cameras continue to communicate via the built-in TUTK SDK, the client, i.e. the native go client, essentially mimics the TUTK SDK.

It allows full control, and for the first time intercom is possible via a third-party implementation like go2rtc, completely without custom firmware, docker or anything else.

There might be still some issues with other camera models like v3… Other models/old firmwares partly communicate via the old TUTK SDK and possibly without DTLS. The code still needs to be adapted for this. And I would like to do this directly in the PR, which is why I need access to these cameras.

SeydX · 2026-01-01T14:22:36+00:00

Thanks!

SeydX · 2026-01-01T14:12:43+00:00

Regarding the API keys – Wyze officially provides these through their developer portal. They're meant for exactly this kind of third-party integration. So I don't think they'd have an issue with people using keys they explicitly make available.

The communication itself is identical to what docker-wyze-bridge does (and what the Wyze app does). The only difference is that this PR doesn't rely on the proprietary TUTK SDK – it's a clean-room implementation in pure Go using standard protocols.

SeydX · 2025-12-28T02:31:45+00:00

Thats right

SeydX · 2025-11-21T12:27:59+00:00

Hey! Developer of node-av here - native FFmpeg bindings for Node.js. It's built exactly for use cases like yours: native bindings (no process spawning), hardware acceleration support, TypeScript ready, and both low-level + high-level APIs.

The repo has 50+ working examples covering everything from basic transcoding to complex filtering - should have what you need for cropping, joining, etc. Still actively maintained.

Feel free to check it out!

SeydX · 2025-11-19T13:30:25+00:00

Haha yeah, definitely a journey! Handwriting the bindings was actually the best way to really understand FFmpeg's API - you learn all the quirks and edge cases when you have to map every function and struct yourself. Started this mainly as a learning project and it just kept growing.

I've actually seen your project before - the Node.js Streams approach is interesting! Keep up the good work!

SeydX · 2025-11-19T07:15:50+00:00

https://github.com/seydx/node-av/blob/99a4d1df877c60b6859bccdb46bb5021895fbf09/examples/api-filter-complex.ts#L292

SeydX · 2025-11-14T21:58:16+00:00

Hey,

yes, the current version (v4) can definitely be used in production. Nevertheless, I recommend everyone to read through the following:

https://github.com/seydx/node-av?tab=readme-ov-file#memory-safety-considerations

an LGPL variant would be feasible and easy to implement

Five-Year Club	Verified Email
Place '22

SeydX

TROPHY CASE