2026-06-02

Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué falla una transmisión de vídeo antes de la reproducción

Cómo diagnosticar transmisiones RTSP con pistas de audio, cargas útiles AAC, secciones de medios SDP desconocidas y fallas de compatibilidad del cliente.

Algunas transmisiones de cámara RTSP fallan no porque el video no esté disponible, sino porque la sesión contiene más de lo que el cliente espera. Una cámara puede anunciar video, audio, metadatos, pistas privadas, audio de canal secundario o secciones de medios específicas del proveedor en SDP. Un consumidor estricto puede rechazar toda la sesión cuando encuentre una pista no compatible.

Búsquedas como "el audio RTSP AAC no funciona", "pista desconocida en SDP", "la transmisión RTSP falla con el audio habilitado" o "la cámara funciona después de deshabilitar el audio" apuntan al mismo límite de diagnóstico: SDP describe la sesión y cada pista anunciada puede afectar la compatibilidad.

SDP puede anunciar más que vídeos

Una respuesta RTSP DESCRIBE puede incluir múltiples secciones multimedia:

m=vídeo
m=audio
pistas de metadatos
pistas de aplicaciones
cargas útiles privadas del proveedor
controlar las URL por pista

Para cada pista, el cliente debe decidir si puede configurarla, ignorarla o fallar. Algunos clientes son tolerantes. Otros son estrictos. Si un motor de retransmisión o un producto de análisis solo espera una pista de vídeo compatible, las secciones SDP desconocidas pueden provocar fallos sorprendentes.

AAC Audio tiene su propio límite de compatibilidad

AAC sobre RTP es bastante común, pero no todos los consumidores de RTSP manejan cada carga de audio de manera limpia. Es posible que SDP deba describir el modo, la configuración, la velocidad del reloj, los canales y el tipo de carga útil. Si esos campos faltan o son inusuales, un cliente puede fallar durante la configuración o más tarde al despaquetear.

Los problemas de audio pueden aparecer como:

la transmisión se abre solo cuando el audio está deshabilitado
Error de análisis SDP
tipo de carga útil no admitida
SETUP falla en la pista de audio
El video funciona en VLC pero falla en una ruta de ingesta más estricta.
La grabadora rechaza la sesión aunque la pista de vídeo sea válida.

El último caso es importante: una pista de audio no compatible puede bloquear el acceso a una pista de vídeo utilizable según el comportamiento del cliente.

Las pistas desconocidas deben informarse, no ocultarse

Si SDP contiene una sección de medios desconocida, una herramienta de diagnóstico debería preservarla. Ocultar pistas no compatibles hace que sea más difícil explicar los fallos de compatibilidad.

La evidencia útil incluye:

sección completa de medios SDP
tipo de carga útil
valor rtpmap
valores fmtp
URL de control de seguimiento
si se intentó SETUP
si la falla ocurrió en la pista de video, audio o metadatos

Esto permite a los ingenieros decidir si desactivar la pista, filtrarla, cambiar el perfil de la cámara o ajustar el soporte posterior.

Deshabilite el audio como prueba, no como diagnóstico

Deshabilitar el audio es una solución común. Puede ser válido, especialmente para flujos de trabajo de análisis que solo necesitan vídeo. Pero debería tratarse como una prueba:

el vídeo y el audio fallan
solo video tiene éxito
SDP cambió después de desactivar el audio
la carga útil o la pista no admitida desaparecieron
La ruta del video RTP se mantuvo igual

Esta comparación demuestra que el error pertenece a la composición de la sesión, no a la accesibilidad básica de la red.

Dónde encaja el inspector RTSP

RTSP Inspector debe mantener visible la estructura de la sesión. Su límite no es la reproducción; Es una explicación protocolaria. Para transmisiones RTSP multipista, debería ayudar responder:

¿Cuántas pistas anunció SDP?
¿Qué pistas fueron compatibles?
¿Qué pista falló en la configuración?
¿Llegó el vídeo RTP?
¿El audio o los metadatos bloquearon al consumidor?
¿La siguiente acción debería ser cambiar el perfil de la cámara o cambiar el analizador posterior?

Cuando la transmisión de una cámara "no funciona", es posible que la pista de video esté bien. La pista no compatible al lado puede ser la verdadera razón por la que falló la sesión.

Evidencia reproducible para «Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué falla una transmisión de vídeo antes de la reproducción»

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 «Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué falla una transmisión de vídeo antes de la reproducción», 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 «Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué falla una transmisión de vídeo antes de la reproducción» es: Cómo diagnosticar transmisiones RTSP con pistas de audio, cargas útiles AAC, secciones de medios SDP desconocidas y fallas de compatibilidad del cliente. 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: Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué falla una transmisión de vídeo

Compruebe «Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué falla una transmisión de vídeo antes de la 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 2: Cómo diagnosticar transmisiones RTSP con pistas de audio, cargas útiles AAC, secciones de

Si «Cómo diagnosticar transmisiones RTSP con pistas de audio, cargas útiles AAC, secciones de medios SDP desconocidas y fallas de compatibilidad del clien» 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 3: SDP puede anunciar más que vídeos

Compruebe «SDP puede anunciar más que vídeos» 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 4: AAC Audio tiene su propio límite de compatibilidad

Si «AAC Audio tiene su propio límite de compatibilidad» 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 5: Las pistas desconocidas deben informarse, no ocultarse

Compruebe «Las pistas desconocidas deben informarse, no ocultarse» 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 6: Deshabilite el audio como prueba, no como diagnóstico

Si «Deshabilite el audio como prueba, no como diagnóstico» 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 7: Dónde encaja el inspector RTSP

Compruebe «Dónde encaja el inspector RTSP» 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 8: Evidencia reproducible para «Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué f

Si «Evidencia reproducible para «Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué falla una transmisión de vídeo antes de la reproducción»» 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 9: ¿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.

Punto de control 10: ¿Qué hace reproducible el caso?

Si «¿Qué hace reproducible el caso?» 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.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Pista de audio RTSP, AAC y pistas SDP desconocidas: por qué falla una transmisión de vídeo antes de la reproducción	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo diagnosticar transmisiones RTSP con pistas de audio, cargas útiles AAC, secciones de medios SDP desconocidas y fall	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
SDP puede anunciar más que vídeos	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
AAC Audio tiene su propio límite de compatibilidad	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Las pistas desconocidas deben informarse, no ocultarse	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Deshabilite el audio como prueba, no como diagnóstico	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: