2026-06-02

Erreur du serveur interne RTSP 500 : chemin du flux de la caméra, ressource de l'encodeur, micrologiciel et diagnostics de session

Comment dépanner l'erreur de serveur interne RTSP 500 provenant des caméras IP et des NVR, y compris les mauvais chemins de flux, les limites de ressources de l'encodeur, les bogues du micrologiciel, le nombre maximal de connexions et les sessions échouées.

« Erreur de serveur interne RTSP/1.0 500 » est l'une des réponses RTSP les moins utiles car elle vous indique que la caméra ou le NVR a échoué en interne, mais elle ne précise pas pourquoi. Les utilisateurs recherchent « Erreur de serveur interne RTSP 500 », « Erreur de serveur interne RTSP de caméra », « ffmpeg RTSP 500 », « NVR RTSP 500 » et « Erreur de flux de caméra IP 500 » lorsque le service RTSP est accessible mais que le flux ne peut pas être créé.

Contrairement à « 401 Unauthorized », « 404 Not Found », « 454 Session Not Found » ou « 461 Unsupported Transport », « 500 » pointe souvent vers un chemin de défaillance côté serveur : mauvaise ressource de flux, encodeur non prêt, trop de sessions, bug du micrologiciel, état de profil non valide, canal NVR hors ligne ou limite de tampon/ressource interne.

RTSP Inspector est utile car la méthode RTSP exacte et le timing sont importants. « 500 » sur « DESCRIBE » signifie quelque chose de différent de « 500 » sur « SETUP » ou « PLAY ».

Ce que signifie RTSP 500

« 500 Erreur interne du serveur » signifie que le serveur RTSP a suffisamment accepté la demande pour la traiter, mais a rencontré une défaillance interne. Le serveur peut être la caméra elle-même, un NVR, une passerelle multimédia ou un service de retransmission.

Exemples :

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 500 Internal Server Error

or:

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 500 Internal Server Error

La première suggère que le serveur n'a pas pu décrire ou créer la ressource de flux. La seconde suggère que SDP existait mais que la configuration du transport multimédia a échoué en interne.

Chemin de flux incorrect ou incomplet

Certaines caméras renvoient « 404 » pour un mauvais chemin. D'autres renvoient « 500 » car leur service RTSP tente de résoudre le chemin du flux en interne et échoue. Ceci est courant avec les URL RTSP spécifiques au fournisseur.

Vérifiez les modèles de chemin tels que :

/stream1
/live
/h264
/cam/realmonitor?channel=1&subtype=0
/Streaming/Channels/101
/profile1/media.smp

If the URL has a channel number, profile name, or query parameter, verify it against the exact camera model. A path from a similar model may not work.

Encoder not ready or resource exhausted

IP cameras have limited encoding resources. A camera may fail internally when asked to create a stream profile it cannot currently provide.

Causes include:

Too many clients already connected.
Main stream already used by another profile.
H.265/H.264 encoder resource conflict.
Resolution/frame rate/bitrate combination too heavy.
NVR channel offline.
Camera is rebooting encoder after settings change.
Audio/video profile references disabled components.
Internal buffer space exhausted.

If rebooting the camera temporarily fixes 500, resource exhaustion or firmware state becomes more likely.

500 after authentication

Sometimes authentication succeeds and 500 appears only after the authenticated retry. That means credentials are probably not the main issue. The camera accepted the user enough to reach stream creation but failed internally.

Still check permissions:

User allowed to access live video?
User allowed to access that channel?
Main stream vs sub-stream permission?
NVR user allowed to view target channel?

Some NVRs return generic server errors instead of clean authorization errors.

Method-specific diagnosis

Use the failed method as a guide:

OPTIONS 500: RTSP service itself is unhealthy.
DESCRIBE 500: stream path, profile, encoder, or channel state.
SETUP 500: track control URL, transport setup, RTP resource allocation.
PLAY 500: session created but media start failed.
Keepalive 500: session state or firmware instability.

This is why the whole RTSP sequence must be preserved.

Debug checklist

Use this process:

Identify the exact method that receives 500.
Confirm authentication status before the error.
Validate the stream path for the exact model.
Test main stream and sub-stream.
Reduce resolution, bitrate, frame rate, or switch codec.
Disconnect other RTSP clients and VMS recorders.
Test direct camera URL vs NVR/restream URL.
Check camera/NVR logs for encoder or channel errors.
Reboot only after collecting the RTSP trace.
Record whether the failure is constant or intermittent.

Final diagnosis

RTSP 500 Internal Server Error is a server-side RTSP failure. The likely causes are wrong stream resource, unavailable encoder, resource exhaustion, NVR channel state, firmware bug, or failed media setup.

RTSP Inspector helps by showing exactly which RTSP method triggered the 500 and what happened before it, so troubleshooting can focus on the camera/NVR service state instead of guessing at playback or codec layers.

Preuve reproductible pour « Erreur du serveur interne RTSP 500 : chemin du flux de la caméra, ressource de l'encodeur, micrologiciel et diagnostics de session »

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 « Erreur du serveur interne RTSP 500 : chemin du flux de la caméra, ressource de l'encodeur, micrologiciel et diagnostics de session », 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.

De l’observation au verdict par couche

Pour « Erreur du serveur interne RTSP 500 : chemin du flux de la caméra, ressource de l'encodeur, micrologiciel et diagnostics de session », écrivez d’abord l’observation puis son interprétation. Une observation peut être retrouvée dans la capture : statut RTSP lié à CSeq, valeur SDP, réponse Transport, trou de séquence, changement de SSRC ou différence entre RTP timestamp et RTCP sender report. « Le serveur est lent » ou « le codec est incompatible » reste une hypothèse tant qu’un élément précis ne la rend pas plus probable que les autres.

Découpez le parcours en frontières. TCP doit s’ouvrir, puis OPTIONS ou DESCRIBE être accepté. Le SDP doit décrire une piste exploitable, son control URL, payload type et clock rate. SETUP exige une réponse Transport compatible et PLAY une Session valide. Viennent ensuite arrivée RTP, ordre, temps et préparation du décodeur. Arrêtez-vous à la première frontière sans preuve de réussite ; une donnée ultérieure ne doit pas masquer une lacune antérieure.

Gardez source et intervalle constants pendant les comparaisons. UDP et TCP interleaved utilisent le même chemin et les mêmes identifiants. Main stream et sub stream gardent client et transport. Pour VLC face à un VMS, consignez méthodes, en-têtes et URL réels. Une différence de control URL, Authorization, Session ou keepalive explique parfois davantage que le nom de l’application.

Matrice d’exclusion

Commencez par deux hypothèses. Sans média, UDP peut être bloqué ou le serveur peut envoyer vers d’autres ports. TCP interleaved teste la première ; comparer offre et réponse Transport, adresses et ports teste la seconde. Pour une image corrompue, les séquences RTP séparent perte et initialisation incomplète, tandis que SPS/PPS/VPS avant la première image teste les paramètres codec.

Pour chaque hypothèse, notez une preuve favorable et une preuve qui pourrait la réfuter. Une affirmation qu’aucun paquet ne peut contredire est trop large. « Le NAT supprime UDP » est réfuté par RTP au port client. « Les paramètres H.264 manquent » est réfuté par SPS et PPS valides avant IDR. Le rapport reste ainsi ordonné plutôt qu’une liste de possibilités.

Interpréter le temps sans surconclure

RTSP CSeq ordonne les transactions, RTP sequence les paquets, RTP timestamp le temps d’échantillonnage, et l’horloge de capture l’arrivée au point observé. Ne les confondez pas. Une arrivée irrégulière ne prouve pas une dérive ; un saut timestamp ne prouve pas une perte sans séquence. Les RTCP sender reports relient les horloges RTP audio et vidéo à une référence commune.

Dossier de recette

Fermez l’enquête lorsque la correction se répète sur une connexion neuve avec un changement documenté. Le rapport indique entrées, dernière frontière réussie, première preuve en échec, modification, résultat et tests ouverts. Joignez un court extrait de transcription ou des statistiques ciblées. Masquez les secrets, mais gardez CSeq, Session nettoyée, SSRC et plage temporelle.

La procédure de dépannage RTSP reconstruit le parcours ; les rapports RTSP Inspector transmettent la frontière prouvée aux équipes caméra, réseau ou VMS.