Le flux RTSP H.265 ne fonctionne pas : quand remettre la caméra en H.264

"Le flux RTSP H.265 ne fonctionne pas" est l'une des recherches de dépannage de caméra les plus intentionnelles, car le flux fonctionne souvent à un endroit et échoue à un autre. VLC peut le lire. Une application mobile peut l'afficher. Un navigateur, un NVR, un pipeline d'analyse, une intégration de Home Assistant, un pont WebRTC ou un restreamer peuvent échouer avec un « type de flux non pris en charge », « le codec ne correspond pas », « impossible d'écrire l'en-tête », « aucune vidéo » ou un compteur de chargement permanent.

L'échec n'est pas toujours la session RTSP. H.265, également appelé HEVC, est une limite de prise en charge des codecs. RTSP peut le transmettre correctement alors que le système de réception ne peut toujours pas le décoder, le conditionner, l'afficher ou le retransmettre.

Le succès du RTSP ne signifie pas la prise en charge des codecs

Un client RTSP peut effectuer avec succès :

• 'OPTIONS'
• DÉCRIRE
• CONFIGURATION
• 'JOUER'
• Livraison RTP

et je ne parviens toujours pas à afficher la vidéo. Si SDP annonce l'arrivée des paquets H.265 et RTP, le transport peut se dérouler correctement. Le produit en aval peut tout simplement ne pas prendre en charge H.265 sur ce chemin.

Cela est important car les utilisateurs décrivent souvent le problème comme « RTSP ne fonctionne pas ». Le meilleur diagnostic est "Le transport RTSP fonctionne, mais le codec annoncé n'est pas pris en charge ou n'est pas prêt à être décodé pour ce consommateur".

Pourquoi H.265 échoue plus souvent que H.264

Le H.265 est efficace, notamment pour les caméras haute résolution, mais la prise en charge est inégale. De nombreux chemins de navigateur ne gèrent pas correctement le H.265 brut. Certains NVR peuvent enregistrer du H.265 mais ne peuvent pas le prévisualiser de manière cohérente. Certains pipelines d'analyse nécessitent H.264 car l'accélération matérielle, l'extraction de trames ou la sortie de conteneur l'attendent. Certains restreamers ont besoin d'un transcodage ou d'une configuration spéciale.

Modes de défaillance courants :

• l'aperçu du navigateur ne se charge pas
• le sous-flux basse résolution fonctionne mais le flux principal échoue
• le flux principal est H.265 tandis que le flux secondaire est H.264
• NVR enregistre mais la vue en direct échoue
• La sortie RTMP/FLV rejette HEVC
• Le pont WebRTC ne peut pas correspondre aux codecs
• le service d'analyse accepte uniquement H.264

Il s'agit de limites de compatibilité des produits et non d'une preuve que la caméra est hors ligne.

Inspecter SDP avant de modifier les paramètres

Avant de modifier les paramètres de la caméra, inspectez le SDP :

• est-ce que a=rtpmap annonce H265, H264 ou un autre codec ?
• le flux principal diffère-t-il du flux secondaire ?
• les paramètres H.265 VPS/SPS/PPS sont-ils visibles ?
• le type de charge utile reste-t-il cohérent dans RTP ?
• est-ce que RTP arrive après « PLAY » ?
• L'échec est-il avant ou après la livraison des médias ?

Si SDP indique H.265 et que la plate-forme cible attend H.264, l'action suivante n'est pas le débogage du pare-feu. Il s'agit d'une sélection de profil de flux, d'un changement de codec ou d'un transcodage.

Le flux principal par rapport au sous-flux est souvent l'indice

De nombreuses caméras exposent :

• flux principal : haute résolution, H.265
• sous-flux : basse résolution, H.264

Cela explique pourquoi le sous-flux fonctionne alors que le flux principal échoue. Le sous-flux prouve l’accessibilité et les informations d’identification RTSP. Cela ne prouve pas que le consommateur prend en charge le codec principal.

Un bon rapport compare :

• flux principal SDP
• sous-flux SDP
• noms de codecs
• resolution
• bitrate
• Continuité RTP
• état de préparation du décodeur

Si seul H.265 échoue, les preuves indiquent la prise en charge du codec ou la mise en paquets H.265 plutôt que la syntaxe URL RTSP.

Quand le repli H.264 est la solution pratique

Passer le profil de la caméra à H.264 est souvent la solution la plus rapide lorsque :

• le produit cible ne prend pas en charge H.265
• l'aperçu en direct est basé sur un navigateur
• la retransmission vers RTMP/FLV est requise
• le pipeline d'analyse nécessite des trames H.264
• le chemin de décodage matériel est inconnu
• le cas de support nécessite une large compatibilité

Le H.265 peut toujours être utile pour l’efficacité de l’enregistrement ou du stockage. L'architecture pratique peut utiliser H.264 pour l'acquisition/détection en direct et H.265 pour l'enregistrement de caméra locale, lorsque cela est pris en charge.

Où s’adapte l’inspecteur RTSP

RTSP Inspector n'essaie pas de transcoder ou de lire chaque flux. Son travail consiste à prouver le contrat de flux :

• Le contrôle RTSP a réussi
• SDP annoncé H.265 ou H.264
• RTP est arrivé ou n'est pas arrivé
• la preuve des paramètres du codec était présente ou manquante
• l'échec en aval est probablement dû à la prise en charge du codec, à la perte de paquets ou à une inadéquation des métadonnées

Pour les recherches telles que « Le flux RTSP H.265 ne fonctionne pas », « Caméra de type flux non prise en charge » ou « H.265 fonctionne dans VLC mais pas dans NVR », cette preuve évite un débogage inutile. Le correctif peut être une solution de secours H.264, pas un autre lecteur.