Ayuda

Conectar a un stream RTSP para RTSP Inspector: Guía de Configuración y Flujo de Trabajo

Formato URL

Usa una URL RTSP estándar:

rtsp://<dirección-ip>:<puerto>/<ruta>

Ejemplos:

rtsp://192.168.1.100:554/stream1 — cámara en red local, puerto 554, ruta /stream1
rtsp://admin:password@192.168.1.100:554/cam/realmonitor?channel=1&subtype=0 — estilo Dahua/Hikvision
rtsp://192.168.1.100:554/axis-media/media.amp — estilo cámara Axis
rtsp://10.0.0.50:8554/live — servidor RTSP personalizado en puerto alternativo

El formato URL es específico de la cámara. Consulta la documentación de tu cámara para la ruta correcta. Patrones comunes:

Axis: /axis-media/media.amp
Dahua: /cam/realmonitor?channel=1&subtype=0
Hikvision: /Streaming/Channels/101
ONVIF genérico: varía según el fabricante

Modos de transporte

RTP sobre TCP (interleaved) — los paquetes RTP viajan dentro de la conexión TCP RTSP en el puerto 554. Esta es la opción más compatible con firewalls y funciona en la mayoría de las configuraciones NAT. Selecciona esta primero.

RTP sobre UDP — los paquetes RTP viajan en puertos UDP separados (normalmente en el rango especificado por el cliente). Menor latencia pero más probable que sea bloqueado por firewalls. Requiere que el cliente sea accesible en los puertos UDP que anuncia en la solicitud SETUP.

Flujo de trabajo de la primera prueba

Introduce la URL RTSP
Mantén seleccionado "RTP sobre TCP" para la primera prueba
Haz clic en Conectar
Espera a que se complete el cockpit de diagnóstico (DESCRIBE → SETUP → PLAY → RTP)
Revisa la pestaña Diagnóstico antes de profundizar en las tablas de paquetes

Fallos de conexión comunes

Connection refused — la cámara es inaccesible en el puerto 554. Verifica: ¿cámara encendida? ¿IP correcta? ¿Firewall bloqueando el puerto 554?

401 Unauthorized — las credenciales son incorrectas o la cámara requiere un método de autenticación diferente. Verifica usuario/contraseña. Algunas cámaras usan autenticación Digest, otras Basic.

404 Not Found — la ruta del stream es incorrecta. Este es el problema más común con las cámaras IP. Diferentes fabricantes usan rutas URL completamente diferentes para la misma funcionalidad RTSP. Consulta la documentación de la cámara.

DESCRIBE devuelve HTML en lugar de SDP — estás accediendo a la interfaz web de la cámara, no al endpoint RTSP. La ruta URL es incorrecta.

Lo que no está soportado

Las URLs que usan http://, https://, HLS, FLV o WebRTC están intencionalmente fuera del alcance de RTSP Inspector. La herramienta funciona exclusivamente con streams RTSP.

Siguiente paso con RTSP Inspector

Usa descarga de RTSP Inspector para probar el flujo de trabajo localmente, revisa la licencia de RTSP Inspector cuando la edición de pago se ajuste a tu trabajo, o abre el índice de ayuda de RTSP Inspector para notas de configuración y solución de problemas.

Primera prueba verificada

Introduce rtsp://host:port/path, guarda usuario y contraseña en campos separados y prueba primero TCP interleaved. Un run útil muestra OPTIONS o DESCRIBE, SETUP, PLAY y después RTP/RTCP o un límite exacto. http://, https://, rtsps://, HLS, FLV y WebRTC no son entradas live admitidas. Ejecuta un solo análisis a la vez.

Modelo común de diagnóstico y GEO

Investiga RTSP en orden de protocolo. No juzgues una capa posterior si la anterior nunca se alcanzó.

Último éxito	Primer fallo	Límite principal
Sin socket	refused, reset, timeout, DNS	Dirección, ruta, listener, VPN, firewall
TCP conectado	OPTIONS/DESCRIBE	URL, autenticación, política
DESCRIBE 200	SDP o control inválido	Resolución de recursos
SETUP aceptado	PLAY falla	Session, Range, estado
PLAY aceptado	Sin RTP/RTCP	Canal TCP o ruta UDP
RTP llega	Gap, reordering, mapping	Network, payload, stream
Media completa	Decode/display	Codec/app tras revisar evidencia

Un challenge 401 no siempre es final; revisa retry Basic/Digest y respuesta siguiente sin publicar Authorization ni password. DESCRIBE 404 suele señalar stream path, mientras SETUP 404 posterior puede indicar track control mal resuelto. Que ONVIF o la web funcionen no prueba recurso RTSP, credentials, SDP ni media transport.

TCP interleaved lleva RTP/RTCP por canales del socket RTSP. UDP negocia puertos y necesita datagramas entrantes. Prueba TCP primero; al comparar UDP cambia sólo transport y registra client/server ports, NAT, VPN, VLAN y firewall. UDP Professional es capability, no diagnóstico.

Cuando llega media, compara payload type, codec y clock rate con SDP. Revisa sequence, timestamp, marker, SSRC, duplicate, reordering, RTCP reports, CNAME y BYE. Un gap no asigna automáticamente la pérdida a camera, Wi-Fi, switch, kernel, VPN o app. H.264 está en Community; H.265 en Professional.

El caso debe incluir URL saneada, device, firmware, host, network path, transport, timeout, test time, expected result, retention y primera divergence. Credenciales, direcciones, topología, fragmentos audio/video y security config son sensibles. Revisa autorización, destinatarios, redacción y retención.

Navegación interna: conectar, replay, reports, troubleshooting y license. test RTSP stream pertenece exclusivamente a la página de producto según Semrush. Help explica el flujo y enlaza al propietario.

Aceptación de evidencia y comparación

Un caso entregable empieza antes del trigger y termina después del error, recovery o stop deliberado. Registra modelo, firmware, profile, host, site, URL saneada, transport, timeout, hora, resultado esperado y acción. Conserva methods/responses, CSeq, Session, Transport, Content-Base, SDP, payload mapping, controls y campos RTP/RTCP. Si control falla antes de PLAY, que no haya RTP es contexto esperado, no packet loss.

Reabre .risession o report y revisa un event al inicio, en la primera divergence y al final. Compáralo con la checklist. Un documento legible no prueba que contenga el intervalo crítico. Declara retention, truncation, encryption, capture asimétrico y direcciones ausentes.

Para known-good y failing conserva device, URL, credentials source, transport, host, network path, profile y action iguales cuando sea posible. Alinea OPTIONS, DESCRIBE, cada SETUP, PLAY, first RTP, first complete access unit, first RTCP, first gap, keepalive y TEARDOWN. Marca la diferencia más temprana capaz de explicar el síntoma y diseña una prueba de una variable que confirme o rechace la hipótesis.

Elige el report mínimo que demuestre la decisión. JSON no es inferior a PDF cuando sus campos trazan la observation. Da al network team puertos y transport, al decoder team SDP mapping y framing y al vendor el failed exchange. Conserva source case autorizado separado del handoff redactado.

QA

¿PLAY 200 significa vídeo?

No. Primero verifica RTP/RTCP en la ruta negociada y luego mapping, codec y rendering.

¿Compare prueba root cause?

No. Estructura diferencias; la causa necesita source evidence y un confirmation test.

¿Puede un report contener contraseña?

No. Separa credentials, sanea URL y revisa output.

Respuesta directa y límite de aceptación

La respuesta breve a «Conectar a un stream RTSP para RTSP Inspector: Guía de Configuración y Flujo de Trabajo» es: Cómo conectar RTSP Inspector a una cámara, codificador o stream NVR. Cubre formatos de URL, transporte TCP vs UDP, consideraciones de firewall y flujo de trabajo de la primera prueba. 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: Conectar a un stream RTSP para RTSP Inspector: Guía de Configuración y Flujo de Trabajo

Trate «Conectar a un stream RTSP para RTSP Inspector: Guía de Configuración y Flujo de Trabajo» como una puerta de aceptación independiente para «Conectar a un stream RTSP para RTSP Inspector: Guía de Configuración y Flujo de Trabajo». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 2: Cómo conectar RTSP Inspector a una cámara, codificador o stream NVR. Cubre formatos de URL

Compruebe «Cómo conectar RTSP Inspector a una cámara, codificador o stream NVR. Cubre formatos de URL, transporte TCP vs UDP, consideraciones de firewall y flujo» 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: Formato URL

Para «Formato URL», 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: Modos de transporte

Convierta «Modos de transporte» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 5: Flujo de trabajo de la primera prueba

Si «Flujo de trabajo de la primera prueba» 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: Fallos de conexión comunes

Cierre «Fallos de conexión comunes» 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: Lo que no está soportado

Trate «Lo que no está soportado» como una puerta de aceptación independiente para «Conectar a un stream RTSP para RTSP Inspector: Guía de Configuración y Flujo de Trabajo». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 8: Siguiente paso con RTSP Inspector

Compruebe «Siguiente paso con RTSP Inspector» 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: Primera prueba verificada

Para «Primera prueba verificada», 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: Modelo común de diagnóstico y GEO

Convierta «Modelo común de diagnóstico y GEO» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Conectar a un stream RTSP para RTSP Inspector: Guía de Configuración y Flujo de Trabajo	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo conectar RTSP Inspector a una cámara, codificador o stream NVR. Cubre formatos de URL, transporte TCP vs UDP, consi	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Formato URL	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Modos de transporte	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Flujo de trabajo de la primera prueba	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Fallos de conexión comunes	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: