Vídeo · Multicámara

Conectar cualquier cámara.

Cinco transportes detrás de una API service. Dos familias de SoC. Contrato de bus de frames zero-copy — cada backend converge en la misma forma de buffer, de modo que los consumidores posteriores no negocian el formato por fuente.

Cómo funciona

Un micro service de captura, cinco transportes.

Transportes de captura soportados por mos-camera-capture
Transporte Backend SoC Notas
MIPI-CSI iMX8M Plus (libcamera) MIPI nativo; sin puente externo
GMSL2 Familia QCS (QMMF) Solo vía Qualcomm
USB UVC Ambas Driver de clase V4L2 UVC estándar
Ethernet RTSP / ONVIF Ambas Cámaras de red; RTSPS vía TLS
WebRTC (WHEP) Ambas Señalización compatible con navegador

Varios 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, shader ROI GPU y pose tracker.

flowchart LR
  S1[Sensor 1] --> B1[Backend<br/>QMMF o libcamera]
  S2[Sensor 2] --> B2[Backend]
  S3[Sensor N] --> B3[Backend]
  B1 --> T[Tee · zero-copy DMABuf]
  B2 --> T
  B3 --> T
  T --> E[Codificador]
  T --> N[NPU]
  T --> G[Shader ROI GPU]
  T --> V[Pose tracker]
N sensores → backend por plataforma → tee zero-copy DMABuf → fanout 1:N
5 transportes de captura MIPI · GMSL · UVC · RTSP · WebRTC
2 familias de SoC Familia QCS · iMX8M Plus
6 servicio de control de captura ListDevices · ConfigureStream · Start · Stop · GetStatus · Reset
0 copias de pixel CPU zero-copy DMABuf en producción

Architecture

Lo que no escribes — la infraestructura entregada por MOS4.

service mos-camera-capture

Pipeline GStreamer de extremo a extremo en cinco transportes y dos familias de SoC. Backend seleccionado en tiempo de ejecución vía sondeo del device tree.

contrato NV12 dmabuf entry

Cada backend se normaliza en video/x-raw(memory:DMABuf), format=NV12. El mapeo de pixel en CPU es una violación de spec en builds de producción.

service mos-frame

Fanout SHM entre procesos vía fd de Linux dmabuf en SCM_RIGHTS. Política de descarte LATEST-N por suscriptor — un consumidor lento nunca bloquea al productor.

service CaptureControlService

ListDevices · ConfigureStream · StartCapture · StopCapture · GetStatus · ResetCapture — una superficie para cada plataforma.

Preguntas frecuentes

Preguntas frecuentes

  • ¿Cuántas cámaras simultáneas?

    No hay un límite fijo — la restricción es el ancho de banda del bus de frames y el número de productores soportados por el silicio SoC. Los despliegues en producción funcionan habitualmente con dashcams de óptica dual; los arrays de vigilancia multicámara de cuatro o más son soportados en silicio AI-class.

  • ¿Puedo mezclar MIPI-CSI y cámaras IP en el mismo dispositivo?

    Sí. El contrato de bus de frames zero-copy normaliza cada backend en la misma forma de buffer antes del elemento tee. Los consumidores posteriores (codificador, NPU, recorte GPU) no negocian el formato por fuente.

  • ¿Qué pasa si conecto una cámara USB en tiempo de ejecución?

    mos-camera-capture soporta hot-plug para UVC y gestiona el ciclo de vida del pipeline GStreamer de extremo a extremo — inicio, parada, recuperación de errores, hot-plug — sin código de integración.

  • ¿Tengo que escribir un pipeline GStreamer específico de la plataforma?

    No. El servicio de control de captura (ListDevices, ConfigureStream, StartCapture, StopCapture, GetStatus, ResetCapture) es la superficie de integración. La selección del backend ocurre en tiempo de ejecución vía sondeo del device tree; sin recompilación por variante de hardware.

Trae tus cámaras.

MIPI / GMSL / UVC / RTSP / WebRTC — elige tu mezcla de transportes y esbozaremos la topología de captura.