2026-06-02

Correctif de transport non pris en charge RTSP 461 : échec de la configuration, UDP vs TCP, erreur de transport de la caméra ffmpeg

Correction du transport non pris en charge RTSP 461 et de la méthode ffmpeg \"Échec de la configuration : 461\". Couvre les erreurs de transport UDP vs TCP entrelacé, les en-têtes de transport de caméra, Frigate, Scrypted et l'intégration NVR.

« RTSP/1.0 461 Unsupported Transport » est l'une des erreurs RTSP les plus consultables car elle apparaît dans les ponts ffmpeg, Frigate, Scrypted, HomeKit, les intégrations NVR, les clients Android et les outils de caméra personnalisés. Le journal indique souvent « échec de la méthode SETUP: "461 Transport non pris en charge ». La caméra peut accepter « OPTIONS » et « DESCRIBE », mais lorsque le client essaie de configurer le transport multimédia RTP, la caméra rejette le mode de transport demandé."

Les utilisateurs recherchent "RTSP 461 Unsupported Transport", "ffmpeg method SETUP failed 461", "RTSP UDP vs TCP camera", "RTP AVP TCP entrelacé non pris en charge" et "camera SETUP failed unsupported transport" car le problème ne vient pas uniquement de l'URL RTSP. C'est la négociation de transport entre client et serveur.

RTSP Inspector est utile ici car la preuve décisive est la requête SETUP et l'en-tête Transport.

Ce que fait le CONFIGURATION

Après DESCRIBE, le client connaît les pistes de flux de SDP. Ensuite, il envoie SETUP pour chaque piste afin de négocier le transport multimédia.

Exemple UDP :

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
Transport: RTP/AVP;unicast;client_port=50000-50001

TCP interleaved example:

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

Si la caméra ne prend pas en charge le mode demandé, elle peut renvoyer :

RTSP/1.0 461 Unsupported Transport

UDP-only and TCP-only behavior

Many cameras support both UDP RTP and TCP interleaved RTP. Some do not. Some older cameras support only UDP. Some cloud relays or restreamers support only TCP interleaved. Some NVR paths behave differently from direct camera paths.

Symptoms:

UDP SETUP fails but TCP works.
TCP interleaved SETUP fails but UDP works.
Direct camera works, restream URL fails.
Main stream supports one mode, sub-stream supports another.
Client retries from UDP to TCP and still fails because the server rejects both requested formats.

The fix is not "always use TCP" or "always use UDP." The fix is to identify what the server actually accepts.

Transport header syntax matters

Some RTSP servers are strict. They may reject headers that are valid in theory but not accepted by firmware.

Compare:

Transport: RTP/AVP;unicast;client_port=50000-50001

et:

Transport: RTP/AVP/UDP;unicast;client_port=50000-50001

Some devices treat these differently. Some reject multicast. Some reject a client port range outside expected bounds. Some reject interleaved channel numbers not starting from zero.

RTSP Inspector should preserve the exact header string, not just a simplified "TCP" or "UDP" label.

Restreamers and proxy paths

When RTSP comes through a restreamer, NVR, or media bridge, the upstream and downstream transport capabilities may not match. The camera may support UDP, but the restreamer only exposes TCP. Or the restreamer may accept a SETUP request but fail when mapping media channels.

If a URL points to 127.0.0.1:8554 or another restreamer instead of the camera, diagnose that server's RTSP behavior, not only the camera's.

Debug checklist

Use this workflow:

Capture DESCRIBE and SDP.
Identify the track URL used in SETUP.
Inspect the exact Transport header.
Record the 461 Unsupported Transport response.
Try UDP and TCP interleaved modes deliberately.
Check whether the camera supports multicast, UDP unicast, or TCP interleaved.
Compare main stream and sub-stream.
Compare direct camera URL and NVR/restream URL.
Avoid codec debugging until SETUP succeeds.
Preserve the exact request/response pair for vendor support.

Final diagnosis

RTSP 461 Unsupported Transport means the server rejected the media transport requested during SETUP. The root cause is usually UDP/TCP mode mismatch, strict Transport header syntax, unsupported interleaved mode, unsupported UDP mode, restreamer behavior, or track-specific server limitations.

RTSP Inspector helps diagnose this at the correct layer: RTSP transport negotiation before RTP packets ever appear.

Preuve reproductible pour « Correctif de transport non pris en charge RTSP 461 : échec de la configuration, UDP vs TCP, erreur de transport de la caméra ffmpeg »

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 « Correctif de transport non pris en charge RTSP 461 : échec de la configuration, UDP vs TCP, erreur de transport de la caméra ffmpeg », 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 à « Correctif de transport non pris en charge RTSP 461 : échec de la configuration, UDP vs TCP, erreur de transport de la caméra ffmpeg » est la suivante : Correction du transport non pris en charge RTSP 461 et de la méthode ffmpeg "Échec de la configuration : 461". Couvre les erreurs de transport UDP vs TCP entrelacé, les en-têtes de transport de caméra, Frigate, Scrypted et l'intégration NVR. 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 : Correctif de transport non pris en charge RTSP 461 : échec de la configuration, UDP vs TCP

Ne fermez « Correctif de transport non pris en charge RTSP 461 : échec de la configuration, UDP vs TCP, erreur de transport de la caméra ffmpeg » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 2 : Correction du transport non pris en charge RTSP 461 et de la méthode ffmpeg "Échec de la

Pour « Correction du transport non pris en charge RTSP 461 et de la méthode ffmpeg "Échec de la configuration : 461". Couvre les erreurs de transport UDP v », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 3 : Ce que fait le CONFIGURATION

Ne fermez « Ce que fait le CONFIGURATION » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 4 : UDP-only and TCP-only behavior

Pour « UDP-only and TCP-only behavior », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 5 : Transport header syntax matters

Ne fermez « Transport header syntax matters » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 6 : Restreamers and proxy paths

Pour « Restreamers and proxy paths », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 7 : Debug checklist

Ne fermez « Debug checklist » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 8 : Final diagnosis

Pour « Final diagnosis », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 9 : Preuve reproductible pour « Correctif de transport non pris en charge RTSP 461 : échec de

Ne fermez « Preuve reproductible pour « Correctif de transport non pris en charge RTSP 461 : échec de la configuration, UDP vs TCP, erreur de transport de la camé » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

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

Pour « Comment rédiger une réponse directement réutilisable ? », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Correctif de transport non pris en charge RTSP 461 : échec de la configuration, UDP vs TCP, erreur de transport de la ca	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Correction du transport non pris en charge RTSP 461 et de la méthode ffmpeg "Échec de la configuration : 461". Couvre	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Ce que fait le CONFIGURATION	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
UDP-only and TCP-only behavior	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Transport header syntax matters	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Restreamers and proxy paths	É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 :