Encabezado de rango RTSP y npt=now: depuración de errores de hora de inicio, reanudación y búsqueda de cámara de reproducción en vivo

RTSP PLAY parece simple hasta que una cámara, NVR o servidor de medios interpreta la hora de inicio de manera diferente al cliente. Una transmisión en vivo puede comenzar tarde, reiniciarse desde un punto inesperado, fallar después de una pausa/reanudación o devolver un error cuando el cliente envía un encabezado "Rango". Los usuarios buscan "Rango RTSP npt ahora", "hora de inicio de REPRODUCCIÓN RTSP", "inicio incorrecto de transmisión en vivo RTSP", "la búsqueda RTSP no funciona" y "la cámara reanuda la transmisión RTSP" cuando la transmisión se conecta pero el tiempo de reproducción se comporta incorrectamente.

El encabezado "Rango" es una instrucción de temporización de la capa de control. No es lo mismo que la marca de tiempo RTP, la hora del reloj de pared o la marca de tiempo del archivo de la grabadora. RTSP Inspector es útil porque este problema se encuentra en la secuencia del método RTSP y debe compararse con el tiempo de medios RTP/RTCP después de "PLAY".

¿Qué significa rango en RTSP?

Durante PLAY, un cliente puede enviar:

PLAY rtsp://camera/stream RTSP/1.0
Session: 12345678
Range: npt=now-

For a live stream, npt=now- usually means "start playing from the current live point." Some clients omit the Range header. Some send npt=0.000-. Some NVRs use clock-based ranges for recorded playback.

Different RTSP servers vary in how strictly they interpret these values.

Live stream vs recorded stream

Live streams and recorded streams have different expectations:

• Live camera stream: current live media point.
• NVR playback: requested recording time range.
• Media file: offset into stored content.
• Replay server: session-specific timeline.

A Range value that is valid for a file may be invalid for a live camera. A Range value that works for one NVR may not work for another vendor.

Common symptoms

Range-related problems include:

• PLAY fails only when Range is present.
• Stream starts but with long delay.
• Resume after pause fails.
• Client receives old buffered video.
• NVR playback starts at wrong time.
• RTP timestamps jump after resume.
• Camera ignores Range but returns 200 OK.
• Server returns invalid Range response.

The player may show this as buffering or black video, but the root evidence is in PLAY.

Server response matters

After PLAY, the server may return a Range header:

RTSP/1.0 200 OK
Range: npt=0.000-
RTP-Info: url=...;seq=...;rtptime=...

RTP-Info puede asignar la respuesta de control a la secuencia RTP inicial y los valores de marca de tiempo. Si falta RTP-Info, es incorrecta o inconsistente, los clientes pueden tener dificultades para alinear la sincronización de los medios.

Inspeccionar:

• Rango enviado por el cliente.
• Rango devuelto por el servidor.
• Secuencia RTP-Info y rtptime.
• Primera secuencia RTP después de PLAY.
• Primera marca de tiempo RTP después de PLAY.

Pausar y reanudar

Algunas cámaras admiten "PAUSA"; otros no lo soportan bien para transmisiones en vivo. Un cliente puede pausar y luego enviar "PLAY" con un valor de Rango que el servidor trata como una búsqueda. El servidor puede rechazarlo o reiniciar la transmisión.

Si el currículum se interrumpe, compare el primer "PLAY" con el currículum "PLAY".

Lista de verificación de depuración

Utilice este proceso:

1. Capture la solicitud y respuesta de PLAY.
2. Compruebe si el cliente envía "Rango".
3. Registre el valor exacto: npt=now-, npt=0-, rango de reloj o ausente.
4. Verifique el rango de respuesta del servidor y la información RTP.
5. Compare la primera secuencia/marca de tiempo RTP después de JUGAR.
6. Prueba con y sin Rango si el cliente lo permite.
7. Pruebe la transmisión en vivo y la reproducción grabada por separado.
8. Verifique la secuencia del método de pausa/reanudación.
9. Evite culpar al RTP hasta que se comprenda el tiempo de "PLAY".
10. Preservar todo el flujo de control RTSP para el diagnóstico del proveedor.

Diagnóstico final

Los problemas de rango RTSP son problemas de sincronización del control de reproducción. La transmisión puede autenticarse y configurarse correctamente, pero "PLAY" aún puede comenzar desde el punto incorrecto o fallar porque el servidor no acepta el rango solicitado.

RTSP Inspector ayuda mostrando el rango, la información RTP y los primeros paquetes RTP juntos, de modo que los problemas de tiempo de inicio de la reproducción en vivo se puedan diagnosticar a partir de la evidencia del protocolo.

<!-- rtsp-localized-evidence-foundation-v1:start -->

Evidencia reproducible para «Encabezado de rango RTSP y npt=now: depuración de errores de hora de inicio, reanudación y búsqueda de cámara de reproducción en vivo»

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 «Encabezado de rango RTSP y npt=now: depuración de errores de hora de inicio, reanudación y búsqueda de cámara de reproducción en vivo», 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.

<!-- rtsp-localized-evidence-foundation-v1:end --><!-- rtsp-localized-layer-verdicts-v1:start -->

De la observación a un veredicto por capas

En «Encabezado de rango RTSP y npt=now: depuración de errores de hora de inicio, reanudación y búsqueda de cámara de reproducción en vivo», escribe primero lo observado y después la interpretación. Una observación puede localizarse en la captura: estado RTSP asociado a CSeq, valor SDP, respuesta Transport, hueco entre secuencias, cambio de SSRC o diferencia entre RTP timestamp y RTCP sender report. «El servidor es lento» o «el codec es incompatible» sigue siendo una hipótesis hasta que una evidencia concreta la explique mejor que las alternativas.

Divide el flujo en fronteras. Primero se abre TCP. Después se aceptan OPTIONS o DESCRIBE. El SDP debe describir una pista utilizable, control URL, payload type y clock rate. SETUP necesita una respuesta Transport compatible y PLAY una Session válida. Solo entonces se evalúan llegada RTP, orden, tiempo y preparación del decoder. Detente en la primera frontera sin prueba de éxito; no permitas que datos posteriores oculten una ausencia anterior.

Mantén fuente e intervalo constantes en comparaciones. Para UDP frente a TCP interleaved usa la misma ruta y credenciales. Para main stream frente a sub stream conserva cliente y transporte. Al comparar VLC con un VMS, registra métodos, cabeceras y URL reales; una diferencia de control URL, Authorization, Session o keepalive puede explicar el resultado mejor que el nombre del programa.

Matriz de descarte

Empieza con dos hipótesis. Si no llega multimedia, UDP puede estar bloqueado o el servidor puede enviar a otros puertos. TCP interleaved prueba la primera; comparar oferta y respuesta Transport, IP y puertos prueba la segunda. Para imagen dañada, la secuencia RTP separa pérdida de paquetes de inicialización incompleta, mientras que SPS/PPS/VPS antes del primer frame prueba la hipótesis del codec.

Para cada hipótesis anota evidencia a favor y evidencia que podría refutarla. Una afirmación que ninguna captura puede negar es demasiado amplia. «NAT elimina UDP» queda refutado si RTP llega al puerto del cliente. «Faltan parámetros H.264» queda refutado al ver SPS y PPS válidos antes de IDR. Así el informe conserva prioridad y no se convierte en una lista desordenada.

Interpretar el tiempo sin excederse

RTSP CSeq ordena transacciones, RTP sequence ordena paquetes, RTP timestamp expresa tiempo de muestreo y el reloj de captura expresa llegada al punto observado. No son el mismo reloj. Variación de llegada no demuestra drift; un salto timestamp no demuestra pérdida sin secuencia. Para sincronizar audio y vídeo, los RTCP sender reports relacionan relojes RTP distintos con una referencia común.

Paquete final de aceptación

Cierra el caso cuando el arreglo se repita desde una conexión nueva con un solo cambio documentado. El informe debe indicar entradas, última frontera correcta, primera evidencia fallida, cambio, resultado y pruebas pendientes. Adjunta un fragmento pequeño del transcript o estadísticas relevantes. Oculta secretos, pero conserva CSeq, Session saneada, SSRC e intervalo.

Usa la solución de problemas RTSP para reconstruir el flujo y los informes de RTSP Inspector para entregar la frontera al equipo de cámara, red o VMS.

<!-- rtsp-localized-layer-verdicts-v1:end -->