Réponse directe
Si l'audio est lu, la session RTSP et au moins une piste multimédia fonctionnent. Inspectez la sortie SDP ou la sonde pour le codec vidéo, le profil, la résolution et le format de pixel, puis testez un sous-flux H.264 inférieur avant de modifier le réseau.
Pourquoi cela arrive
La caméra peut annoncer H.265 à un client qui décode uniquement H.264, utiliser un profil H.264 non pris en charge, omettre la piste vidéo sur le chemin sélectionné ou envoyer des paquets endommagés pendant que l'audio continue.
Séparez la disponibilité du flux, la description du média, le transport, le décodage et la synchronisation avant de modifier les paramètres de la caméra.
Un test contrôlé
Sondez le même URL et comparez les flux audio et vidéo annoncés. Changez ensuite uniquement le profil de la caméra, en gardant les informations d'identification et le transport fixes.
Modifiez une variable à la fois. Conservez le modèle de caméra, le micrologiciel, le point final et le compte enregistrés ; testez ensuite l'accessibilité du réseau, la réponse du protocole, le transport multimédia et le décodage en tant que couches distinctes.
Utilisez un compte dédié en lecture seule et un outil de diagnostic local fiable. Rédigez les informations d’identification, les adresses privées et les données d’identification avant de partager la sortie.
Séquence diagnostique
| Vérifier | Action | Preuve de progrès |
|---|---|---|
| Pistes | Confirmez qu'une section multimédia vidéo existe dans SDP. | Un codec vidéo et une charge utile sont annoncés. |
| Codec | Testez un sous-flux H.264 lorsque le flux principal est H.265. | La vidéo apparaît sans changer le point de terminaison. |
| Profil | Réduisez temporairement le profil, le niveau ou la résolution. | Le client décode le flux le plus simple. |
| Paquets | Comparez TCP et UDP tout en regardant les erreurs de décodage. | Un transport propre supprime la corruption sans changer de codec. |
Des preuves à conserver
Enregistrez le résultat de la sonde avec les informations d’identification supprimées. Il fournit le codec et les preuves de piste nécessaires pour distinguer « aucune piste vidéo » de « impossible de décoder la vidéo ».
Note de délimitation et de sécurité
Ne présumez pas qu’une connexion RTSP réussie signifie que chaque codec annoncé est pris en charge par chaque appareil.
Pour la visualisation à distance, utilisez un VPN géré au lieu d'exposer RTSP ou les ports d'administration de la caméra directement à l'Internet public.
SmartRTSP
SmartRTSP est une visionneuse RTSP et ONVIF axée sur la caméra pour les appareils Apple, Windows et Android. Il convient aux contrôles de visualisation directe, de découverte et multi-caméras ; conservez un NVR ou VMS dédié lorsqu’un enregistrement continu, une exportation de preuves ou des contrôles d’entreprise centralisés sont requis.
Questions fréquemment posées
Pourquoi l’audio peut-il fonctionner alors que la vidéo ne fonctionne pas ?
RTSP peut décrire des pistes multimédias distinctes, et le client peut décoder une piste mais pas l'autre.
Dois-je essayer H.264 ?
Oui, un sous-flux H.264 documenté constitue le test de compatibilité le plus rapide lorsque le flux principal utilise H.265.
Est-ce toujours un problème de codec ?
Non. La piste vidéo peut être manquante ou endommagée pendant le transport, alors inspectez les pistes annoncées et décodez les erreurs.
Références principales
- IETF RFC 7826 — Protocole de diffusion en temps réel 2.0
- FFmpeg — RTSP options et exemples de protocole
- MDN — Formats de conteneurs multimédia et de codecs sur le Web
Guide SmartRTSP associé
Ouvrir le guide associéDiagnostiquez un flux RTSP qui transporte de l'audio tandis que l'image reste noire en inspectant les pistes annoncées et la prise en charge du décodeur.