The short answer
Native RTSP is served by the camera; Docker Wyze Bridge receives a supported Wyze stream and publishes a new endpoint on another host. Choose by exact model and firmware. A bridge’s compatibility table is not a promise that every newer firmware or every Wyze camera will work.
Work through the checks
First check whether the camera’s installed firmware exposes an official RTSP setup. A direct connection avoids adding a separate restreaming host to the path.
If considering a bridge, compare the exact model and firmware with its project documentation. Read account, API-key and authentication requirements for the release you will run.
Draw the route: camera to bridge, then bridge to viewer. Use the bridge machine’s LAN address when the viewer is on another computer; localhost refers to the viewer itself.
Start one camera and one viewer. Separate failures in account login, camera acquisition and bridge output; a healthy container does not prove it has received video.
Test restart behavior and retain only the access permissions the workflow needs. Do not publish the bridge’s administration interface as a public camera viewer.
What to verify
Compare a decoded live scene, restart recovery and host resource use. Keep the third-party dependency visible in your inventory and do not describe it as native Wyze or AeoCam functionality.
Sources and scope
AeoCam is available for Windows. Camera settings below describe protocol preparation, not a certification of a particular camera or a promise of every feature in every app version. Check the installed build and the Microsoft Store listing for current availability.
Vendor documents describe the camera or protocol. No physical-camera compatibility test is claimed here. Menus and capabilities can change with model and firmware.