La transmisión H.265 RTSP no funciona: cuándo volver a cambiar la cámara a H.264

Por qué las transmisiones de cámara H.265 RTSP a menudo fallan en navegadores, NVR, sistemas de análisis y retransmisiones, y cómo demostrar si la alternativa H.264 es la solución correcta.

H265, H264, RTSP, HEVC, tipo de transmisión no compatible

"La transmisión H.265 RTSP no funciona" es una de las búsquedas de solución de problemas de cámara con mayor intención porque la transmisión a menudo funciona en un lugar y falla en otro. VLC puede reproducirlo. Una aplicación móvil puede mostrarlo. Un navegador, NVR, canal de análisis, integración de Home Assistant, puente WebRTC o retransmisión pueden fallar con "tipo de transmisión no compatible", "códec no coincidente", "no se pudo escribir el encabezado", "no hay video" o un control giratorio de carga permanente.

El fallo no siempre es la sesión RTSP. H.265, también llamado HEVC, es un límite de soporte de códec. RTSP puede entregarlo correctamente mientras el sistema receptor aún no puede decodificarlo, empaquetarlo, mostrarlo o retransmitirlo.

El éxito de RTSP no significa compatibilidad con códecs

Un cliente RTSP puede completar exitosamente:

  • OPCIONES
  • DESCRIBIR
  • CONFIGURACIÓN
  • REPRODUCIR
  • Entrega RTP

y todavía no puedo mostrar el video. Si SDP anuncia que llegan paquetes H.265 y RTP, el transporte puede estar bien. Es posible que el producto descendente simplemente no admita H.265 en esa ruta.

Esto es importante porque los usuarios suelen describir el problema como "RTSP no funciona". El mejor diagnóstico es "El transporte RTSP funciona, pero el códec anunciado no es compatible o no está listo para decodificar para este consumidor".

Por qué H.265 falla con más frecuencia que H.264

H.265 es eficiente, especialmente para cámaras de alta resolución, pero el soporte es desigual. Muchas rutas de navegador no manejan bien H.265 sin formato. Algunos NVR pueden grabar H.265 pero no obtener una vista previa constante. Algunas canalizaciones de análisis requieren H.264 porque así lo requieren la aceleración de hardware, la extracción de cuadros o la salida de contenedores. Algunos restreamers necesitan transcodificación o configuración especial.

Modos de falla comunes:

  • la vista previa del navegador no se carga
  • La transmisión secundaria de baja resolución funciona pero la transmisión principal falla
  • La transmisión principal es H.265 mientras que la transmisión secundaria es H.264.
  • NVR graba pero la visualización en vivo falla
  • La salida RTMP/FLV rechaza HEVC
  • El puente WebRTC no puede coincidir con los códecs
  • El servicio de análisis solo acepta H.264.

Estos son límites de compatibilidad de productos, no pruebas de que la cámara esté desconectada.

Inspeccione el SDP antes de cambiar la configuración

Antes de cambiar la configuración de la cámara, inspeccione el SDP:

  • ¿a=rtpmap anuncia H265, H264 u otro códec?
  • ¿La corriente principal difiere de la corriente secundaria?
  • ¿Son visibles los parámetros H.265 VPS/SPS/PPS?
  • ¿El tipo de carga útil se mantiene constante en RTP?
  • ¿Llega el RTP después de "PLAY"?
  • ¿La falla es antes o después de la entrega del medio?

Si SDP dice H.265 y la plataforma de destino espera H.264, la siguiente acción no es la depuración del firewall. Se trata de selección de perfil de transmisión, cambio de códec o transcodificación.

La corriente principal versus la corriente secundaria es a menudo la pista

Muchas cámaras exponen:

  • Transmisión principal: alta resolución, H.265
  • subtransmisión: baja resolución, H.264

Esto explica por qué la corriente secundaria funciona mientras que la corriente principal falla. La subcorriente demuestra la accesibilidad y las credenciales de RTSP. No prueba que el consumidor admita el códec principal.

Un buen informe compara:

  • corriente principal SDP
  • subcorriente SDP
  • nombres de códecs
  • resolution
  • bitrate
  • Continuidad RTP
  • preparación del decodificador

Si solo falla H.265, la evidencia apunta hacia la compatibilidad con códec o paquetización H.265 en lugar de la sintaxis de URL RTSP.

Cuando el respaldo H.264 es la solución práctica

Cambiar el perfil de la cámara a H.264 suele ser la solución más rápida cuando:

  • el producto de destino no es compatible con H.265
  • la vista previa en vivo está basada en el navegador
  • Se requiere retransmisión a RTMP/FLV
  • La canalización de análisis requiere marcos H.264
  • La ruta de decodificación del hardware es desconocida.
  • el caso de soporte necesita una amplia compatibilidad

H.265 aún puede resultar útil para la eficiencia de grabación o almacenamiento. La arquitectura práctica puede utilizar H.264 para ingesta/detección en vivo y H.265 para grabación de cámara local cuando sea compatible.

Dónde encaja el inspector RTSP

RTSP Inspector no intenta transcodificar ni reproducir todas las transmisiones. Su trabajo es probar el contrato de transmisión:

  • El control RTSP fue exitoso
  • SDP anuncia H.265 o H.264
  • RTP llegó o no llegó
  • La evidencia del parámetro códec estaba presente o faltaba.
  • Es probable que el fallo descendente sea compatible con el códec, pérdida de paquetes o discrepancia de metadatos.

Para búsquedas como "La transmisión H.265 RTSP no funciona", "cámara de tipo de transmisión no compatible" o "H.265 funciona en VLC pero no en NVR", esta evidencia evita la depuración desperdiciada. La solución puede ser el respaldo H.264, no otro reproductor.