Error de RTP en la solución de transmisión principal: diagnosticar pérdida de paquetes, congelaciones de cámara y macrobloques en RTSP

Cuando la transmisión de una cámara IP se congela, entrecorta o produce errores del decodificador H.264, el síntoma visible suele llegar tarde. La causa suele aparecer antes en la secuencia RTP. Un paquete RTP faltante puede eliminar una porción de datos de video de los que dependen los fotogramas posteriores. Para cuando el reproductor registra un error de decodificación, es posible que la evidencia de la red ya haya desaparecido.

Es por eso que la solución de problemas de RTP debe comenzar con los números de secuencia, las marcas de tiempo, el tipo de carga útil, el comportamiento del marcador y la estructura del códec antes de cambiar la configuración aleatoria de la cámara.

Lo que le dicen las brechas en la secuencia RTP

Cada paquete RTP lleva un número de secuencia. Para un flujo constante, la secuencia debería avanzar de manera predecible. Un espacio significa que uno o más paquetes no llegaron. Un salto hacia atrás puede indicar reordenamiento, entrega duplicada, comportamiento de reinicio o problemas con los límites de captura.

Las preguntas prácticas son:

• ¿Cuántos paquetes faltaron?
• ¿La pérdida ocurrió una vez o repetidamente?
• ¿Ocurrió cerca de fotogramas clave?
• ¿Continuaron los informes del remitente RTCP?
• ¿Permaneció viva la sesión de control RTSP?
• ¿Ocurrió la falla del decodificador después del intervalo?

Esta evidencia puede separar la pérdida de red de los errores en la carga útil de la cámara. Si las brechas en la secuencia se alinean con la corrupción visual, el caso es más sólido. Si la continuidad de la secuencia es perfecta pero la carga útil tiene un formato incorrecto, el diagnóstico avanza hacia el comportamiento del codificador o de la paquetización.

Por qué H.264 y H.265 son sensibles a las pérdidas

El vídeo comprimido no es una lista de imágenes independientes. Los marcos intermedios dependen de los marcos de referencia. La pérdida de un pequeño paquete puede dañar más que el paquete inmediato. Los flujos H.264 y H.265 también pueden depender de conjuntos de parámetros como SPS y PPS, y H.265 agrega VPS. Si faltan, llegan tarde o están dañados, el software posterior puede rechazar la transmisión incluso cuando un espectador tolerante parece recuperarse.

Los síntomas comunes incluyen:

• macrobloques o artefactos en bloques
• se congela seguido de una recuperación repentina
• Errores del decodificador de estilo "referencia faltante"
• La transmisión comienza pero ningún fotograma está listo para decodificar.
• corrupción repetida después de escenas con mucho movimiento

Estos síntomas no son suficientes por sí solos. La evidencia de RTP y códec los hace procesables.

No confunda el nerviosismo con la pérdida

Jitter significa que los paquetes llegan con tiempos desiguales. La pérdida significa que los paquetes no llegan. Ambos pueden causar tartamudeo visible para el usuario, pero requieren soluciones diferentes.

Para detectar fluctuaciones, inspeccione la progresión de la marca de tiempo y el tiempo de llegada. En busca de pérdidas, inspeccione los espacios en la secuencia. Para detectar errores en el firmware de la cámara, inspeccione la coherencia de la carga útil y la estructura NAL. Un informe de campo que solo dice "la transmisión está entrecortada" no le dice a un ingeniero de red, ingeniero de firmware o proveedor de VMS qué cambiar.

El mejor informe dice:

• Brecha de secuencia RTP de N a N+M
• salto de marca de tiempo observado en el mismo punto
• La sesión RTSP permaneció establecida
• el tipo de carga útil se mantuvo estable
• El segmento H.264 estaba incompleto
• siguiente cuadro IDR restableció la preparación del decodificador

Ese es un artefacto de apoyo mucho más fuerte.

UDP y TCP cuentan historias diferentes

RTSP comúnmente transporta RTP a través de UDP o TCP entrelazado. UDP expone directamente la pérdida de paquetes. TCP puede hacer que desaparezcan las rutas UDP bloqueadas, pero puede introducir latencia y no demuestra que la ruta de implementación prevista esté en buen estado.

Para el diagnóstico, compare ambos modos:

• UDP falla con espacios en la secuencia: inspeccione la pérdida de red, los conmutadores, Wi-Fi, firewall, NAT o el comportamiento de envío de la cámara.
• UDP no recibe RTP: inspeccione los puertos negociados y la política de firewall.
• TCP funciona pero UDP falla: ruta de red sospechosa en lugar de códec.
• Ambos modos muestran una carga útil con formato incorrecto: codificador de cámara sospechoso, perfil de transmisión o firmware.

La elección del transporte es una prueba, no sólo una casilla de verificación del jugador.

Cómo RTSP Inspector enmarca el problema

RTSP Inspector se centra en la evidencia del protocolo en lugar de en la reproducción. Captura observaciones RTSP, RTP, RTCP y códecs para poder reproducir y explicar un caso de soporte. Eso importa cuando la misma transmisión se comporta de manera diferente en VLC, FFmpeg, un NVR, un servicio de ingesta en la nube y un canal de análisis.

El objetivo no es afirmar que todas las transmisiones se puedan arreglar localmente. El objetivo es identificar al dueño de la falla:

• ruta de red
• configuración de la cámara
• paquetización del firmware
• soporte de decodificador descendente
• límite de códec no compatible
• discrepancia esperada en la implementación de UDP/TCP

La pérdida de RTP no es sólo un síntoma de vídeo. Es un evento protocolar medible. Una vez que se mide, la conversación para solucionar problemas se vuelve mucho más corta.