2026-06-03

Depuración de encabezado de velocidad y escala RTSP: avance rápido, cámara lenta, reproducción con truco, reproducción NVR y velocidad no compatible

Cómo depurar encabezados de escala y velocidad RTSP, avance rápido, cámara lenta, reproducción NVR, interacciones de rango, velocidad de reproducción no compatible y comportamiento de cámara de reproducción trucada.

La visualización en vivo RTSP ya es complicada, pero la reproducción grabada agrega otra capa: "control de velocidad. Los usuarios buscan "encabezado de escala RTSP", "encabezado de velocidad RTSP", "avance rápido RTSP no funciona", "reproducción de trucos NVR RTSP", "velocidad de reproducción RTSP no compatible" y "reproducción de cámara en cámara lenta RTSP" cuando la reproducción normal funciona pero falla el avance rápido, la reproducción hacia atrás o la reproducción lenta." RTSP Inspector es útil porque el truco es un problema del plano de control. El cliente envía "PLAY" con "Rango", "Escala" o "Velocidad", y el servidor puede aceptar, bloquear, ignorar o rechazar la solicitud.

Escala vs reproducción normal

La reproducción normal suele verse así:

PLAY rtsp://nvr/recording RTSP/1.0
Range: npt=0-

Trick play may add:

Scale: 2.0

u otra tarifa dependiendo del soporte del servidor. Algunos servidores solo admiten valores seleccionados. Algunos ignoran los valores no admitidos. Algunos devuelven un encabezado de respuesta con la escala aceptada real.

Síntomas comunes

Los fallos aparecen como:

El botón de avance rápido no hace nada.
La transmisión salta al momento equivocado.
La reproducción se congela después de la solicitud de escala.
El servidor devuelve "Método 455 no válido en este estado".
El servidor devuelve "457 rango no válido".
El servidor devuelve "501 no implementado".
El servidor acepta PLAY pero mantiene la velocidad normal.
NVR envía solo fotogramas clave durante el avance rápido.
El audio desaparece durante la reproducción de trucos.

Estos no son el mismo fracaso. Los encabezados exactos de solicitud y respuesta son importantes.

Interacción de rango

La reproducción RTSP grabada a menudo combina "Rango" con "Escala".

Ejemplos:

Range: npt=120-
Scale: 4.0

or:

Range: clock=20260603T010000Z-
Scale: 0.5

Si el cliente envía un formato de hora que el servidor no admite, la falla puede parecer un problema de velocidad aunque el problema real sea "Rango".

El servidor limita o reescribe la velocidad

Algunos NVR solo aceptan valores discretos:

0,5
1.0
2.0
4.0
8.0
modos de solo fotogramas clave

Si el cliente solicita "3.0", el servidor puede elegir "2.0" o "4.0". Un buen seguimiento compara la tasa solicitada con los encabezados de respuesta aceptados y el tiempo real de RTP.

Comportamiento del audio durante la reproducción con trucos

Muchos servidores eliminan el audio durante la reproducción hacia adelante o hacia atrás. Esto es de esperarse porque el audio no se puede decodificar de manera significativa a alta velocidad.

Evidencia:

La CONFIGURACIÓN de vídeo permanece activa.
El RTP de audio se detiene después de avanzar rápidamente la reproducción.
El servidor envía RTCP BYE para audio.
La pista de audio se reanuda cuando Scale vuelve a "1.0".
SDP todavía anuncia audio, pero el modo de reproducción lo suprime.

No diagnostique esto como pérdida de paquetes hasta que se verifique el estado de control RTSP.

Avance rápido solo de fotogramas clave

Los NVR suelen enviar sólo fotogramas clave durante la reproducción a alta velocidad. Eso reduce el ancho de banda y el costo de decodificación, pero cambia la cadencia de RTP.

Síntomas:

El vídeo parece nervioso.
La tasa de bits de RTP cae.
Los marcos son escasos.
Cambios de cadencia del bit marcador.
Las marcas de tiempo saltan en grandes intervalos.

Esto puede ser un comportamiento correcto de juego de trucos, no corrupción de transmisión.

Reproducción inversa no compatible

La reproducción inversa no es universalmente compatible. Algunos servidores rechazan los valores de escala negativos. Otros emulan la reproducción inversa saltando entre fotogramas clave.

Términos de búsqueda:

"No se admite la reproducción inversa RTSP"
"Escala negativa RTSP"
"NVR rebobinado RTSP"
"Reproducción de trucos RTSP solo fotogramas clave"

La pregunta de diagnóstico es si el servidor rechazó explícitamente la tarifa solicitada o cambió silenciosamente el comportamiento.

Lista de verificación de depuración

Utilice este proceso:

Capture el PLAY en funcionamiento a velocidad normal.
Capture el JUEGO con truco.
Compare los encabezados "Rango", "Escala" y "Velocidad".
Verifique el código de estado de respuesta.
Verifique los encabezados de respuesta para conocer la tarifa aceptada.
Compara la cadencia de la marca de tiempo RTP.
Compruebe si el audio se detiene intencionalmente.
Busque comportamiento de video de solo fotogramas clave.
Pruebe las velocidades discretas admitidas.
Conserve los encabezados de solicitud y respuesta para el soporte del proveedor de NVR.

Diagnóstico final

Las fallas de avance rápido, cámara lenta y reproducción trucada de RTSP deben diagnosticarse a partir de los encabezados de control y la sincronización de los medios en conjunto. El servidor puede rechazar, bloquear, ignorar o admitir parcialmente "Escala" y "Velocidad".

RTSP Inspector ayuda a comprobar si el problema es una velocidad de reproducción no compatible, un formato de rango, una política de reproducción trucada de NVR, supresión de audio o interpretación del cliente.

Evidencia reproducible para «Depuración de encabezado de velocidad y escala RTSP: avance rápido, cámara lenta, reproducción con truco, reproducción NVR y velocidad no compatible»

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 «Depuración de encabezado de velocidad y escala RTSP: avance rápido, cámara lenta, reproducción con truco, reproducción NVR y velocidad no compatible», 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 «Depuración de encabezado de velocidad y escala RTSP: avance rápido, cámara lenta, reproducción con truco, reproducción NVR y velocidad no compatible» es: Cómo depurar encabezados de escala y velocidad RTSP, avance rápido, cámara lenta, reproducción NVR, interacciones de rango, velocidad de reproducción no compatible y comportamiento de cámara de reproducción trucada. 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: Depuración de encabezado de velocidad y escala RTSP: avance rápido, cámara lenta, reproduc

Si «Depuración de encabezado de velocidad y escala RTSP: avance rápido, cámara lenta, reproducción con truco, reproducción NVR y velocidad no compatible» 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: Cómo depurar encabezados de escala y velocidad RTSP, avance rápido, cámara lenta, reproduc

Compruebe «Cómo depurar encabezados de escala y velocidad RTSP, avance rápido, cámara lenta, reproducción NVR, interacciones de rango, velocidad de reproducción » 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: Escala vs reproducción normal

Si «Escala vs reproducción normal» 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: Síntomas comunes

Compruebe «Síntomas comunes» 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: Interacción de rango

Si «Interacción de rango» 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: El servidor limita o reescribe la velocidad

Compruebe «El servidor limita o reescribe la velocidad» 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: Comportamiento del audio durante la reproducción con trucos

Si «Comportamiento del audio durante la reproducción con trucos» 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: Avance rápido solo de fotogramas clave

Compruebe «Avance rápido solo de fotogramas clave» 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: Reproducción inversa no compatible

Si «Reproducción inversa no compatible» 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: Lista de verificación de depuración

Compruebe «Lista de verificación de depuración» 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
Depuración de encabezado de velocidad y escala RTSP: avance rápido, cámara lenta, reproducción con truco, reproducción N	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo depurar encabezados de escala y velocidad RTSP, avance rápido, cámara lenta, reproducción NVR, interacciones de ran	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Escala vs reproducción normal	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Síntomas comunes	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Interacción de rango	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
El servidor limita o reescribe la velocidad	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: