2026-06-02

La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demuestra la diferencia

Una guía de diagnóstico para casos de cámaras IP en los que la transmisión secundaria RTSP funciona pero la transmisión principal falla, se congela, devuelve 404 o no se puede decodificar.

Una consulta de búsqueda de cámara IP muy común es "La transmisión principal RTSP no funciona pero la transmisión secundaria sí". El síntoma es lo suficientemente específico como para ser útil. Si la transmisión secundaria funciona, se puede acceder a la cámara, las credenciales probablemente sean correctas, el servicio RTSP está habilitado y se puede acceder al menos a un perfil de video. El problema ya no es "RTSP está roto". El problema es la diferencia entre los perfiles de transmisión.

La transmisión principal y la transmisión secundaria generalmente difieren en resolución, tasa de bits, códec, intervalo GOP, tamaño de carga útil y, a veces, incluso ruta URL. Una transmisión secundaria puede ser H.264 con baja resolución, mientras que la transmisión principal es H.265, 4K, con alta tasa de bits o restringida a menos sesiones simultáneas. Un NVR puede exponer diferentes caminos desde la propia cámara. ONVIF puede devolver una URL en vivo de baja calidad, mientras que la URL de grabación o el perfil principal requieren una ruta separada.

La pregunta de diagnóstico útil es: ¿qué prueba la subcorriente de trabajo y qué no prueba?

Lo que demuestra una subcorriente funcional

Si la subtransmisión se puede abrir a través de RTSP, normalmente puedes decir:

la dirección IP de la cámara es accesible
el puerto RTSP está abierto
la autenticación funciona para al menos una secuencia
el cliente puede analizar respuestas RTSP básicas
DESCRIBE, SETUP y PLAY pueden funcionar correctamente para al menos un perfil
La entrega RTP es posible para al menos una pista multimedia

Esa es una evidencia valiosa. Limita la búsqueda. No debe seguir depurando la accesibilidad básica de la red después de este punto a menos que la transmisión principal utilice un host, puerto, modo de transporte o ruta NVR diferente.

Lo que una subcorriente funcional no prueba

Una subcorriente en funcionamiento no prueba:

la ruta URL de la transmisión principal es correcta
la transmisión principal está habilitada
el códec de transmisión principal es compatible
la tasa de bits de la transmisión principal puede cruzar la red
la corriente principal está disponible para múltiples clientes
la corriente principal envía evidencia SPS/PPS o VPS/SPS/PPS lista para decodificar
el NVR expone la corriente principal de la cámara a través del mismo camino

Es por eso que "VLC puede abrir la transmisión secundaria" no es suficiente para un VMS, un sistema de análisis o una canalización de retransmisión que necesita la transmisión principal.

Verifique la ruta URL antes del códec

Muchas familias de cámaras utilizan diferentes patrones de ruta para las transmisiones principales y secundarias. Algunos usan "perfil1" y "perfil2". Algunos usan /Streaming/Channels/101 y /Streaming/Channels/102. Algunos usan "principal", "sub", "video1", "video2" o nombres de acceso específicos del proveedor. Algunos NVR exponen los canales de forma diferente a las URL directas de las cámaras.

Si la transmisión principal devuelve "404 No encontrado", inspeccione:

URI de solicitud exacta enviada en DESCRIBE
si la ruta URL coincide con el modelo del proveedor
número de canal
número de flujo
token de perfil descubierto por ONVIF
si la transmisión está habilitada en la interfaz de usuario web de la cámara
si la URL apunta a la IP de la cámara o a la IP del NVR

No trate un 404 como pérdida de paquete. RTP aún no ha comenzado.

Verifique el códec y la tasa de bits después de que la ruta sea válida

Si la transmisión principal devuelve SDP e inicia RTP pero aún no muestra video, pase a códec y evidencia multimedia.

Las fallas de la corriente principal a menudo provienen de:

H.265 seleccionado mientras que el consumidor espera H.264
faltan pruebas de H.264 SPS/PPS o H.265 VPS/SPS/PPS
intervalo de fotograma clave muy largo
Pérdida alta de velocidad de bits a través de Wi-Fi o enlace ascendente débil
Fragmentación y pérdida de paquetes en movimiento.
Perfil o nivel del decodificador no soportado por el sistema aguas abajo.

En esta etapa, el informe debe incluir SDP, tipo de carga útil, continuidad de la secuencia RTP, evidencia de la unidad NAL del códec y si se alcanzó el primer límite de decodificación.

Límites de simultaneidad y comportamiento de NVR

Algunas versiones económicas de DVR, NVR o firmware de cámara limitan el acceso a la transmisión principal. La transmisión secundaria puede permanecer disponible mientras la transmisión principal ya se consume en la pantalla local, la grabación, la aplicación del proveedor u otro cliente. Esto puede parecer un problema de URL incluso cuando la ruta es correcta.

Comprobaciones útiles:

desconectar a otros espectadores
Pruebe la IP de la cámara directa frente a la IP del NVR
comparar la transmisión principal desde la interfaz de usuario web de la cámara
menor tasa de bits o resolución de la transmisión principal
cambiar el códec de transmisión principal de H.265 a H.264
Pruebe RTSP sobre TCP intercalado y UDP por separado

Si reducir la tasa de bits soluciona el problema, la falla original puede ser la capacidad de transporte en lugar de la sintaxis de la URL.

Cómo debería encuadrar el inspector RTSP este caso

RTSP Inspector es más fuerte cuando explica el límite:

la ruta de control de la subcorriente es exitosa
La ruta de control de la corriente principal falla con el código de estado
La transmisión principal devuelve SDP pero no RTP
La corriente principal RTP llega con pérdida de paquetes
Faltan metadatos del códec de transmisión principal o no son compatibles
La corriente principal es H.265, mientras que el consumidor necesita H.264.

Ésa es la diferencia entre "la corriente principal rota" y un informe de soporte útil. La siguiente acción correcta podría ser la búsqueda de URL del proveedor, la configuración del perfil de transmisión, el cambio de códec, la reducción de la tasa de bits, la actualización del firmware o la reparación de la ruta de red.

Si su búsqueda exacta es "La subtransmisión RTSP funciona pero la transmisión principal no", comience comparando los métodos RTSP, SDP, códec, transporte y concurrencia. La subcorriente de trabajo no es el final del diagnóstico. Es la muestra de control.

Evidencia reproducible para «La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demuestra la diferencia»

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 «La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demuestra la diferencia», 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 «La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demuestra la diferencia» es: Una guía de diagnóstico para casos de cámaras IP en los que la transmisión secundaria RTSP funciona pero la transmisión principal falla, se congela, devuelve 404 o no se puede decodificar. 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: La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demues

Si «La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demuestra la diferencia» 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: Una guía de diagnóstico para casos de cámaras IP en los que la transmisión secundaria RTSP

Compruebe «Una guía de diagnóstico para casos de cámaras IP en los que la transmisión secundaria RTSP funciona pero la transmisión principal falla, se congela, d» 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: Lo que demuestra una subcorriente funcional

Si «Lo que demuestra una subcorriente funcional» 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: Lo que una subcorriente funcional no prueba

Compruebe «Lo que una subcorriente funcional no prueba» 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: Verifique la ruta URL antes del códec

Si «Verifique la ruta URL antes del códec» 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: Verifique el códec y la tasa de bits después de que la ruta sea válida

Compruebe «Verifique el códec y la tasa de bits después de que la ruta sea válida» 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: Límites de simultaneidad y comportamiento de NVR

Si «Límites de simultaneidad y comportamiento de NVR» 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: Cómo debería encuadrar el inspector RTSP este caso

Compruebe «Cómo debería encuadrar el inspector RTSP este caso» 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: Evidencia reproducible para «La transmisión principal RTSP no funciona pero la transmisión

Si «Evidencia reproducible para «La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demuestra la diferencia»» 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: ¿Cómo se redacta una respuesta que pueda citarse?

Compruebe «¿Cómo se redacta una respuesta que pueda citarse?» 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
La transmisión principal RTSP no funciona pero la transmisión secundaria sí: lo que demuestra la diferencia	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Una guía de diagnóstico para casos de cámaras IP en los que la transmisión secundaria RTSP funciona pero la transmisión	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Lo que demuestra una subcorriente funcional	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Lo que una subcorriente funcional no prueba	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Verifique la ruta URL antes del códec	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Verifique el códec y la tasa de bits después de que la ruta sea válida	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: