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
Cómo solucionar problemas de encabezados de rango RTSP, npt=now, reproducción de cámara en vivo, comportamiento de reanudación, hora de inicio incorrecta, búsqueda no válida, solicitudes de PLAY y tiempo de respuesta del servidor.
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:
PLAYfails 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:
- Capture la solicitud y respuesta de
PLAY. - Compruebe si el cliente envía "Rango".
- Registre el valor exacto:
npt=now-,npt=0-, rango de reloj o ausente. - Verifique el rango de respuesta del servidor y la información RTP.
- Compare la primera secuencia/marca de tiempo RTP después de JUGAR.
- Prueba con y sin Rango si el cliente lo permite.
- Pruebe la transmisión en vivo y la reproducción grabada por separado.
- Verifique la secuencia del método de pausa/reanudación.
- Evite culpar al RTP hasta que se comprenda el tiempo de "PLAY".
- 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 --><!-- multilingual-blog-closeout:start -->Respuesta directa y límite de aceptación
La respuesta breve a «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» es: Cómo solucionar problemas de encabezados de rango RTSP, npt=now, reproducción de cámara en vivo, comportamiento de reanudación, hora de inicio incorrecta, búsqueda no válida, solicitudes de PLAY y tiempo de respuesta del servidor. 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: Encabezado de rango RTSP y npt=now: depuración de errores de hora de inicio, reanudación y
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», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.
Punto de control 2: Cómo solucionar problemas de encabezados de rango RTSP, npt=now, reproducción de cámara en
Cierre «Cómo solucionar problemas de encabezados de rango RTSP, npt=now, reproducción de cámara en vivo, comportamiento de reanudación, hora de inicio incorre» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.
Punto de control 3: ¿Qué significa rango en RTSP?
Para «¿Qué significa rango en RTSP?», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.
Punto de control 4: Live stream vs recorded stream
Cierre «Live stream vs recorded stream» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.
Punto de control 5: Common symptoms
Para «Common symptoms», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.
Punto de control 6: Server response matters
Cierre «Server response matters» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.
Punto de control 7: Pausar y reanudar
Para «Pausar y reanudar», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.
Punto de control 8: Lista de verificación de depuración
Cierre «Lista de verificación de depuración» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.
Punto de control 9: Diagnóstico final
Para «Diagnóstico final», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.
Punto de control 10: Evidencia reproducible para «Encabezado de rango RTSP y npt=now: depuración de errores de
Cierre «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 reproduc» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.
Matriz de aceptación
| Punto | Evidencia que conservar | Condición de aprobado |
|---|---|---|
| Encabezado de rango RTSP y npt=now: depuración de errores de hora de inicio, reanudación y búsqueda de cámara de reprodu | Estado inicial, una acción y estado resultante | Otra persona reproduce el resultado declarado |
| Cómo solucionar problemas de encabezados de rango RTSP, npt=now, reproducción de cámara en vivo, comportamiento de reanu | Estado inicial, una acción y estado resultante | Otra persona reproduce el resultado declarado |
| ¿Qué significa rango en RTSP? | Estado inicial, una acción y estado resultante | Otra persona reproduce el resultado declarado |
| Live stream vs recorded stream | Estado inicial, una acción y estado resultante | Otra persona reproduce el resultado declarado |
| Common symptoms | Estado inicial, una acción y estado resultante | Otra persona reproduce el resultado declarado |
| Server response matters | 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:
- Sesión RTSP 454 no encontrada: por qué falla la CONFIGURACIÓN o la REPRODUCCIÓN después de que se inicia la conexión de una cámara
- La transmisión H.265 RTSP no funciona: cuándo volver a cambiar la cámara a H.264
- Solución de solicitud incorrecta RTSP 400: DESCRIBE fallida, URL de cámara mal formada y errores de encabezado