Falta H.264 SPS/PPS en transmisiones RTSP: por qué se reproduce VLC pero falla FFmpeg o Analytics

Los ingenieros de cámaras conocen un patrón de falla RTSP frustrante: "VLC reproduce la transmisión, pero FFmpeg, un VMS, un canal de análisis o un servicio de ingesta en la nube fallan con errores de decodificador. El hilo de soporte a menudo se convierte en un debate sobre qué herramienta es la "correcta". La mejor pregunta es si la transmisión proporciona suficiente evidencia de parámetros H.264 para un decodificador nuevo." H.264 necesita conjuntos de parámetros de secuencia y conjuntos de parámetros de imagen. Los ingenieros suelen llamarlos SPS y PPS. Describen cómo se debe decodificar el flujo de bits: "perfil, nivel, dimensiones, comportamiento de referencia y estructura de la imagen. Sin ellos, un decodificador puede ver datos de corte pero aún no tener un contexto válido para convertirlos en fotogramas."

Dónde pueden aparecer SPS y PPS

En las implementaciones RTSP, la evidencia SPS/PPS puede aparecer en más de un lugar:

• SDP conjuntos-de-parámetros-sprop
• Cargas útiles RTP dentro de banda antes de los cortes
• repetido antes de fotogramas clave
• almacenado en caché por un jugador tolerante de una sesión anterior
• entregado solo después de esperar el próximo IDR

Esto explica el problema de "funciona en un solo visor". Un jugador puede reutilizar el estado, esperar más, recuperarse de referencias faltantes o aplicar ocultación de errores. Un servicio de ingesta estricto puede comenzar con un decodificador vacío y rechazar la transmisión hasta que lleguen SPS/PPS y un fotograma clave utilizable.

Lo que realmente significa el error

Mensajes como "falta imagen en la unidad de acceso", "error de encabezado de segmento de decodificación", "se hace referencia a PPS no existente" o "esperando SPS/PPS" no significan automáticamente que la cámara esté averiada. Significan que el decodificador no tenía el contexto de parámetros que necesitaba en el momento en que intentó decodificar.

Las preguntas diagnósticas son:

• ¿SDP incluyó sprop-parameter-sets?
• ¿Se vieron SPS y PPS en la carga útil de RTP?
• ¿Llegaron antes del primer trozo?
• ¿Apareció un marco IDR después de los conjuntos de parámetros?
• ¿La pérdida de paquetes eliminó el paquete del conjunto de parámetros?
• ¿La transmisión comenzó a mediados del Partido Republicano?
• ¿El tipo de carga útil era coherente con el SDP?

Una vez que se responden esas preguntas, la siguiente acción se vuelve más clara.

Por qué los inicios de transmisiones a mitad del Partido Republicano son riesgosos

Muchas cámaras comienzan a enviar desde la posición actual del codificador cuando se conecta el cliente RTSP. Si el cliente se une a mitad del Partido Republicano, puede recibir fotogramas intermedios antes de un fotograma clave. Si el flujo tampoco repite SPS/PPS regularmente, el decodificador puede esperar o fallar hasta el siguiente límite adecuado.

Para el software de monitoreo, esto puede verse así:

• pantalla negra durante varios segundos
• El primer fotograma aparece sólo después del movimiento o del intervalo de fotograma clave.
• La canalización de análisis rechaza la transmisión.
• El restreamer se inicia pero los clientes posteriores fallan.
• recuperación ocasional después de volver a conectarse

La solución puede estar en el lado de la cámara: acortar el intervalo de fotogramas clave, repetir conjuntos de parámetros, usar un perfil de transmisión diferente o cambiar de H.265 a H.264 si el producto descendente tiene un soporte más estricto.

SDP es un reclamo; El RTP es una prueba

Algunos sistemas de cámaras anuncian SPS/PPS en SDP. Otros esperan que el decodificador espere unidades NAL dentro de banda. Algunos hacen ambas cosas. Algunos no hacen ninguna de las dos cosas correctamente. Un informe de diagnóstico debe comparar el reclamo con la carga útil.

La evidencia útil incluye:

• conjuntos de parámetros base64 en SDP
• Tipos de unidades NAL H.264 observados en RTP
• primer índice de paquete SPS/PPS
• primer índice de paquete IDR
• pérdida de paquetes antes de que el fotograma clave esté listo
• estado de preparación del decodificador

Esto es mucho más fuerte que "probar con otro jugador". Le indica al proveedor si debe cambiar el SDP, la configuración del codificador o el comportamiento de paquetización.

Dónde encaja el inspector RTSP

RTSP Inspector está diseñado para inspeccionar RTSP, SDP, RTP/RTCP y la estructura de códecs sin pretender que la reproducción sea el diagnóstico. Para los casos SPS/PPS faltantes, el producto debería ayudar a los ingenieros a mostrar:

• la transmisión se conectó exitosamente
• SDP llevaba o no conjuntos de parámetros
• RTP entregó o no conjuntos de parámetros
• La pérdida de paquetes afectó o no el primer límite de decodificación.
• el error pertenece a los metadatos de la transmisión, la entrega de la red, la compatibilidad con el decodificador o la configuración de la cámara

Este es el tipo de evidencia que resuelve el argumento de que "VLC funciona". El funcionamiento de VLC es información útil. No es una prueba de que el flujo sea limpio para todos los consumidores.

Si su consulta de búsqueda es "RTSP funciona en VLC pero FFmpeg falla", inspeccione SPS/PPS, fotogramas clave, pérdida de paquetes y SDP antes de culpar al sistema descendente.