The short answer
FFmpeg can help separate endpoint access from actual decoding. Use a short, bounded test with the same RTSP source as your viewer. Stream metadata or a successful DESCRIBE response alone is not proof of a usable live image; inspect decoded frames and the errors that occur during the sample.
Work through the checks
Confirm the installed FFmpeg build and use the exact endpoint from the camera. Replace the example placeholders and supply the stream login only through your private test environment.
Use a ten-second media sample and a ten-second input socket timeout. The sample duration starts when media arrives, not at process launch; the timeout limits a stalled socket read.
Read whether the error occurs before authentication, during transport negotiation or after packets arrive. Preserve the original error rather than immediately changing multiple options.
If the camera supports it, compare a UDP test separately on the same private network. Keep the source, codec and time window consistent for a meaningful comparison.
Open the source in a visual client to confirm the scene and channel. A completed metadata probe or a packet count can still conceal a wrong camera or corrupt image.
ffmpeg -rtsp_transport tcp -timeout 10000000 -i "rtsp://CAMERA_IP:554/STREAM_PATH" -t 10 -f null -What to verify
Record decoded-frame progress and a sanitized log alongside the viewer result. Remove embedded credentials before sharing; diagnose protocol and codec support separately.
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.