2026-06-02

Solución de desviación de la marca de tiempo RTSP: discrepancia en la frecuencia del reloj RTP, sincronización de audio/vídeo y errores de sincronización de fotogramas

Se corrigió la desviación de la marca de tiempo RTSP que causaba la pérdida de sincronización de audio/vídeo. Cubre la falta de coincidencia de la frecuencia del reloj RTP, la fluctuación, la sincronización de fotogramas, las marcas de tiempo no monótonas y la inestabilidad de la reproducción de la transmisión de la cámara.

Una transmisión de cámara RTSP puede conectarse exitosamente, autenticarse correctamente, devolver SDP válido, enviar paquetes RTP y aun así comportarse mal. Es posible que el vídeo se retrase poco a poco del tiempo real. El audio y el vídeo pueden no estar sincronizados. Es posible que lleguen fotogramas pero que se reproduzcan de manera desigual. Una grabadora puede crear archivos con una duración extraña. Un reproductor puede mostrar advertencias de fluctuación, tartamudeo, "marca de tiempo no monótona", "DTS no válido", "salto de marca de tiempo RTP" o "desajuste de frecuencia de reloj".

Los usuarios buscan "derivación de la marca de tiempo RTP", "sincronización de audio y video de la cámara RTSP", "velocidad de reloj RTP incorrecta", "marca de tiempo entrecortada de la transmisión RTSP" y "problema de sincronización de fotogramas de la transmisión de la cámara" cuando la conexión de red funciona pero la línea de tiempo de los medios no.

Este es exactamente el tipo de problema en el que una prueba exclusiva para jugadores es demasiado superficial. El reproductor puede ocultar la línea de tiempo del paquete detrás del almacenamiento en búfer y la decodificación. RTSP Inspector es útil porque la temporización RTP es evidencia de protocolo: tipo de carga útil, marca de tiempo RTP, número de secuencia, bit marcador, velocidad de reloj SDP, informes del remitente RTCP, fluctuación y mapeo del reloj de pared, todos son importantes.

Las marcas de tiempo RTP no son marcas de tiempo de reloj de pared.

Una marca de tiempo RTP es un valor de reloj multimedia, no una marca de tiempo Unix. Para vídeo H.264, SDP suele declarar un reloj de 90 kHz:

a=rtpmap:96 H264/90000

90000 / 30 = 3000

Para vídeo de 25 fps, el incremento suele ser 3600:

90000 / 25 = 3600

SDP clock rate is the first clue

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
m=audio 0 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/48000/2

Si el SDP dice que H.264 usa 90000, el cliente debe interpretar las marcas de tiempo RTP del video con ese reloj. Si el SDP falta, está mal formado o es inconsistente con el comportamiento de la carga útil, el cliente puede adivinar incorrectamente.

Los problemas comunes de sincronización del SDP incluyen:

Falta a=rtpmap para el tipo de carga útil dinámica.
Frecuencia de reloj de audio incorrecta.
El tipo de carga útil se reutiliza de manera inconsistente.
El firmware de la cámara declara 90000 pero envía incrementos de marca de tiempo que no coinciden con la velocidad de fotogramas.
La configuración de AAC no coincide con la frecuencia de muestreo real.
Varias pistas utilizan atributos de control confusos o duplicados.

RTSP Inspector debería ayudar a preservar el SDP junto con la evidencia de RTP porque la línea de tiempo de RTP no se puede interpretar correctamente sin ella.

Número de secuencia vs marca de tiempo

Los números de secuencia y las marcas de tiempo de RTP responden a diferentes preguntas.

El número de secuencia ayuda a detectar la pérdida y el pedido de paquetes:

¿Llegó el paquete 1024?
¿Llegó el paquete 1025?
¿Llegó el paquete 1026 antes del 1025?
¿Faltan paquetes?

La marca de tiempo RTP ayuda a interpretar el tiempo de los medios:

¿Qué paquetes pertenecen al mismo cuadro de vídeo?
¿Cuánto tiempo multimedia pasó entre fotogramas?
¿La cámara saltó hacia adelante o hacia atrás?
¿El audio avanza al ritmo esperado?
¿El tiempo de los medios coincide con el del reloj de pared?

Una transmisión puede tener una continuidad de secuencia perfecta y aún tener marcas de tiempo rotas. También puede haber cierta pérdida de paquetes, mientras que las marcas de tiempo permanecen consistentes.

Límites de bits de marcador y fotogramas de vídeo

Para muchas cargas de vídeo RTP, el bit marcador indica un límite de cuadro. Con H.264, varios paquetes RTP pueden transportar fragmentos de un cuadro de vídeo. Comparten la misma marca de tiempo RTP y el bit marcador suele aparecer en el último paquete de la unidad de acceso.

Si las marcas de tiempo cambian con demasiada frecuencia, no con la suficiente frecuencia, o el comportamiento del marcador es inconsistente, la reconstrucción del marco puede volverse inestable.

Los síntomas incluyen:

El vídeo se entrecorta sin pérdida visible de paquetes.
El decodificador recibe tramas incompletas.
La grabadora crea una duración de fotograma incorrecta.
La reproducción se acelera o ralentiza.
Las marcas de tiempo de los fotogramas no son monótonas.

Es por eso que una herramienta de diagnóstico debería mostrar metadatos RTP a nivel de paquete, no solo cuadros decodificados.

Deriva de sincronización de audio/vídeo

La sincronización de audio y video depende de asignar la marca de tiempo RTP de cada pista multimedia a una base de tiempo compartida. Los informes de remitente RTCP se utilizan a menudo para esto. Un informe de remitente puede asignar la marca de tiempo RTP a la hora NTP:

RTCP SR:
NTP timestamp: wall-clock reference
RTP timestamp: media timestamp at that reference

Audio/video drift can happen when:

Timestamp jumps

Look for:

Questions to separate them:

Checklist for RTP timestamp drift

Use this workflow:

What to include in a useful report

Final diagnosis

Evidencia reproducible para «Solución de desviación de la marca de tiempo RTSP: discrepancia en la frecuencia del reloj RTP, sincronización de audio/vídeo y errores de sincronización de fotogramas»

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 «Solución de desviación de la marca de tiempo RTSP: discrepancia en la frecuencia del reloj RTP, sincronización de audio/vídeo y errores de sincronización de fotogramas», 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.

Respuesta directa y límite de aceptación

La respuesta breve a «Solución de desviación de la marca de tiempo RTSP: discrepancia en la frecuencia del reloj RTP, sincronización de audio/vídeo y errores de sincronización de fotogramas» es: Se corrigió la desviación de la marca de tiempo RTSP que causaba la pérdida de sincronización de audio/vídeo. Cubre la falta de coincidencia de la frecuencia del reloj RTP, la fluctuación, la sincronización de fotogramas, las marcas de tiempo no monótonas y la inestabilidad de la reproducción de la transmisión de la cámara. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en RTSP Inspector.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Solución de desviación de la marca de tiempo RTSP: discrepancia en la frecuencia del reloj

Si «Solución de desviación de la marca de tiempo RTSP: discrepancia en la frecuencia del reloj RTP, sincronización de audio/vídeo y errores de sincronizac» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 2: Se corrigió la desviación de la marca de tiempo RTSP que causaba la pérdida de sincronizac

Compruebe «Se corrigió la desviación de la marca de tiempo RTSP que causaba la pérdida de sincronización de audio/vídeo. Cubre la falta de coincidencia de la fre» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 3: Las marcas de tiempo RTP no son marcas de tiempo de reloj de pared.

Si «Las marcas de tiempo RTP no son marcas de tiempo de reloj de pared.» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 4: SDP clock rate is the first clue

Compruebe «SDP clock rate is the first clue» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 5: Número de secuencia vs marca de tiempo

Si «Número de secuencia vs marca de tiempo» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 6: Límites de bits de marcador y fotogramas de vídeo

Compruebe «Límites de bits de marcador y fotogramas de vídeo» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 7: Deriva de sincronización de audio/vídeo

Si «Deriva de sincronización de audio/vídeo» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 8: Timestamp jumps

Compruebe «Timestamp jumps» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 9: Checklist for RTP timestamp drift

Si «Checklist for RTP timestamp drift» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 10: What to include in a useful report

Compruebe «What to include in a useful report» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Solución de desviación de la marca de tiempo RTSP: discrepancia en la frecuencia del reloj RTP, sincronización de audio/	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Se corrigió la desviación de la marca de tiempo RTSP que causaba la pérdida de sincronización de audio/vídeo. Cubre la f	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Las marcas de tiempo RTP no son marcas de tiempo de reloj de pared.	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
SDP clock rate is the first clue	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Número de secuencia vs marca de tiempo	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Límites de bits de marcador y fotogramas de vídeo	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: