SDP, H.264 y H.265 en diagnóstico RTSP: los metadatos que deciden si el vídeo puede iniciarse

Muchas fallas de RTSP se describen como "la transmisión de la cámara no se reproduce". Esa frase oculta el límite de diagnóstico más importante: "¿qué afirmó la cámara en SDP y la carga útil de los medios coincidió con esa afirmación?" El SDP suele ser la primera evidencia estructurada disponible en una sesión RTSP. Declara pistas multimedia, tipos de carga útil, nombres de códecs, velocidades de reloj, URL de control y parámetros específicos del códec. Si el SDP es incorrecto, está incompleto o no es compatible con el consumidor, una transmisión puede fallar antes de que se decodifique el primer cuadro.

Lo que el SDP debería demostrar

Después de "DESCRIBE", un cliente debe saber si la transmisión contiene video, qué tipo de carga útil se asigna a qué códec y cómo se debe configurar la pista multimedia. Para el diagnóstico de la cámara, inspeccione:

• sección multimedia m=video
• URL de seguimiento a=control
• a=rtpmap tipo de carga útil y nombre de códec
• Parámetros del códec a=fmtp
• H.264 sprop-parameter-sets cuando esté presente
• Señalización H.265 VPS/SPS/PPS cuando esté disponible
• si se espera la velocidad de reloj anunciada

Si SDP anuncia H.264 pero la cámara envía algo más, el receptor no está siendo irrazonable. Si SDP omite evidencia de parámetros esenciales y la transmisión nunca la envía dentro de banda, es posible que el decodificador no tenga suficiente información para comenzar.

Los conjuntos de parámetros H.264 no son evidencia opcional

Los decodificadores H.264 necesitan información de parámetros de imagen y secuencia. En las implementaciones de cámaras RTSP, esta evidencia puede aparecer en SDP, cargas útiles RTP dentro de banda o ambas. Los problemas aparecen cuando una cámara supone que el receptor ya sabe algo que no sabe.

Un registro de diagnóstico limpio responde:

• ¿Era visible el SPS?
• ¿Era visible el PPS?
• ¿Las cargas útiles incluían un marco IDR?
• ¿La transmisión comenzó a mediados del Partido Republicano?
• ¿La identificación del nivel del perfil parecía plausible?
• ¿El modo de paquetización coincidió con la estructura de carga útil observada?

Esto es especialmente importante cuando un jugador trabaja y otro no. Un espectador tolerante puede sobrevivir a metadatos cuestionables. Un proceso de grabación, análisis o cumplimiento puede rechazarlo.

H.265 agrega más límites de compatibilidad

H.265 es común en las cámaras modernas, especialmente cuando el ancho de banda es importante, pero tiene un soporte menos universal que H.264 en herramientas más antiguas y consumidores integrados. H.265 también trae evidencia VPS además de SPS y PPS. Una implementación que solo diga "RTSP funciona" aún puede fallar porque el perfil de códec real o la entrega de parámetros están fuera de los límites admitidos por el consumidor.

Para los equipos de campo, un artículo, ticket o informe útil no debe decir sólo "cambiar a H.264". Debe explicar por qué:

• el consumidor actual carece de soporte H.265
• los conjuntos de parámetros H.265 faltan o están retrasados
• el tipo de carga útil no coincide con la asignación de códec esperada
• la secuencia es válida pero está fuera del límite del producto
• el perfil de la cámara debe cambiarse para este flujo de trabajo

Ese nivel de claridad evita repetidos cambios de prueba y error.

SDP debe compararse con RTP

SDP es un reclamo. RTP es la evidencia que sigue. Hay que comparar ambos.

Ejemplos:

• SDP afirma que el tipo de carga útil 96 es H.264, pero RTP llega con un tipo de carga útil diferente.
• SDP contiene una pista de vídeo, pero ningún RTP sigue a "PLAY".
• SDP dice H.265, pero el producto descendente solo admite H.264.
• SDP omite conjuntos de parámetros y RTP nunca los envía antes de los cortes.
• Llega RTP, pero la estructura de la unidad NAL no coincide con el códec anunciado.

Estos casos requieren diferentes acciones siguientes. Sin comparar SDP y RTP, todos parecen el mismo fallo vago de "no hay vídeo".

Por qué el inspector RTSP saca a la luz esta evidencia

RTSP Inspector está diseñado para ingenieros de transmisión, proveedores de cámaras e integradores de CCTV que necesitan evidencia repetible. Intencionalmente no es un reproductor multimedia genérico. Su trabajo es inspeccionar la ruta de control RTSP, los metadatos SDP, el flujo RTP/RTCP y la preparación de H.264/H.265.

Eso hace que el resultado sea útil en las conversaciones de soporte:

• proveedor de cámara: arreglar SDP o paquetización
• equipo de red: arreglar la ruta de entrega RTP
• Equipo VMS: ajuste el perfil de códec admitido
• Integrador de campo: cambiar el perfil de flujo o el modo de transporte.
• Cliente: comprenda por qué la reproducción no es una prueba del estado del protocolo.

En los diagnósticos RTSP, SDP no es texto repetitivo. Es el primer contrato que ofrece la transmisión. Si ese contrato se rompe, el resto del proceso está en conjeturas.