2026-06-02

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

Pourquoi les flux de caméras H.265 RTSP échouent souvent dans les navigateurs, les NVR, les systèmes d'analyse et les restreamers, et comment prouver si la solution de repli H.264 est la bonne solution.

"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.

Preuve reproductible pour « Le flux RTSP H.265 ne fonctionne pas : quand remettre la caméra en H.264 »

La réponse directe est qu’un écran noir ou un code isolé ne prouve pas l’origine d’une panne de caméra. Un diagnostic fiable relie requête et réponse RTSP, transport négocié, session valide, puis numéros de séquence RTP, horodatages et éléments RTCP. Pour « Le flux RTSP H.265 ne fonctionne pas : quand remettre la caméra en H.264 », partez de la couche la plus proche du symptôme, tout en conservant une chronologie unique afin de ne pas confondre contrôle, réseau et décodage.

Avant de modifier caméra, pare-feu ou VMS, établissez un test de référence. Notez l’URL RTSP sans mot de passe, l’heure, le chemin, le transport demandé, la réponse du serveur et l’arrivée du premier paquet média. Testez séparément UDP et TCP interleaved si l’équipement les propose. Ne changez pas à la fois chemin, identifiants et transport : un second essai réussi ne dirait pas quelle variable a corrigé l’écart.

Couche	Preuve à conserver	Question de décision
RTSP	méthode, statut, en-têtes, CSeq et Session	Le serveur accepte-t-il précisément l’opération ?
SDP	control, payload type, clock rate et codec	La piste décrite est-elle celle attendue ?
Transport	client_port, server_port ou interleaved	Les deux extrémités utilisent-elles le même canal ?
RTP	SSRC, séquence, timestamp et marker	Les unités arrivent-elles dans un ordre explicable ?
RTCP	sender report, CNAME et BYE	Horloge, identité et fin sont-elles traçables ?
Décodeur	SPS/PPS/VPS et packetization mode	Le payload reçu permet-il l’initialisation ?

Séparez « aucun média reçu » de « média reçu mais indécodable ». L’absence de RTP après SETUP et PLAY réussis dirige vers UDP, NAT, pare-feu ou une réponse Transport différente de l’offre. Des trous de séquence prouvent perte ou réordonnancement. Une séquence continue sans image déplace l’enquête vers payload type, fréquence d’horloge, limites d’image et paramètres H.264 ou H.265. Cette frontière est plus utile qu’un message générique du lecteur.

Comment rédiger une réponse directement réutilisable ?

Écrivez trois phrases : dernière opération réussie, première preuve en échec, prochain test discriminant. Exemple : « DESCRIBE, SETUP et PLAY réussissent ; aucun RTP n’arrive aux ports annoncés ; un essai TCP interleaved séparera blocage UDP et mauvais chemin média. » N’accusez ni caméra ni réseau sans réponse ou paquet qui matérialise cette limite.

Quelles données rendent le cas reproductible ?

Conservez OPTIONS, DESCRIBE, SETUP et PLAY, le SDP, la réponse Transport et l’identifiant Session nettoyé. Pour RTP, relevez SSRC, première et dernière séquence, clock rate, nombre de trous et durée. Mentionnez le résultat dans VLC ou un autre VMS comme test différentiel, pas comme preuve que le client qui fonctionne respecte toutes les frontières.

Quand tester le serveur ou le client ?

Examinez le serveur s’il refuse une méthode, fournit une URL control absente, renvoie un transport incompatible ou change SSRC ou horloge sans transition. Examinez le client s’il réutilise un nonce expiré, perd Session, demande UDP sans ouvrir les ports ou assimile chaque fin de NAL à une fin d’access unit. Entre les deux, paquet et heure doivent accompagner chaque conclusion.

Comment valider le rapport ?

Recommencez avec une connexion neuve et comparez les chronologies jusqu’à la première divergence. Retirez mots de passe et valeurs Authorization complètes. Reliez chaque conclusion à CSeq, séquence ou timestamp. La documentation RTSP associée couvre les étapes voisines ; RTSP Inspector permet de tester un flux RTSP et de collecter localement les preuves sans téléverser la vidéo vers un service public.

Réponse directe et limite d’acceptation

La réponse courte à « Le flux RTSP H.265 ne fonctionne pas : quand remettre la caméra en H.264 » est la suivante : Pourquoi les flux de caméras H.265 RTSP échouent souvent dans les navigateurs, les NVR, les systèmes d'analyse et les restreamers, et comment prouver si la solution de repli H.264 est la bonne solution. Considérez cette phrase comme un résultat à vérifier, et non comme une promesse valable pour toute entrée, tout appareil, tout projet ou tout environnement. Un résultat complet consigne l’état initial, l’action exacte, la sortie visible et la condition qui prouve la fin de la tâche dans RTSP Inspector.

Procédure fondée sur les preuves

Commencez par un cas petit et répétable avant de modifier un projet complet. Notez version de l’application, système, identité de l’entrée ou de l’appareil, réglages pertinents et résultat attendu. Exécutez une action volontaire, conservez la première transition inattendue et comparez-la à un cas nominal si possible. Plusieurs changements simultanés masquent la condition qui a créé ou corrigé le problème.

Point de contrôle 1 : Le flux RTSP H.265 ne fonctionne pas : quand remettre la caméra en H.264

Si « Le flux RTSP H.265 ne fonctionne pas : quand remettre la caméra en H.264 » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 2 : Pourquoi les flux de caméras H.265 RTSP échouent souvent dans les navigateurs, les NVR, le

Vérifiez « Pourquoi les flux de caméras H.265 RTSP échouent souvent dans les navigateurs, les NVR, les systèmes d'analyse et les restreamers, et comment prouver » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 3 : Le succès du RTSP ne signifie pas la prise en charge des codecs

Si « Le succès du RTSP ne signifie pas la prise en charge des codecs » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 4 : Pourquoi H.265 échoue plus souvent que H.264

Vérifiez « Pourquoi H.265 échoue plus souvent que H.264 » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 5 : Inspecter SDP avant de modifier les paramètres

Si « Inspecter SDP avant de modifier les paramètres » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 6 : Le flux principal par rapport au sous-flux est souvent l'indice

Vérifiez « Le flux principal par rapport au sous-flux est souvent l'indice » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 7 : Quand le repli H.264 est la solution pratique

Si « Quand le repli H.264 est la solution pratique » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 8 : Où s’adapte l’inspecteur RTSP

Vérifiez « Où s’adapte l’inspecteur RTSP » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 9 : Preuve reproductible pour « Le flux RTSP H.265 ne fonctionne pas : quand remettre la camér

Si « Preuve reproductible pour « Le flux RTSP H.265 ne fonctionne pas : quand remettre la caméra en H.264 » » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 10 : Comment rédiger une réponse directement réutilisable ?

Vérifiez « Comment rédiger une réponse directement réutilisable ? » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Le flux RTSP H.265 ne fonctionne pas : quand remettre la caméra en H.264	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi les flux de caméras H.265 RTSP échouent souvent dans les navigateurs, les NVR, les systèmes d'analyse et les re	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Le succès du RTSP ne signifie pas la prise en charge des codecs	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi H.265 échoue plus souvent que H.264	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Inspecter SDP avant de modifier les paramètres	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Le flux principal par rapport au sous-flux est souvent l'indice	État initial, une action et état obtenu	Une seconde personne reproduit le résultat

Isolation, reprise et transmission

Arrêtez-vous à la première limite en échec. Conservez source, projet, session ou capture, dupliquez avant toute modification destructive et changez une variable par essai. Rejouer un flux entier après plusieurs changements peut modifier le résultat sans expliquer pourquoi.

Distinguez absence de preuve et preuve d’absence. Une vue vide peut signaler mauvaise entrée, portée, filtre, permission, appareil, période ou état du projet. Vérifiez acquisition ou import avant d’interpréter décodeur, éditeur, rapport ou export.

Avant transmission, rouvrez l’artefact durable et inspectez début, point de décision et fin. Notez version, plateforme, configuration, attente, observation et reproduction minimale. Retirez ou masquez les données sensibles et confirmez l’autorisation du destinataire.

Questions et réponses

Quelle est la manière fiable la plus rapide de commencer ?

Utilisez le plus petit cas représentatif, écrivez le résultat attendu et ne changez qu’une variable. Validez le parcours de base avant d’ajouter filtres, effets, modifications, automatisation ou grande source.

Quelles preuves faut-il conserver ?

Gardez identité de l’entrée, version, plateforme, réglages, action exacte, première transition inattendue et sortie finale. Fermez puis rouvrez projet, session, rapport ou export avant de le considérer durable.

Quand faut-il répéter la procédure ?

Répétez-la après un changement pertinent d’application, système, pilote, firmware, modèle, source ou processus. Conservez le cas accepté précédent comme référence non modifiée.

Quand le résultat est-il transmissible ?

Lorsqu’une seconde personne autorisée identifie l’entrée, répète l’action, obtient le même résultat, comprend les limites et ouvre l’artefact sans état local non documenté.

Guides associés

Ces pages dans la même langue couvrent les étapes voisines sans changer le propriétaire canonique du sujet :