La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demuestra la diferencia

Una consulta de búsqueda de cámara IP muy común es "La transmisión principal RTSP no funciona pero la transmisión secundaria sí". El síntoma es lo suficientemente específico como para ser útil. Si la transmisión secundaria funciona, se puede acceder a la cámara, las credenciales probablemente sean correctas, el servicio RTSP está habilitado y se puede acceder al menos a un perfil de video. El problema ya no es "RTSP está roto". El problema es la diferencia entre los perfiles de transmisión.

La transmisión principal y la transmisión secundaria generalmente difieren en resolución, tasa de bits, códec, intervalo GOP, tamaño de carga útil y, a veces, incluso ruta URL. Una transmisión secundaria puede ser H.264 con baja resolución, mientras que la transmisión principal es H.265, 4K, con alta tasa de bits o restringida a menos sesiones simultáneas. Un NVR puede exponer diferentes caminos desde la propia cámara. ONVIF puede devolver una URL en vivo de baja calidad, mientras que la URL de grabación o el perfil principal requieren una ruta separada.

La pregunta de diagnóstico útil es: ¿qué prueba la subcorriente de trabajo y qué no prueba?

Lo que demuestra una subcorriente funcional

Si la subtransmisión se puede abrir a través de RTSP, normalmente puedes decir:

• la dirección IP de la cámara es accesible
• el puerto RTSP está abierto
• la autenticación funciona para al menos una secuencia
• el cliente puede analizar respuestas RTSP básicas
• DESCRIBE, SETUP y PLAY pueden funcionar correctamente para al menos un perfil
• La entrega RTP es posible para al menos una pista multimedia

Esa es una evidencia valiosa. Limita la búsqueda. No debe seguir depurando la accesibilidad básica de la red después de este punto a menos que la transmisión principal utilice un host, puerto, modo de transporte o ruta NVR diferente.

Lo que una subcorriente funcional no prueba

Una subcorriente en funcionamiento no prueba:

• la ruta URL de la transmisión principal es correcta
• la transmisión principal está habilitada
• el códec de transmisión principal es compatible
• la tasa de bits de la transmisión principal puede cruzar la red
• la corriente principal está disponible para múltiples clientes
• la corriente principal envía evidencia SPS/PPS o VPS/SPS/PPS lista para decodificar
• el NVR expone la corriente principal de la cámara a través del mismo camino

Es por eso que "VLC puede abrir la transmisión secundaria" no es suficiente para un VMS, un sistema de análisis o una canalización de retransmisión que necesita la transmisión principal.

Verifique la ruta URL antes del códec

Muchas familias de cámaras utilizan diferentes patrones de ruta para las transmisiones principales y secundarias. Algunos usan "perfil1" y "perfil2". Algunos usan /Streaming/Channels/101 y /Streaming/Channels/102. Algunos usan "principal", "sub", "video1", "video2" o nombres de acceso específicos del proveedor. Algunos NVR exponen los canales de forma diferente a las URL directas de las cámaras.

Si la transmisión principal devuelve "404 No encontrado", inspeccione:

• URI de solicitud exacta enviada en DESCRIBE
• si la ruta URL coincide con el modelo del proveedor
• número de canal
• número de flujo
• token de perfil descubierto por ONVIF
• si la transmisión está habilitada en la interfaz de usuario web de la cámara
• si la URL apunta a la IP de la cámara o a la IP del NVR

No trate un 404 como pérdida de paquete. RTP aún no ha comenzado.

Verifique el códec y la tasa de bits después de que la ruta sea válida

Si la transmisión principal devuelve SDP e inicia RTP pero aún no muestra video, pase a códec y evidencia multimedia.

Las fallas de la corriente principal a menudo provienen de:

• H.265 seleccionado mientras que el consumidor espera H.264
• faltan pruebas de H.264 SPS/PPS o H.265 VPS/SPS/PPS
• intervalo de fotograma clave muy largo
• Pérdida alta de velocidad de bits a través de Wi-Fi o enlace ascendente débil
• Fragmentación y pérdida de paquetes en movimiento.
• Perfil o nivel del decodificador no soportado por el sistema aguas abajo.

En esta etapa, el informe debe incluir SDP, tipo de carga útil, continuidad de la secuencia RTP, evidencia de la unidad NAL del códec y si se alcanzó el primer límite de decodificación.

Límites de simultaneidad y comportamiento de NVR

Algunas versiones económicas de DVR, NVR o firmware de cámara limitan el acceso a la transmisión principal. La transmisión secundaria puede permanecer disponible mientras la transmisión principal ya se consume en la pantalla local, la grabación, la aplicación del proveedor u otro cliente. Esto puede parecer un problema de URL incluso cuando la ruta es correcta.

Comprobaciones útiles:

• desconectar a otros espectadores
• Pruebe la IP de la cámara directa frente a la IP del NVR
• comparar la transmisión principal desde la interfaz de usuario web de la cámara
• menor tasa de bits o resolución de la transmisión principal
• cambiar el códec de transmisión principal de H.265 a H.264
• Pruebe RTSP sobre TCP intercalado y UDP por separado

Si reducir la tasa de bits soluciona el problema, la falla original puede ser la capacidad de transporte en lugar de la sintaxis de la URL.

Cómo debería encuadrar el inspector RTSP este caso

RTSP Inspector es más fuerte cuando explica el límite:

• la ruta de control de la subcorriente es exitosa
• La ruta de control de la corriente principal falla con el código de estado
• La transmisión principal devuelve SDP pero no RTP
• La corriente principal RTP llega con pérdida de paquetes
• Faltan metadatos del códec de transmisión principal o no son compatibles
• La corriente principal es H.265, mientras que el consumidor necesita H.264.

Ésa es la diferencia entre "la corriente principal rota" y un informe de soporte útil. La siguiente acción correcta podría ser la búsqueda de URL del proveedor, la configuración del perfil de transmisión, el cambio de códec, la reducción de la tasa de bits, la actualización del firmware o la reparación de la ruta de red.

Si su búsqueda exacta es "La subtransmisión RTSP funciona pero la transmisión principal no", comience comparando los métodos RTSP, SDP, códec, transporte y concurrencia. La subcorriente de trabajo no es el final del diagnóstico. Es la muestra de control.