Solutions · Cámaras IA
Enviar una línea de producto de cámara IA.
Un OS de cámara conectada para dispositivos de borde AI-first. La cámara, la GPU y la NPU comparten memoria — sin copia de píxel por la CPU. Declare el pipeline en TOML; entregue un modelo ONNX o TFLite. Hasta ~100 TOPS en el nivel de clase IA.
Tres formatos de producto
Un runtime. Tres formatos de despliegue.
La misma plataforma de vídeo MOS4 se entrega en tres formatos de producto con nombre. Las seis funciones siguientes se ejecutan en todos los formatos — capturar, grabar, transmitir, recuperar, despertar, IA en la nube.
caja de cámara OEM · instalación fija · óptica única
AI Cam · caja OEM
Cámara mono-óptica de instalación fija con inferencia IA en el dispositivo. Inspección industrial, perímetro, antirrobo en retail, visión del operador sobre máquinas pesadas. Marca del OEM, se ejecuta sobre la plataforma MOS4.
embarcada · doble óptica · ADAS + DMS
Dashcam · embarcada
Dashcam embarcada de doble óptica con asistencia al conductor (ADAS), monitorización del conductor (DMS) y anonimización GDPR en vivo. Despliegues en producción en vehículos de alto rendimiento, camiones, vehículos comerciales ligeros y flotas especiales.
flota · 3–5 cámaras · visión del operador
Red multicámara de flota
Arreglos de tres a cinco cámaras para reparto, operaciones en tierra y visión del operador en off-highway. Los frames pasan directamente de las cámaras a la inferencia IA y a la grabación sin copia por la CPU. Las mismas seis funciones que los formatos mono-cámara, distribuidas por todas las ópticas.
¿Busca el catálogo de casos de uso IA (DMS, ADAS, seguridad en obra y de activos)? Vea Casos de uso IA. Los análisis del pipeline en profundidad (extracción de ROI, anonimización GDPR en vivo) viven en AI Vision. ¿Busca la escala de silicon y los SKU de hardware? Vea hardware y munic.io.
Mapa de funciones
Elija la tarea. Salte a su sección.
Conectar cualquier cámara
Cinco transportes — MIPI-CSI, GMSL2, USB UVC, RTSP/ONVIF, WebRTC — detrás de un único servicio de control de captura. Dos familias de SoC. Hot-plug. Backend seleccionado en tiempo de ejecución.
Grabar por evento
Almacenamiento rotativo con protección de clip por evento — los segmentos marcados nunca son eliminados por la política de retención. Cero escrituras en flash durante la grabación normal. La anonimización GDPR en vivo se ejecuta dentro del pipeline de captura.
Transmitir en vivo
WebRTC (compatible con navegador), RTSP / RTSPS y SRT para baja latencia de larga distancia sobre celular con pérdidas. Reproducción compatible con navegador. La señalización de sesión la gestiona la plataforma — sin código de señalización que escribir.
Recuperar un clip
Siete operaciones de servicio cubren el ciclo de vida completo del medio almacenado. Extracción de clip por copia de flujo — sin decodificación, sin recodificación. Carga SFTP con anclaje de clave de servidor y recorte de carga útil antes de la transferencia.
Despertar por evento
Siete fuentes de despertar — Encendido, Alarma, RTC, trama CAN, Movimiento, Módem, Perturbación. Tiempo hasta listo inferior a cinco segundos — suficientemente rápido para alcanzar un vehículo en fuga.
Ejecutar IA sobre los bytes
Clasificación NPU en el dispositivo hoy; IA en la nube sobre clips subidos fusionada con el flujo de eventos del ciclo de vida — comportamiento del conductor, DTC, posición OBD, pose GNSS. Conforme al GDPR por difuminado en tiempo de captura.
Cómo encaja
Un pipeline, seis funciones.
La cámara produce frames zero-copy en el bus de frames; el bus distribuye al codificador, NPU y stream; el codificador alimenta el índice dashcam, que alimenta la carga SFTP, que alimenta la IA en la nube; la IA en la nube también recibe detecciones NPU.
flowchart LR C[Camera<br/>MIPI · GMSL · UVC · RTSP · WebRTC] F[Frame bus<br/>shared-memory · 1:N fanout] E[Encoder<br/>H.264 segments] N[NPU<br/>on-device triage] S[Stream<br/>WebRTC · RTSP · SRT] D[Dashcam index<br/>SQLite · zero flash writes] U[SFTP upload<br/>host-key pinned] X[Cloud AI<br/>per-clip + lifecycle merge] C --> F --> E --> D --> U --> X F --> N --> X F --> S
Multicámara
De una a ocho cámaras de fábrica.
Cinco transportes detrás de una sola API de servicio. Dos niveles de hardware. De una a ocho cámaras por dispositivo se soportan en el runtime entregado; configuraciones mayores están disponibles bajo estudio. Los frames pasan por el pipeline en memoria compartida — todas las fuentes convergen al mismo formato, así que los consumidores aguas abajo (inferencia IA, codificador, stream) no necesitan negociación por fuente.
Grabación y stream simultáneos
Muchas plataformas de cámara obligan a elegir entre grabar en local y emitir o subir clips antiguos. MOS4 se diseñó para ambas cosas a la vez: codificación en vivo al segment sink flash-aware, stream RTSP/WebRTC y carga de clips históricos se ejecutan sobre el mismo plano de frames en memoria compartida, sin duplicar buffers.
Almacenamiento con wear-leveling
El segment sink es flash-aware: las escrituras se reparten entre bloques para alargar la resistencia en SKUs premium de exposición larga. Las políticas de retención, los clips protegidos y la cola de carga en la nube comparten la misma contabilidad de presupuesto de desgaste.
| Transporte | Backend de SoC | Notas |
|---|---|---|
| MIPI-CSI | clase IA / clase compute (libcamera) | MIPI nativo; sin puente externo |
| GMSL2 | clase IA (puente serializador) | Ruta de puente serializador |
| USB UVC | Ambas | Driver V4L2 UVC estándar |
| Ethernet RTSP / ONVIF | Ambas | Cámaras de red; RTSPS sobre TLS |
| WebRTC (WHEP) | Ambas | Señalización compatible con navegador |
Múltiples sensores alimentan sus backends por plataforma; los backends convergen en un elemento tee con el contrato de bus de frames zero-copy; el tee distribuye al codificador, NPU, GPU ROI shader y pose tracker.
flowchart LR S1[Sensor 1] --> B1[Backend<br/>per platform] S2[Sensor 2] --> B2[Backend] S3[Sensor N] --> B3[Backend] B1 --> T[Frame bus<br/>shared-memory · 1:N fanout] B2 --> T B3 --> T T --> E[Encoder] T --> N[NPU] T --> G[GPU crop/resize] T --> V[Pose tracker]
mos-camera-capture Pipeline GStreamer de extremo a extremo en cinco transportes y dos familias de SoC. Backend seleccionado en tiempo de ejecución mediante sondeo del device tree.
NV12 dmabuf entry
Cada backend normaliza a video/x-raw(memory:DMABuf), format=NV12. El mapeado
de píxeles por CPU es una violación de spec en builds de producción.
mos-frame Fanout SHM entre procesos vía dmabuf fd de Linux sobre SCM_RIGHTS. Política de descarte LATEST-N por suscriptor — un consumidor lento nunca detiene al productor.
CaptureControlService ListDevices · ConfigureStream · StartCapture · StopCapture · GetStatus · ResetCapture — una superficie para cada plataforma.
Grabar por evento
Grabe lo que importa. Conserve lo que marca.
Los segmentos rotativos rotan por presupuesto de almacenamiento. Un flag de evento convierte un segmento en un clip protegido — nunca eliminado por la política de retención. La anonimización GDPR vive dentro del pipeline de captura, antes de que ningún frame llegue al codificador.
El pipeline de captura alimenta el segment sink flash-aware; cada segmento cerrado dispara un evento SegmentClosed hacia el índice SQLite; el aplicador de retención comprueba el flag de protegido y elimina los segmentos no protegidos más antiguos por encima del presupuesto; los flags de evento llaman al método de servicio Protect para marcar segmentos como seguros.
flowchart LR
C[Capture pipeline<br/>encode · parse · mux] --> S[Segment sink<br/>flash-aware]
S --> X[SegmentClosed event]
X --> I[(SQLite segment index<br/>in-memory + snapshots)]
I --> R{Retention check}
R -->|protected| K[Keep]
R -->|unprotected + over budget| D[Delete oldest]
E[Event flag<br/>driver behaviour · DTC · ...] --> P[Protect service method]
P --> I | Parámetro | Por defecto | Notas |
|---|---|---|
| segment_seconds | configurable | Duración del segmento; limitada por el GOP y el lote de escritura en almacenamiento. |
| budget_bytes | 10 GiB | El aplicador de retención elimina los segmentos no protegidos más antiguos por encima de este umbral. |
| gop_seconds | configurable | Afecta al margen del borde del clip en ExtractClip (~1–2 s). |
| anonymisation.enabled | false | Difuminado GDPR en vivo (pixelación en el pipeline). Requiere reinicio para alternar. |
| event_flag | 0 | Flag por segmento; proteger mediante el método de servicio Protect para saltar la retención. |
mos-camera-capture Etapa de codificador de segmentos y de anonimización GDPR — el pipeline GStreamer desde el sensor hasta el segment sink flash-aware, incluida la etapa de pixelación GPU antes del codificador.
mos-dashcam Índice de segmentos (SQLite en memoria), aplicador de retención y método de servicio Protect — el ciclo de vida completo del medio almacenado sin una sola escritura en flash durante la grabación normal.
flash-aware segment sink Renombrado atómico al cierre del segmento — límite de segmento a prueba de pérdida de alimentación. Sin segmentos parciales en el índice tras un apagado inesperado.
mp4mux + h264parse + hw-encoder
Pipeline de codificador seleccionado en tiempo de ejecución — codificador H.264 hardware
en silicon de clase IA, codificador V4L2 H.264 en la otra variante. h264parse
normaliza el bytestream; mp4mux hace el mux a MP4.
Transmitir en vivo
Transmita en vivo a un navegador, un reproductor o un relay en la nube.
Tres rutas en vivo — WebRTC (WHEP compatible con navegador), RTSP / RTSPS y SRT. SRT para baja latencia de larga distancia sobre celular con pérdidas. El micro service gestiona el establecimiento de la sesión; la señalización es transparente para la integración.
La cámara alimenta el codificador H.264; el codificador distribuye a un servidor RTSP (rtsps:// con TLS), un endpoint WHEP y un listener SRT; RTSP alimenta reproductores VLC/ffmpeg, WHEP alimenta un navegador y SRT alimenta un relay en la nube.
flowchart LR C[Camera] --> E[Encoder<br/>H.264] E --> R[RTSP server<br/>rtsps:// · TLS] E --> W["WHEP endpoint<br/>http(s)://.../whep"] E --> S[SRT listener] R --> P1[Player<br/>VLC · ffmpeg] W --> P2[Browser] S --> P3[Cloud relay]
| Protocolo | URI | Elemento | Uso |
|---|---|---|---|
| WebRTC (WHEP) | http(s)://…/whep | whepsrc | Reproducción en navegador; vista embebida en la interfaz de flota |
| WebRTC (señalización WS) | ws(s)://… | webrtcsrc | Servidor de señalización personalizado |
| RTSP | rtsp://… | rtspsrc | VLC · ffmpeg · ingesta NVR |
| RTSPS (RTSP + TLS) | rtsps://… | rtspsrc protocols=tcp+srtp | CA bundle validado por TLS para producción |
| SRT | srt://… | srtsink / srtsrc | Baja latencia de larga distancia sobre celular con pérdidas |
whepsrc / webrtcsrc Elementos fuente WebRTC — WHEP offer/answer sobre HTTP, señalización WebSocket, recolección ICE, handshake DTLS. Usted aporta la URI; el elemento negocia la sesión.
rtspsrc
Fuente RTSP y RTSPS — rtsp:// plano o rtsps:// validado por TLS
con protocols=tcp+srtp. CA bundle anclado en producción; en desarrollo se
puede ajustar tls-validation-flags=0.
SRT plumbing
Listener SRT vía srtsink / srtsrc — recuperación de paquetes sobre
celular con pérdidas sin bloqueo en cabeza por TCP. Larga distancia hasta un relay en la nube
sin código de integración del lado del relay.
ICE / DTLS session establishment Ciclo de vida completo de sesión WebRTC — recolección de candidatos, traversal STUN/TURN, acuerdo de claves DTLS-SRTP. El micro service expone el flujo RTP una vez la sesión está en vivo; la integración no toca el handshake.
TLS validation for rtsps://
Validación de cadena de certificados X.509, anclaje del CA bundle y derivación de claves
SRTP — todo dentro de rtspsrc. Sin plumbing OpenSSL en la capa de
integración.
Recuperar un clip
Extraiga un clip bajo demanda. Envíelo a su nube.
Siete operaciones de servicio cubren el ciclo de vida del medio almacenado. Extracción de clip por copia de flujo — sin decodificación, sin recodificación, margen de borde de ~1–2 s. Carga SFTP con anclaje de clave de servidor, protección contra path traversal y recorte de carga útil previo a la carga.
GetSegments consulta el índice de segmentos por óptica y rango temporal; ExtractClip realiza una extracción por copia de flujo con margen de ~1–2 s; Upload envía por SFTP con anclaje de clave de host; la carga útil se recorta (átomos redundantes eliminados, offsets de chunk parcheados) antes de la transferencia. Snapshot (keyframe a JPEG ~50 ms) y Protect/Unprotect se muestran como rutas laterales con línea discontinua.
flowchart LR G[GetSegments<br/>by lens + time range] --> X[ExtractClip<br/>no decode · ~1–2 s edge slop] X --> U[Upload<br/>SFTP · host-key pinned] U --> M[Trim payload<br/>no re-encode] S[Snapshot<br/>keyframe → JPEG ~50 ms] -.-> X P[Protect / Unprotect] -.-> G
| Operación | Entrada | Salida |
|---|---|---|
| GetSegments | lens, start_ts, end_ts | lista de SegmentRow |
| ExtractClip | segment_id, start_offset, end_offset | ruta del clip en disco |
| Snapshot | segment_id, keyframe_offset | ruta JPEG |
| Protect | segment_id | — (idempotente) |
| Unprotect | segment_id | — (idempotente) |
| Remove | segment_id | — (elimina fichero + fila) |
| Upload | paths, destination_uri, options | flujo de estado de carga |
mos-dashcam Índice de segmentos (SQLite, en memoria con snapshots), aplicador de retención y las siete operaciones de servicio — GetSegments, ExtractClip, Snapshot, Protect, Unprotect, Remove, Upload. Listo para producción en rutas de grabación internas.
splitmuxsrc ! qtmux ! filesink
Pipeline GStreamer solo de mux para ExtractClip — splitmuxsrc lee el segmento fuente;
qtmux remuxa el flujo; filesink escribe el clip de salida. Sin decodificación,
sin recodificación, sin ida y vuelta de píxeles.
russh-sftp ring backend
Transporte de carga SFTP — russh-sftp con backend ring, anclaje de clave de host,
protección contra path traversal y sustitución de URL por token de contexto. La integración
aporta una URI; el micro service gestiona el handshake SSH y la transferencia del flujo.
mp4-reduce
Elimina los átomos free y skip del contenedor MP4 y luego parchea
las tablas de offsets de chunk stco / co64 para mantener el fichero
válido. Reduce la carga útil de subida sin recodificar un solo frame.
dashcam-controller
Integración con dashcam externa de marca blanca sobre Wi-Fi HTTP y notificación TCP. Cola
de peticiones pendientes con TTL para gestionar cortes de conectividad. Distinto de mos-dashcam — este micro service controla una unidad hardware externa, no el pipeline
de grabación interno de la caja MOS4.
mos-dashcam vs dashcam-controller
mos-dashcam es el grabador interno: se ejecuta en la caja MOS4, posee el FIFO de segmentos y expone las siete operaciones de servicio documentadas arriba. dashcam-controller controla una unidad externa de dashcam de marca blanca sobre Wi-Fi HTTP y notificación TCP — hardware separado, ciclo de vida separado, mismo vehículo. Ambos pueden ejecutarse simultáneamente; no comparten estado.
Despertar por evento
Despertar por impacto. Despertar por trama CAN. Despertar por comando de la nube.
Siete fuentes de despertar cubren el ciclo de vida de un vehículo aparcado o en suspensión. El tiempo hasta listo es inferior a cinco segundos — suficientemente rápido para alcanzar a un vehículo que acaba de empezar a moverse.
Siete fuentes de despertar — Encendido, Alarma, RTC, trama CAN, Movimiento, Módem, Perturbación — todas alimentan al gestor de alimentación, que lleva la caja a estado listo en menos de cinco segundos.
flowchart LR IG[Ignition<br/>vehicle ignition signal] --> PM[Power manager] AL[Alarm<br/>external alarm input] --> PM RT[RTC<br/>scheduled wall-clock / relative timer] --> PM CA[CAN frame<br/>CAN ID match] --> PM MV[Movement<br/>accelerometer threshold] --> PM MO[Modem<br/>cloud-issued remote wake] --> PM DI[Disturbance<br/>G-sensor impact threshold] --> PM PM --> BR[Box ready<br/>< 5 s]
| Fuente | Disparador | Uso | Tiempo hasta listo |
|---|---|---|---|
| Encendido | Señal de encendido del vehículo | Caja de flota estándar | < 5 s |
| Alarma | Entrada de alarma externa | Antirrobo / botón de pánico | < 5 s |
| RTC | Wall-clock programado o temporizador relativo | Carga periódica de salud / fin de jornada | < 5 s |
| Trama CAN | Coincidencia de CAN ID | Despertar por señal específica — fallo de mazo / apertura de puerta | < 5 s |
| Movimiento | Umbral del acelerómetro | El vehículo se mueve mientras está aparcado → despierta para grabar | < 5 s |
| Módem | Despertar remoto emitido por la nube | El operador despierta para stream en vivo / extracción de clip | < 5 s |
| Perturbación | Umbral de impacto del sensor G | Captura de evento de colisión / intrusión | < 5 s |
configure_wake_events Bitmask de fuentes de despertar del gestor de alimentación — configure cuáles de las siete fuentes están activas para el siguiente ciclo de suspensión. Una llamada; el micro servicio posee las escrituras en registros hardware y el arbitraje entre fuentes.
set_rtc_wake_time Planificador de despertar por RTC — establezca un timestamp wall-clock o un offset relativo para el siguiente despertar programado. Se utiliza para carga periódica de salud, reporte de fin de jornada o cualquier ciclo de reanudación dirigido por tiempo.
get_wake_reason / clear_wake_reason Lectura y limpieza del motivo de despertar — llame una vez tras la reanudación para leer el bitmask que identifica la fuente disparadora, luego limpie antes de la siguiente suspensión. El gestor de alimentación posee el registro de motivo y distingue arranque-vs-despertar automáticamente.
boot-vs-wake discrimination El gestor de alimentación distingue un arranque en frío de un despertar desde suspensión al inicio. El código de integración ve un bitmask de motivo de despertar limpio — sin inspección de registros hardware crudos.
request_reboot_on_idle / request_shutdown_on_idle Hooks de anulación al próximo idle — programe un reinicio o apagado al final de la ventana activa actual sin interrumpir la grabación o la carga en curso. El micro service espera la condición de idle antes de ejecutar.
IA en la nube
NPU en el dispositivo hoy. IA en la nube sobre los bytes que sube.
El triaje de IA en el dispositivo se ejecuta antes de que un byte salga de la caja — los frames se recortan y analizan en la NPU. Un producto de nube de Munic ejecuta después IA más pesada por clip sobre los segmentos subidos y la fusiona con el flujo de eventos del ciclo de vida — comportamiento del conductor, códigos de fallo (DTC), posición OBD-II, pose GNSS. El clip ya es conforme al GDPR cuando la nube lo recibe.
La captura con difuminado GDPR en vivo alimenta el triaje NPU en el dispositivo y el segmento del grabador. El segmento se sube vía SFTP como bytes conformes al GDPR hacia la IA en la nube. Comportamiento del conductor, DTC/posición OBD y pose GNSS alimentan el flujo de eventos del ciclo de vida, que se fusiona con la inferencia por clip de la IA en la nube y sale al panel de flota.
flowchart TD CAP[Capture<br/>GDPR live blur at capture time] --> NPU[NPU triage<br/>GPU crop + on-device inference] CAP --> REC[Recorder segment<br/>anonymised clip] REC --> UPL[SFTP upload<br/>GDPR-clean bytes] UPL --> CAI[Cloud AI<br/>per-clip inference] DRV[Driver behaviour] --> LS[Lifecycle event stream] OBD[DTC / OBD position] --> LS GNS[GNSS pose] --> LS LS --> CAI CAI --> DSH[Fleet dashboard]
El triaje en el dispositivo se ejecuta antes de que un byte salga de la caja — la extracción de región de interés más la inferencia NPU descartan los frames irrelevantes. Lo que llega a la nube ya está anonimizado y ya está filtrado. La IA en la nube ejecuta modelos más pesados por clip y se fusiona con el flujo de eventos del ciclo de vida de AI Funnel para correlación de comportamiento del conductor e incidentes a escala de flota.
mos-roi-shader Extracción de ROI por Vulkan con transferencia dmabuf-a-NPU zero-copy en silicon de clase IA compatible — sin copias de píxel por CPU en el camino caliente de IA. Las regiones de interés se extraen y entregan a la NPU sin salir del dominio de memoria del acelerador.
mos-ai-runtime Inferencia NPU .tflite en silicon de clase IA — ejecución concurrente multi-modelo en distintas slices de NPU, gestionada por el micro service. Aporte su fichero de modelo .tflite; el runtime gestiona la planificación, la memoria y la entrega de resultados.
AI Funnel Reentrenamiento en la nube, cuantización y entrega OTA del modelo — gestionado por el pipeline AI Funnel. Los modelos reentrenados llegan al dispositivo sin un ciclo de actualización de firmware. No se requiere código de integración para cablear el bucle de feedback.
lifecycle event correlation A cada evento del ciclo de vida se le adjunta un flag temporalmente fiable — comportamiento del conductor, códigos de fallo (DTC), posición OBD-II, pose GNSS. La IA en la nube utiliza el flag para rechazar coincidencias de timestamp ambiguas antes de fusionar con los resultados de inferencia del clip. La postura GDPR está documentada en /es/platform/compliance.
Límite de alcance
Un producto específico de nube de Munic proporciona la inferencia por clip y la fusión del ciclo de vida descritas en esta sección. El nombre del producto, los precios y la arquitectura de nube están fuera del alcance de esta página — esa conversación arranca con ingeniería. Use el CTA de abajo para conectar.
Catálogo de casos de uso IA
DMS, ADAS y seguridad de flota — el catálogo completo.
Monitorización del conductor, asistencia a la conducción, seguridad en obra y seguridad de activos — cada una un modelo embebido fusionado con la telemetría del vehículo en directo. Traiga su propio modelo o haga entrenar uno a partir de su material.
Ver el catálogo completo de casos de uso IA →Preguntas frecuentes
Preguntas habituales
-
¿El stack de vídeo funciona sobre hardware de clase módem?
La captura y la grabación dashcam se entregan en dispositivos de clase compute. La inferencia NPU (crop GPU, runtime de IA en el dispositivo) requiere silicon de clase IA — no hay alternativa por CPU en producción.
-
¿Dónde se realiza la anonimización GDPR?
Dentro del pipeline de captura, antes de que ningún frame llegue al codificador, al runtime de IA o a cualquier consumidor. Los segmentos grabados ya son conformes; los consumidores aguas abajo reciben frames pre-difuminados.
-
¿Tengo que escribir código de codificador o de pipeline?
No. El micro service de captura de cámara posee el pipeline de vídeo de extremo a extremo — inicio, parada, recuperación de errores, hot-plug — en cinco transportes y dos niveles de hardware.
-
¿En qué se diferencia la dashcam externa de marca blanca de la grabación interna?
mos-dashcam es el grabador interno; dashcam-controller controla el hardware de dashcam externa de marca blanca sobre Wi-Fi HTTP y notificación TCP. Ambas pueden coexistir en el mismo vehículo.
Traiga dos cámaras y un caso de uso.
Transporte de captura, estrategia de grabación, protocolo en vivo, fuente de despertar, modelo de IA, formato de despliegue — traiga lo que tenga y esbozaremos el pipeline durante la llamada. Las flotas multicámara en vehículos autónomos también encajan con Atención Remota.