RTSP se conecta pero no muestra vídeo: qué inspeccionar antes de culpar al reproductor

Uno de los tickets de soporte de cámara más comunes suena simple: "la URL RTSP se conecta, la autenticación se realiza correctamente, pero el espectador no muestra ningún vídeo. El instinto natural es probar con otro jugador. Esto puede ser útil, pero no responde a la pregunta de ingeniería: ¿la transmisión falló en el control RTSP, la negociación SDP, la entrega RTP o la preparación del códec?" Para los integradores de CCTV, los ingenieros de VMS y los proveedores de cámaras, esta distinción es importante. Un reproductor puede ocultar la pérdida de paquetes, reutilizar el estado anterior del decodificador o reintentar silenciosamente los modos de transporte. Un informe de diagnóstico debe explicar qué parte del flujo se demostró que era saludable y cuál no.

Separe el éxito del control del éxito de los medios

RTSP es un protocolo de control. Una secuencia exitosa de DESCRIBE, SETUP y PLAY prueba que la cámara aceptó la sesión. No prueba que hayan llegado paquetes RTP. Tampoco prueba que la carga útil sea realmente H.264 o H.265 en la forma anunciada por SDP.

Un registro útil de primer paso:

• los códigos de estado RTSP para OPCIONES, DESCRIBE, SETUP y PLAY
• si el cuerpo del SDP contiene una sección de medios de video
• el tipo de carga útil negociado para la pista de vídeo
• si los paquetes RTP llegan después de "PLAY"
• si la marca de tiempo RTP y los números de secuencia avanzan
• si la primera carga de vídeo contiene evidencia de parámetros de códec

Si el control tiene éxito pero no llega RTP, el problema suele ser el transporte, el firewall, NAT, el modo de cámara o la disponibilidad de la transmisión del lado del servidor. Si llega RTP pero no hay ningún vídeo listo para decodificar, el problema se desplaza hacia la carga útil, la paquetización o los metadatos del códec.

Por qué el SDP es el primer límite de la evidencia

SDP le dice al cliente lo que la cámara afirma que enviará. Para H.264, los ingenieros buscan valores rtpmap y fmtp, como modo de paquetización, ID de nivel de perfil y sprop-parameter-sets. Para H.265, el SDP puede transportar información VPS, SPS y PPS de manera diferente, y muchos consumidores tienen límites de soporte más estrictos.

Cuando el SDP dice H.264 pero los bytes de medios no contienen la estructura de unidad NAL esperada, la falla no es un "problema del reproductor" genérico. Es una falta de coincidencia entre los metadatos anunciados y la realidad de la carga útil. Cuando SDP omite conjuntos de parámetros y el flujo RTP nunca los envía dentro de banda, un decodificador puede esperar una eternidad.

Es por eso que un flujo de trabajo de inspección RTSP debe mantener al SDP al lado de la evidencia de los medios, no enterrado en un registro del jugador.

La llegada del RTP no es suficiente

Incluso cuando llegan paquetes RTP, el vídeo aún puede fallar. Las tramas H.264 y H.265 a menudo dependen de paquetes anteriores. Un paquete faltante puede hacer que el siguiente segmento no se pueda decodificar. La entrega fuera de orden puede parecer corrupción. Es posible que una carga útil que se inicia a mitad del GOP no esté lista para decodificarse hasta que aparezca el siguiente fotograma clave y conjunto de parámetros.

La evidencia mínima a recolectar es:

• Continuidad de la secuencia RTP
• progresión de la marca de tiempo
• comportamiento del bit marcador
• consistencia del tipo de carga útil
• Categorías de unidades NAL H.264 o H.265
• Visibilidad de SPS, PPS y VPS H.265
• preparación del primer fotograma clave

Esto explica por qué "VLC lo juega" y "nuestro proceso de análisis lo rechaza" pueden ser ciertos. Algunos espectadores se recuperan agresivamente. Los sistemas de ingeniería a menudo necesitan evidencia limpia de estándares.

TCP versus UDP es una opción de diagnóstico

Cambiar el transporte RTSP de UDP a TCP es un paso común para la solución de problemas, pero no debe considerarse como una panacea. El entrelazado TCP puede evitar el bloqueo de puertos UDP y reducir la pérdida de paquetes causada por la política de red. También puede ocultar si la ruta UDP prevista para la implementación funciona.

Un buen informe de campo registra ambos intentos:

• RTSP sobre TCP intercalado: ¿llegan los medios?
• RTP sobre unidifusión UDP: ¿llegan los paquetes a los puertos negociados?
• RTCP: ¿los comentarios del remitente muestran el tiempo y el recuento de paquetes?

Si TCP funciona y UDP falla, la respuesta probablemente no sea la compatibilidad con códecs. Probablemente se trate de una ruta de red, un firewall, NAT o una asignación de puerto. Si ambos transportes entregan RTP pero la decodificación aún falla, inspeccione la estructura del códec.

Dónde encaja el inspector RTSP

RTSP Inspector está diseñado para este límite exacto. No pretende convertirse en un reproductor de vídeo o NVR. Capta la evidencia sobre la sesión RTSP, SDP, flujo RTP/RTCP y preparación H.264/H.265 para que un ingeniero pueda explicar por qué "conectado" no se convirtió en "vídeo utilizable".

El resultado útil no es una captura de pantalla de una ventana del reproductor en negro. Es una respuesta repetible:

• El control RTSP fue exitoso
• SDP anunció este códec y tipo de carga útil
• RTP llegó o no
• La secuencia del paquete era continua o estaba rota.
• La evidencia del parámetro códec estaba presente o faltaba.
• la siguiente acción pertenece a la red, configuración de la cámara, firmware o consumidor de transmisión

Esa es la diferencia entre mirar una transmisión y diagnosticarla.