The short answer
Check the exact Xiongmai / XMEye / iCSee model and installed firmware before choosing a connection method. The information below separates vendor-documented preparation from actual playback verification with your camera and client.
What to know for this brand
Read the installed hardware and firmware identifiers and obtain the matching camera or recorder vendor's instructions before enabling local services.
Xiongmai's 5013D_D download explicitly identifies an ONVIF firmware branch, which is not evidence that every XMEye or iCSee product exposes the same capabilities.
An app's cloud identifier or successful proprietary playback does not establish an RTSP URI, ONVIF credentials, or PTZ operation for a rebranded OEM device.
Product families to identify
XMEye recorder ecosystem · iCSee camera ecosystem · 5013D_D IPC module
These names help identify the relevant documentation; they are not an exhaustive list or a hardware certification.
Connection route
This brand includes different product families and connection methods. Identify the exact line before choosing RTSP, ONVIF, a controller export or the vendor app. Do not transfer a URL pattern, account rule or cloud limitation from one family to every product sold under the same name.
ONVIF check
Support depends on the model, firmware and enabled service; video access alone does not prove discovery or controls.
Model-scoped stream examples
No universal direct RTSP template is provided. Obtain a supported endpoint from the exact device, controller or documented API instead of guessing an address.
Use a private, reachable network for the first test. A working vendor cloud view does not prove that a separate computer can reach a local camera service.
Source titles retain the original document language. Check the current manual for your product; firmware, accounts and service availability can change.
Work through the checks
Identify the exact Xiongmai / XMEye / iCSee model, firmware and whether the source is a camera, recorder, hub or API. Match the documentation to that source rather than another device with a similar name.
Confirm the documented local service or export route. Create the required local account where supported; a cloud-account login is not automatically a camera-stream credential.
Check the reachable private address, scheme, configured port and stream selection. A controller token or temporary API session may have different lifetime and access requirements from a camera account.
Test one authorized source and one client. Preserve the error stage: address timeout, authentication failure, unsupported secure mode and decoding errors require different corrections.
Verify a changing live scene, the intended lens or channel and a reconnect. Test audio, PTZ, events and offline restart separately instead of inferring them from video playback.
What to verify
Record model, firmware, source, account type and the actual decoded-video result. This guide does not assert physical-device testing, certification or every optional capability in AeoCam.
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.