2026-06-02

Cambio de RTP SSRC a mitad de la transmisión: depuración de reinicios de la cámara, cambios de fuente de transmisión, restablecimientos de secuencia y fallas del decodificador

Cómo diagnosticar cambios RTP SSRC en transmisiones de cámara RTSP, restablecimientos de números de secuencia, discontinuidad de marca de tiempo, reinicios del codificador de cámara, transmisiones de conmutación por error y fallas en el decodificador.

RTP SSRC identifica la fuente de sincronización de una secuencia RTP. Cuando cambia en medio de una sesión RTSP, los usuarios pueden ver congelaciones, cuadros negros, desincronización de audio/video, video corrupto, alarmas de pérdida de paquetes o reinicio repentino del decodificador. Las frases de búsqueda incluyen "RTP SSRC cambiado", "La transmisión RTSP se congela después de reiniciar la cámara", "restablecimiento del número de secuencia RTP", "discontinuidad de la marca de tiempo RTP" y "la fuente de la transmisión de la cámara cambió a mitad de la transmisión".

RTSP Inspector es útil porque esta no es una pregunta normal de un jugador. La evidencia clave se encuentra en los encabezados de los paquetes RTP, los informes del remitente RTCP, los metadatos de seguimiento SDP, los números de secuencia y las marcas de tiempo.

Qué significa SSRC

En RTP, cada fuente de medios tiene un valor SSRC. Una pista de vídeo y una pista de audio suelen tener valores SSRC diferentes. El receptor utiliza SSRC junto con el tipo de carga útil, el número de secuencia, la marca de tiempo y los informes RTCP para mantener la continuidad de la transmisión.

Si el SSRC cambia, un receptor debe decidir si esto es:

Una nueva fuente de sincronización legítima.
Se reinicia el codificador de la cámara.
Una conmutación por error a otro codificador.
Un error de firmware.
Un problema de reescritura de NAT/proxy.
Una nueva transmisión se mezcló incorrectamente en la misma sesión.

Tratar todos los cambios de SSRC como pérdida de paquetes es engañoso.

Síntomas comunes

Un cambio de SSRC puede producir varios síntomas visibles:

El vídeo se congela durante unos segundos.
El decodificador muestra "unidad NAL no válida" o "falta un marco de referencia".
La reproducción continúa pero la latencia aumenta.
El audio y el vídeo se separan.
El cliente registra una pérdida repentina de paquetes.
Picos de fluctuación RTCP.
Los números de secuencia se reinician desde un valor pequeño.
La marca de tiempo RTP salta hacia atrás o hacia adelante.

La pregunta importante es si la identidad de los medios cambió al mismo tiempo que la secuencia y la continuidad de la marca de tiempo.

Reinicio de la cámara o reinicio del codificador

Muchas cámaras IP reinician la canalización de su codificador sin cerrar la conexión TCP RTSP. Es posible que la sesión de control aún parezca viva, pero el RTP cambia debajo de ella.

Evidencia:

Continúa el mismo ID de sesión RTSP.
Cambios en RTP SSRC.
Se reinicia el número de secuencia RTP.
La marca de tiempo RTP se reinicia o salta.
El informe del remitente RTCP cambia la asignación.
El fotograma clave aparece poco después del reinicio o el decodificador espera hasta el siguiente fotograma IDR.

Si la transmisión se recupera después del siguiente fotograma clave, el problema puede ser el reinicio del codificador en lugar de la pérdida de paquetes de red.

Fuentes de medios con carga equilibrada y conmutación por error

Algunos sistemas transmiten transmisiones RTSP a través de una puerta de enlace. Si la puerta de enlace cambia cámaras ascendentes, tuberías de grabación o trabajadores transcodificadores, el receptor puede ver un nuevo SSRC.

Esto puede suceder con:

Retransmisión de NVR.
Puentes de cámara en la nube.
Conmutación por error del proxy RTSP.
Firmware de cámara multicodificador.
Servidores de flujo redundantes.
Equilibradores de carga que no conservan la afinidad de los medios.

Si los cambios de SSRC se correlacionan con la conmutación por error del backend, la solución puede pertenecer a la capa de retransmisión.

Restablecer el número de secuencia

Los números de secuencia RTP son de 16 bits y normalmente aumentan en uno por cada paquete en el mismo flujo. Se puede esperar un reinicio al mismo tiempo que el cambio de SSRC. Un reinicio sin cambio de SSRC es más sospechoso.

Comparaciones útiles:

Antiguo rango de secuencia SSRC.
Nuevo primer número de secuencia del SSRC.
Tipo de carga útil antes y después.
Marca de tiempo antes y después.
Comportamiento del bit marcador cerca del límite.
Si aparece un fotograma clave después del reinicio.

Esta distinción es importante para el SEO porque muchas personas buscan "restablecer el número de secuencia RTP" y asumen la pérdida de paquetes, mientras que la verdadera causa es el reemplazo de la fuente.

Discontinuidad de la marca de tiempo

Las marcas de tiempo RTP siguen el reloj de los medios. Para vídeo, esto suele ser 90 kHz. Si la marca de tiempo retrocede, un receptor puede eliminar fotogramas o reordenarlos incorrectamente. Si salta mucho hacia adelante, el comportamiento del búfer de fluctuación puede cambiar.

Cuando cambia SSRC, la discontinuidad de la marca de tiempo puede ser aceptable si el receptor la trata como una nueva fuente. Cuando SSRC no cambia, la discontinuidad de la marca de tiempo a menudo indica que el reloj del remitente está roto.

RTSP Inspector debe mostrar claramente el límite de la marca de tiempo:

old SSRC: sequence 43120, timestamp 88210000
new SSRC: sequence 210, timestamp 3000

That kind of evidence is more useful than a player screenshot.

RTCP sender report changes

RTCP sender reports map RTP timestamps to wall-clock time. If SSRC changes, the receiver should watch for new RTCP sender reports.

Questions to answer:

Does the new SSRC send RTCP SR?
Does the old SSRC send RTCP BYE?
Does the camera announce source shutdown?
Is jitter calculated per SSRC or across the boundary?
Does packet loss accounting reset correctly?

If a tool merges statistics across SSRC changes, it may show false loss, false jitter, or false bitrate dips.

Decoder behavior

Even when RTP is valid, decoders need a clean frame boundary. For H.264 and H.265, recovery may require SPS/PPS/VPS and an IDR frame.

After an SSRC change, check:

Does the next access unit include a keyframe?
Are SPS and PPS repeated?
Does the SDP still match the actual stream?
Does payload type stay the same?
Does fragmentation restart in the middle of a frame?

If the new source starts with P-frames only, the receiver may show black video until the next keyframe.

Debug checklist

Use this workflow:

Identify all SSRC values per RTP track.
Locate the exact packet where SSRC changes.
Compare sequence numbers before and after.
Compare RTP timestamps before and after.
Check RTCP BYE and sender reports.
Check whether RTSP session ID changed.
Check whether payload type changed.
Look for keyframe or codec config after the boundary.
Separate source restart from network loss.
Export the boundary packets for firmware or gateway debugging.

Final diagnosis

An RTP SSRC change is not automatically a network problem. It can reveal camera encoder restart, RTSP relay failover, timestamp reset, media source replacement, or decoder recovery delay.

RTSP Inspector helps by showing the media evidence that players hide: SSRC, sequence number, timestamp, RTCP behavior, keyframe recovery, and the exact packet where the stream identity changed.

Evidencia reproducible para «Cambio de RTP SSRC a mitad de la transmisión: depuración de reinicios de la cámara, cambios de fuente de transmisión, restablecimientos de secuencia y fallas del decodificador»

La respuesta directa es que una avería de vídeo no se demuestra con una ventana negra ni con un solo código de estado. Un diagnóstico fiable conecta la petición y la respuesta RTSP, el transporte negociado, una sesión válida y después los números de secuencia RTP, las marcas de tiempo y las señales RTCP. Para «Cambio de RTP SSRC a mitad de la transmisión: depuración de reinicios de la cámara, cambios de fuente de transmisión, restablecimientos de secuencia y fallas del decodificador», empieza por la capa más cercana al síntoma visible, pero conserva una cronología común para no mezclar un fallo de control con uno de red o decodificación.

Antes de cambiar la cámara, el firewall o el VMS, crea una prueba base pequeña. Anota la URL RTSP sin contraseña, la hora, la ruta, el transporte solicitado, la respuesta del servidor y el instante del primer paquete multimedia. Prueba UDP y TCP interleaved por separado cuando el equipo ofrezca ambos. No cambies ruta, credenciales y transporte a la vez; si el segundo intento funciona, necesitas saber qué variable produjo la diferencia.

Capa	Evidencia que se debe guardar	Pregunta de decisión
RTSP	método, estado, cabeceras, CSeq y Session	¿El servidor aceptó exactamente la operación?
SDP	control, payload type, clock rate y codec	¿El servidor describió la pista esperada?
Transport	client_port, server_port o interleaved	¿Ambos extremos usan el mismo canal?
RTP	SSRC, secuencia, timestamp y marker	¿Las unidades llegan en un orden explicable?
RTCP	sender report, CNAME y BYE	¿Se pueden relacionar reloj, identidad y final?
Decoder	SPS/PPS/VPS y packetization mode	¿El payload recibido permite iniciar el decoder?

Separa «no llega multimedia» de «llega multimedia que no se puede decodificar». Si no aparece RTP después de SETUP y PLAY correctos, revisa UDP, NAT, firewall y una respuesta Transport distinta de la oferta. RTP con huecos de secuencia prueba pérdida o reordenación. Una secuencia continua sin imagen desplaza la investigación hacia payload type, clock rate, límites de cuadro y parámetros H.264 o H.265. Esta frontera es más útil que el mensaje general del reproductor.

¿Cómo se redacta una respuesta que pueda citarse?

Usa tres frases: última operación correcta, primera evidencia que falla y siguiente prueba que separa dos causas. Ejemplo: «DESCRIBE, SETUP y PLAY terminan correctamente; no llega RTP a los puertos anunciados por el cliente; repetir por TCP interleaved separará el bloqueo UDP de una ruta multimedia incorrecta». No atribuyas el fallo a la cámara o a la red sin una respuesta o un paquete que marque ese límite.

¿Qué hace reproducible el caso?

Guarda OPTIONS, DESCRIBE, SETUP y PLAY, el SDP, la respuesta Transport y el identificador Session saneado. Para RTP registra SSRC, primer y último número de secuencia, clock rate, huecos y duración. Indica si VLC u otro VMS funciona, pero úsalo como comparación controlada, no como prueba de que el cliente exitoso interpreta todas las reglas de forma correcta.

¿Cuándo se investiga el servidor y cuándo el cliente?

Mira el servidor si rechaza un método, entrega un control URL inexistente, responde con un transporte incompatible o cambia SSRC o reloj sin transición. Mira el cliente si reutiliza un nonce caducado, pierde Session, solicita UDP sin abrir los puertos o interpreta cada final NAL como final de access unit. Si el límite está entre ambos, conserva paquete y hora en cada afirmación.

¿Cómo se revisa el informe?

Repite desde una conexión nueva y compara las dos cronologías solo hasta la primera diferencia. Elimina contraseñas y valores Authorization completos. Relaciona cada conclusión con CSeq, secuencia o timestamp. Continúa con la guía RTSP relacionada y usa RTSP Inspector para probar un stream RTSP y recoger evidencia de forma local, sin subir el vídeo de la cámara a un servicio público.