Mis à jour

Ma caméra est-elle compatible ?

SecureEyes lit la vidéo RTSP locale en H.264 ou H.265 et utilise ONVIF (Profile S ou T) pour la trouver. Ce n'est pas une liste de marques.

La réponse courte

Une caméra qui fournit un flux H.264 ou H.265 en RTSP sur votre réseau, et qui répond en ONVIF, est une bonne candidate. SecureEyes demande ses flux à la caméra via ONVIF, et fonctionne avec l'ancien service média ONVIF (Profile S) comme avec le plus récent (Profile T).

ONVIF est la voie facile, pas la seule. Une caméra avec RTSP mais sans ONVIF peut quand même être ajoutée : SecureEyes essaie les chemins de flux qu'il connaît et ne garde que ceux que la caméra fournit réellement.

Comment SecureEyes trouve la vidéo d'une caméra

Seules les adresses de flux rtsp et rtsps sont utilisées. Chaque guide de marque liste ses chemins : Caméras Hikvision et HiWatch, Caméras Reolink, Caméras Dahua, Amcrest et Lorex, Caméras TP-Link Tapo et VIGI, et Generic and white-label cameras Anglais.

  • Une caméra qui déclare plus d'un objectif : SecureEyes utilise les flux que la caméra déclare.
  • Une marque que SecureEyes connaît (Reolink, Hikvision et HiWatch, Dahua, Amcrest et Lorex, TP-Link Tapo et VIGI, cartes de type XiongMai, Axis, Uniview) : SecureEyes utilise ses propres chemins de flux pour cette marque, et cherche un second objectif caché.
  • Toute autre marque qui répond en ONVIF : SecureEyes utilise les flux que la caméra déclare.
  • Pas de réponse ONVIF : SecureEyes essaie tous les chemins qu'il connaît et ne garde que ceux que la caméra a fournis.
  • Rien de trouvé : la caméra est enregistrée sans image, et vous pouvez définir ses chemins vous-même.

Caméras testées sur du vrai matériel

Voici les résultats relevés sur nos propres caméras de test. Chacun ne vaut que pour ce modèle et ce firmware. Les résultats varient selon le modèle et le firmware.

  • Hikvision DS-2DE2C400IWG/W, firmware V5.3.8 build 260123, relevé par un SecureEyes Hub sur notre banc d'essai : trouvée par WS-Discovery ; la vidéo en direct et le flux secondaire fonctionnent ; le Hub l'enregistre en continu depuis le 11 septembre 2026 ; les événements de mouvement ONVIF arrivent. Le firmware ne propose pas le panoramique et l'inclinaison via ONVIF, bien que la caméra pivote et s'incline ; on ne sait pas si un réglage de la caméra les masque. H.265, le projecteur via l'API propre à Hikvision et le texte incrusté ne sont pas encore testés.
  • Dahua DH-IPC-PTS1439B-E2-S-PV (deux objectifs), firmware 3.120.0000000.26.R : la détection, les deux objectifs et les quatre flux ont fonctionné du premier coup (20 août 2026). L'état du projecteur et du microphone se lit correctement via l'API propre à Dahua ; les modifier depuis l'app n'est pas encore testé. La caméra est livrée avec le son désactivé dans ses propres réglages d'encodage.
  • Reolink TrackMix PoE (deux objectifs), firmware v3.2.0.5931 tel que la caméra le déclare : RTSP répond sur le port 554, ONVIF répond sur les ports 8000 et 80, et les événements de mouvement ONVIF fonctionnent (22 août 2026). ONVIF ne déclare qu'un seul objectif ; SecureEyes demande le second via RTSP, et une vérification du 19 août 2026 a constaté qu'il fournissait de la vidéo. Le projecteur s'allume et s'éteint via l'API propre à Reolink (15 août 2026).
  • TP-Link Tapo C500 (firmware non relevé) : RTSP sur le port 554 fonctionne une fois que vous avez créé un compte caméra dans l'app Tapo ; l'identifiant cloud TP-Link est refusé. Son service ONVIF est sur le port 2020. Nos relevés donnent Décodage matériel réglé sur Désactivé comme correctif des éclairs verts sur cette caméra. L'isolation AP du routeur l'a bloquée jusqu'à sa désactivation.
  • Amcrest (modèle et firmware pas encore relevés) : la vidéo en direct fonctionne (26 septembre 2026).
  • Caméras en marque blanche de type XiongMai sur notre banc d'essai : ONVIF sur le port 8899 répond pour les infos de l'appareil et le redémarrage, mais les caméras refusent la commande de vision nocturne (filtre IR). Elles acceptent les changements d'encodage, puis les ignorent. Leur flux RTSP se lisait avec n'importe quel mot de passe.

Résultats d'encodage et de panoramique/inclinaison par marque (test en laboratoire, 12 août 2026)

  • Tapo : les changements d'encodage sont acceptés et appliqués. Il n'y a pas de zoom. Un panoramique peut continuer jusqu'en bout de course au lieu de s'arrêter quand vous relâchez (problème ouvert).
  • Reolink : la caméra refuse les changements d'encodage, ses réglages d'encodage sont donc en lecture seule. Le panoramique et l'inclinaison fonctionnent. Il n'y a pas de zoom.

Pas encore testé

  • Axis et Hanwha Vision n'ont pas encore été testées sur du vrai matériel. Tant que ce n'est pas fait, elles ne figurent pas dans la liste ci-dessus.
  • Le contrôle via l'API propre à la marque (projecteur, microphone) est développé pour Hikvision, Axis et Foscam, mais pas encore testé sur une vraie caméra. Hanwha Vision n'a pas encore de contrôle direct.
  • L'API propre à Tapo n'est pas encore prise en charge. Les caméras Tapo utilisent uniquement ONVIF et RTSP.

Non pris en charge

  • Les caméras uniquement cloud, sans ONVIF ni RTSP local, comme Ring, Nest et Blink d'origine, et Wyze avec son firmware d'origine.
  • Les caméras qui ne proposent que WebRTC, ou qui ont besoin d'une app ou d'un SDK du fabricant pour afficher la vidéo.
Cette page vous a-t-elle été utile ?

Articles liés