Manquant H.264 SPS/PPS dans les flux RTSP : pourquoi VLC joue mais FFmpeg ou Analytics échoue

Un modèle d'échec RTSP frustrant est familier aux ingénieurs caméra: "VLC lit le flux, mais FFmpeg, un VMS, un pipeline d'analyse ou un service d'ingestion cloud échoue avec des erreurs de décodeur. Le fil de discussion devient souvent un débat sur le « bon » outil. La meilleure question est de savoir si le flux fournit suffisamment de preuves des paramètres H.264 pour un nouveau décodeur." H.264 a besoin d'ensembles de paramètres de séquence et d'ensembles de paramètres d'image. Les ingénieurs les appellent généralement SPS et PPS. Ils décrivent comment le flux binaire doit être décodé: "profil, niveau, dimensions, comportement de référence et structure d'image. Sans eux, un décodeur peut voir les données de tranche mais ne dispose toujours pas de contexte valide pour les transformer en images."

Où peuvent apparaître les SPS et PPS

Dans les déploiements RTSP, les preuves SPS/PPS peuvent apparaître à plusieurs endroits :

• SDP sprop-parameter-sets
• charges utiles RTP intra-bande avant les tranches
• répété avant les images clés
• mis en cache par un joueur tolérant d'une session précédente
• livré seulement après avoir attendu le prochain IDR

Ceci explique le problème du « fonctionne dans un seul visualiseur ». Un joueur peut réutiliser un état, attendre plus longtemps, récupérer des références manquantes ou appliquer une dissimulation d'erreur. Un service d'ingestion stricte peut démarrer avec un décodeur vide et rejeter le flux jusqu'à l'arrivée de SPS/PPS et d'une image clé utilisable.

Ce que signifie réellement l'erreur

Des messages tels que « image manquante dans l'unité d'accès », « erreur d'en-tête de décodage », « PPS référencé inexistant » ou « en attente de SPS/PPS » ne signifient pas automatiquement que la caméra est cassée. Ils signifient que le décodeur ne disposait pas du contexte de paramètres dont il avait besoin au moment où il essayait de décoder.

Les questions diagnostiques sont les suivantes :

• SDP a-t-il inclus des « ensembles de paramètres sprop » ?
• les SPS et PPS ont-ils été vus dans la charge utile RTP ?
• sont-ils arrivés avant la première tranche ?
• une trame IDR est-elle apparue après les jeux de paramètres ?
• la perte de paquets a-t-elle supprimé le paquet de paramètres ?
• le flux a-t-il commencé au milieu du GOP ?
• le type de charge utile était-il cohérent avec SDP ?

Une fois ces questions répondues, la prochaine action devient plus claire.

Pourquoi les démarrages de flux Mid-GOP sont risqués

De nombreuses caméras commencent à envoyer à partir de la position actuelle de l'encodeur lorsque le client RTSP se connecte. Si le client rejoint le milieu du GOP, il peut recevoir des inter-images avant une image clé. Si le flux ne parvient pas non plus à répéter SPS/PPS régulièrement, le décodeur peut attendre ou échouer jusqu'à la prochaine limite appropriée.

Pour un logiciel de surveillance, cela peut ressembler à :

• écran noir pendant plusieurs secondes
• la première image n'apparaît qu'après un mouvement ou un intervalle d'images clés
• le pipeline d'analyse refuse le flux
• le restreamer démarre mais les clients en aval échouent
• récupération occasionnelle après reconnexion

Le correctif peut être côté caméra : raccourcissez l’intervalle des images clés, répétez les ensembles de paramètres, utilisez un profil de flux différent ou passez de H.265 à H.264 si le produit en aval bénéficie d’une prise en charge plus stricte.

SDP est une réclamation ; RTP est une preuve

Certains systèmes de caméras annoncent SPS/PPS en SDP. D'autres s'attendent à ce que le décodeur attende les unités NAL intra-bande. Certains font les deux. Certains ne font ni l’un ni l’autre correctement. Un rapport de diagnostic doit comparer la réclamation à la charge utile.

Les preuves utiles comprennent :

• jeux de paramètres base64 dans SDP
• Types d'unités H.264 NAL observés dans RTP
• premier index de paquets SPS/PPS
• premier index de paquet IDR
• perte de paquets avant la préparation des images clés
• état de préparation du décodeur

C'est beaucoup plus fort que « essayez avec un autre joueur ». Il indique au fournisseur s'il doit modifier le SDP, les paramètres de l'encodeur ou le comportement de mise en paquets.

Où s’adapte l’inspecteur RTSP

RTSP Inspector est conçu pour inspecter la structure RTSP, SDP, RTP/RTCP et codec sans prétendre que la lecture est le diagnostic. Pour les cas SPS/PPS manquants, le produit devrait aider les ingénieurs à montrer :

• le flux s'est connecté avec succès
• SDP transportait ou non des jeux de paramètres
• RTP a fourni ou non des jeux de paramètres
• la perte de paquets a affecté ou non la première limite de décodage
• l'échec appartient aux métadonnées du flux, à la livraison réseau, à la prise en charge du décodeur ou à la configuration de la caméra

C'est le genre de preuve qui résout l'argument "VLC fonctionne". Le fonctionnement de VLC est une information utile. Cela ne prouve pas que le flux soit propre pour chaque consommateur.

Si votre requête de recherche est « RTSP fonctionne dans VLC mais FFmpeg échoue », inspectez SPS/PPS, les images clés, la perte de paquets et SDP avant de blâmer le système en aval.