Skip to main content
Esta página fue traducida automáticamente. Si encuentra errores o tiene sugerencias, contáctenos.

Descripción general

El stream de video WebSocket del agente LAN incrusta los resultados de detección de IA directamente en el encabezado de encapsulación H.264. Cuando el pipeline de inferencia en la cámara produce una nueva detección, esta se inserta como un campo TLV en el siguiente frame de video saliente del mismo WebSocket — sin un canal de detección separado. Esta guía cubre:
  • El formato de encapsulación TLV y el esquema JSON dentro del campo AI_DETECTIONS
  • La conexión al WebSocket H.264 por LAN en vivo y la lectura tanto de los frames binarios como del mensaje de texto de inicialización
  • El dibujo de cuadros de detección sobre RhombusRealtimePlayer usando un WebSocket paralelo solo de detección
  • Una referencia de parser desde cero para consumidores que no usan React
Si solo necesitas un reproductor, incrusta RhombusRealtimePlayer — maneja la autenticación, la decodificación con WebCodecs y la negociación de resolución. Esta guía es para agregar una capa de superposición de detección encima, o para clientes que no usan el React SDK.

Conexión al stream en tiempo real por LAN

Obtener la URL del WebSocket

Llama a POST /api/camera/getMediaUris y lee:
  • lanLiveH264Uris (array de strings) — URLs de LAN, cuando el cliente y la cámara comparten una red
  • wanLiveH264Uri (string) — URL de WAN, enrutada a través de Rhombus
Para la variante de menor resolución, cambia /ws por /wsl en la ruta.

Autenticar

Ambos modos usan un token de sesión federada generado en tu backend mediante POST /api/org/generateFederatedSessionToken. Nunca pongas tu API key en el código del navegador. El ejemplo completo de backend para generar tokens (Express, FastAPI, Next.js) está en la guía del React SDK — reutilízalo.

Qué envía el servidor

Inmediatamente después de la actualización del WebSocket y antes de cualquier frame binario, el servidor envía un único mensaje de texto que describe el stream:
Lee las dimensiones si tu renderizador necesita la resolución de origen. Los cuadros delimitadores son independientes de la resolución (unidades permyriad), por lo que la mayoría de las superposiciones no lo necesitan. Después del mensaje de inicialización, cada mensaje posterior es un frame binario que contiene el encabezado de encapsulación codificado en TLV seguido de los datos NAL H.264 sin procesar.

Encabezado de encapsulación (formato TLV)

Cada mensaje binario contiene una secuencia de TLVs. Cada TLV usa el mismo formato de cable:

Tipos de TLV

Disposición de cable

El TLV de datos de frame (0x00 o 0x01) es siempre la última entrada — el codificador del agente LAN inserta explícitamente los TLVs de metadatos antes de la entrada de frame. Un parser seguro deja de recorrer los TLVs en cuanto encuentra un tipo de datos de frame.

Análisis del encabezado de encapsulación

Recorre los campos TLV hasta que llegues al tipo 0x00 o 0x01 (la entrada de datos de frame):
El React SDK de Rhombus usa un parser equivalente en parseRhombusH264Binary.ts — la referencia canónica del lado del cliente.

Esquema JSON de detección

AI_DETECTIONS transporta un array JSON de objetos de detección. Los objetos de detección no llevan un timestamp propio — todas las detecciones de un mensaje se analizaron a partir del mismo frame, así que usa el TLV TIMESTAMP (tipo 0x02) del frame envolvente como hora de análisis.

Campos obligatorios

Campos opcionales

Ejemplo

Análisis compatible hacia adelante. Las futuras versiones de firmware agregarán texto de LPR (lp_chars, lp_confidence), esqueletos de pose (pose_permyriad_points — de 38 articulaciones, no el conjunto COCO de 17 articulaciones) y embeddings de reidentificación. Trata todos los campos no reconocidos como opcionales e ignora las claves desconocidas, para que tu cliente siga funcionando cuando esos campos lleguen.

Dibujo de cuadros delimitadores en un canvas

Las coordenadas de los cuadros delimitadores son permyriad (0–10000) e independientes de la resolución. Conviértelas a píxeles usando las dimensiones del canvas:
Para un canvas de 1280×720 y b: [1200, 3400, 4500, 8900], esto produce (x=153.6, y=244.8, w=422.4, h=396.0).

Comportamiento de temporización

  • Las detecciones no están presentes en cada frame. El pipeline de IA analiza un subconjunto de frames (normalmente 2–10 fps). La mayoría de los frames no llevan un TLV AI_DETECTIONS.
  • Las detecciones no llevan un timestamp propio. Alinea cada conjunto de detecciones según el TLV TIMESTAMP (tipo 0x02) del frame envolvente — la marca de tiempo en milisegundos del reloj de pared del servidor que el codificador escribe para ese frame. Como el pipeline de inferencia en la cámara y el codificador se ejecutan de forma independiente, una detección viaja en el frame que salga del codificador a continuación y puede corresponder a un frame capturado un poco antes; el stream no expone ese desfase, así que el TIMESTAMP del frame portador es el punto de referencia a usar, especialmente para VOD o reproducción con búfer.
  • Persiste entre actualizaciones. Para mantener los cuadros visibles entre actualizaciones de detección, conserva el conjunto más reciente y sigue redibujándolo hasta que llegue un conjunto más nuevo o transcurra un TTL. Un TTL de 2 segundos es un valor predeterminado seguro.

Extender RhombusRealtimePlayer con renderizado de detecciones

El RhombusRealtimePlayer del React SDK no expone actualmente las detecciones de IA a la aplicación anfitriona. Hasta que lo haga, el patrón más sencillo es abrir un segundo WebSocket a la misma URL únicamente para leer AI_DETECTIONS, y dibujar el resultado en un <canvas> superpuesto sobre el reproductor.
Un WebSocket paralelo duplica el egreso de esa cámara. Úsalo solo en la página que necesita detecciones y ciérralo al desmontar.
Resuelve detectionWsUrl en tu backend de la misma forma que lo hace el SDK: llama a getMediaUris, elige el wanLiveH264Uri o la entrada de LAN adecuada, luego agrega ?x-auth-scheme=federated-token&x-auth-ft=<TOKEN> (tanto WAN como LAN) antes de pasar la URL al navegador.

Referencia de parser desde cero

Para clientes que no usan React (una página web pura, Node, Electron), el mismo parser impulsa una superposición mínima. Decodificar el H.264 en sí requiere WebCodecs (navegador) o ffmpeg/libav (Node) y queda fuera del alcance, pero leer las detecciones del WebSocket solo necesita el parser anterior:

Streams HTTP vs WebSocket

La variante de stream HTTP video/h264 elimina por completo el encabezado de encapsulación y entrega únicamente datos NAL H.264 sin procesar. Las detecciones viajan solo por el transporte WebSocket. Usa las URLs de WebSocket de getMediaUris (lanLiveH264Uris / wanLiveH264Uri) para cualquier flujo que necesite detecciones.

Solución de problemas

Los cuadros aparecen en la ubicación incorrecta Las coordenadas de bbox son permyriad (0–10000), no píxeles y no 0–1. Asegúrate de que el renderizador divida entre 10000 antes de multiplicar por las dimensiones del canvas. Los cuadros parecen retrasarse respecto al video Las detecciones no tienen un timestamp propio — alinea cada conjunto según el TLV TIMESTAMP (tipo 0x02) del frame envolvente. La detección viaja en el frame que salga del codificador a continuación, por lo que puede ir un poco por detrás del frame analizado; el TIMESTAMP del frame portador es el único punto de referencia de temporización que ofrece el stream. Los cuadros desaparecen durante unos cientos de milisegundos y luego reaparecen El pipeline de IA produce resultados a 2–10 fps y las detecciones no viajan en cada frame de video. Conserva el conjunto de detección más reciente con un TTL (p. ej. 2 s) para que la superposición se mantenga estable entre actualizaciones. El receptor solo recibe frames binarios; nunca ve el mensaje de inicialización Confirma que tu manejador de WebSocket acepte frames de texto antes que los frames binarios. La inicialización es un único mensaje de texto que se envía una vez por conexión. La autenticación en LAN falla localmente La autenticación en LAN se agrega a la URL del WebSocket como parámetros de consulta (igual que en WAN), por lo que funciona desde cualquier origen, incluido localhost. Si LAN falla, la causa habitual es la accesibilidad de red: el navegador debe alcanzar directamente el host de LAN de la cámara (se aplican reglas de enrutamiento, firewall y de contenido mixto HTTPS-vs-HTTP). Si el host de LAN no es accesible, conéctate por WAN en su lugar, o usa un proxy a través de tu backend.

Próximos pasos

React SDK

Componentes RhombusRealtimePlayer y RhombusBufferedPlayer listos para usar.

Streaming de video

HLS, streams compartidos, miniaturas y captura de frames.
Última modificación el 8 de julio de 2026