Solutions · Caméras IA
Livrez une gamme de produits caméras IA.
Un OS de caméra connectée pour les appareils edge AI-first. Caméra, GPU et NPU partagent la mémoire — sans copie pixel CPU. Déclarez le pipeline en TOML ; livrez un modèle ONNX ou TFLite. Jusqu'à ~100 TOPS sur la classe IA.
Trois formes produit
Un runtime. Trois formes de déploiement.
La même plateforme vidéo MOS4 est livrée sous trois formes produit nommées. Les six fonctions ci-dessous tournent sous chaque forme — capturer, enregistrer, diffuser, récupérer, réveiller, IA cloud.
boîtier caméra OEM · installation fixe · mono-optique
AI Cam · boîtier OEM
Caméra mono-optique en installation fixe avec inférence IA embarquée. Inspection industrielle, périmètre, anti-vol retail, vision opérateur sur machines lourdes. Marquée par l'OEM, tourne sur la plateforme MOS4.
embarquée · double-optique · ADAS + DMS
Dashcam · embarquée
Dashcam embarquée double-optique avec assistance conducteur (ADAS), surveillance conducteur (DMS) et anonymisation RGPD en direct. Déploiements en production sur véhicules de performance, camions, véhicules utilitaires légers et flottes spécialisées.
flotte · 3–5 caméras · vision opérateur
Réseau flotte multi-caméras
Réseaux de trois à cinq caméras pour la livraison, le ground-handling et la vision opérateur off-highway. Les frames se déplacent directement des caméras vers l'inférence IA et l'enregistrement sans copie CPU. Mêmes six fonctions que les formats mono-caméra, déployées sur toutes les optiques.
Vous cherchez le catalogue de cas d’usage IA (DMS, ADAS, sécurité chantier et des biens) ? Voir Cas d’usage IA. Les approfondissements du pipeline (extraction ROI, anonymisation RGPD en direct) vivent chez AI Vision. L'échelle silicium et les SKU matériel ? Voir matériel et munic.io.
Carte des fonctions
Choisissez la tâche. Accédez à sa section.
Connecter n'importe quelle caméra
Cinq transports — MIPI-CSI, GMSL2, USB UVC, RTSP/ONVIF, WebRTC — derrière un seul service de contrôle de capture. Deux familles de SoC. Hot-plug. Backend sélectionné à l'exécution.
Enregistrer sur événement
Stockage roulant avec protection de clips déclenchée par événement — les segments signalés ne sont jamais supprimés par la politique de rétention. Zéro écriture flash pendant l'enregistrement normal. L'anonymisation RGPD en direct tourne dans le pipeline de capture.
Diffusion en direct
WebRTC (compatible navigateur), RTSP / RTSPS et SRT pour la longue distance à faible latence sur cellulaire avec pertes. Lecture compatible navigateur. La signalisation de session est prise en charge par la plateforme — aucun code de signalisation à écrire.
Récupérer un clip
Sept opérations de service couvrent le cycle de vie complet des médias stockés. Extraction de clip par copie de flux — sans décodage, sans ré-encodage. Upload SFTP avec épinglage de clé serveur et compactage de charge utile avant upload.
Réveil sur événement
Sept sources de réveil — Allumage, Alarme, RTC, trame CAN, Mouvement, Modem, Perturbation. Délai de mise en service inférieur à cinq secondes — assez rapide pour rattraper un véhicule en fuite.
Exécuter l'IA sur les octets
Triage NPU embarqué aujourd'hui ; IA cloud sur les clips uploadés fusionnés avec le flux d'événements du cycle de vie — comportement conducteur, codes défauts (DTC), position OBD, pose GNSS. Conforme RGPD par floutage au moment de la capture.
Comment ça s'articule
Un pipeline, six fonctions.
La caméra produit des frames zero-copy dans le bus de frames ; le bus distribue vers l'encodeur, le NPU et la diffusion ; l'encodeur alimente l'index dashcam, qui alimente l'upload SFTP, qui alimente l'IA cloud ; l'IA cloud reçoit aussi les détections 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
Multi-caméra
Une à huit caméras clé en main.
Cinq transports derrière une seule API de service. Deux familles matérielles. Une à huit caméras par appareil sont supportées dans le runtime livré ; des fan-outs plus larges sont disponibles sur étude. Les frames se déplacent dans le pipeline en mémoire partagée — toutes les sources convergent vers le même format, donc les consommateurs en aval (inférence IA, encodeur, diffusion) n'ont pas de négociation par source à faire.
Enregistrement et diffusion simultanés
Beaucoup de plateformes caméra forcent à choisir entre enregistrer localement et diffuser ou téléverser d'anciens clips. MOS4 est conçu pour faire les deux à la fois : encodage en direct vers le segment sink flash-aware, flux RTSP/WebRTC et upload de clips historiques tournent sur le même plan de frames en mémoire partagée, sans duplication de buffer.
Stockage avec wear-leveling
Le segment sink est flash-aware : les écritures sont réparties entre blocs pour étendre l'endurance sur les SKU premium à exposition longue. Politiques de rétention, clips protégés et file d'upload cloud partagent la même comptabilité d'usure.
| Transport | Backend SoC | Notes |
|---|---|---|
| MIPI-CSI | classe IA / classe compute (libcamera) | MIPI natif ; sans bridge externe |
| GMSL2 | classe IA (bridge sérialiseur) | Chemin bridge sérialiseur |
| USB UVC | Les deux | Driver standard V4L2 classe UVC |
| Ethernet RTSP / ONVIF | Les deux | Caméras réseau ; RTSPS via TLS |
| WebRTC (WHEP) | Les deux | Signalisation compatible navigateur |
Plusieurs capteurs alimentent leurs backends par plateforme ; les backends convergent vers un élément tee avec le contrat bus de frames zero-copy ; le tee distribue vers l'encodeur, le NPU, le shader ROI GPU et le tracker de pose.
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 bout en bout sur cinq transports et deux familles de SoC. Backend sélectionné à l'exécution via probe device-tree.
NV12 dmabuf entry
Chaque backend normalise vers video/x-raw(memory:DMABuf), format=NV12. Le
mapping pixel CPU est une violation de spec dans les builds de production.
mos-frame Fanout SHM inter-processus via dmabuf fd Linux sur SCM_RIGHTS. Politique de drop LATEST-N par abonné — un consommateur lent n'arrête jamais le producteur.
CaptureControlService ListDevices · ConfigureStream · StartCapture · StopCapture · GetStatus · ResetCapture — une surface pour chaque plateforme.
Enregistrer sur événement
Enregistrez ce qui compte. Conservez ce que vous signalez.
Les segments roulants se renouvellent selon le budget de stockage. Un flag d'événement transforme un segment en clip protégé — jamais supprimé par la politique de rétention. L'anonymisation RGPD vit dans le pipeline de capture, avant qu'une frame n'atteigne l'encodeur.
Le pipeline de capture alimente le segment sink flash-aware ; chaque segment fermé déclenche un événement SegmentClosed dans l'index SQLite ; l'enforcer de rétention vérifie le flag protégé et supprime les segments non protégés les plus anciens au-dessus du budget ; les flags d'événements appellent la méthode de service Protect pour marquer les segments comme sûrs.
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 | Paramètre | Défaut | Notes |
|---|---|---|
| segment_seconds | configurable | Durée du segment ; bornée par le GOP et le batch d'écriture de stockage. |
| budget_bytes | 10 Gio | L'enforcer de rétention supprime les segments non protégés les plus anciens au-dessus. |
| gop_seconds | configurable | Affecte le slop de bord de clip sur ExtractClip (~1–2 s). |
| anonymisation.enabled | false | Flou RGPD en direct (pixelisation dans le pipeline). Reboot pour basculer. |
| event_flag | 0 | Flag par segment ; protéger via la méthode de service Protect pour exclure de la rétention. |
mos-camera-capture Étage d'encodeur de segments et anonymisation RGPD — pipeline GStreamer du capteur au segment sink flash-aware, incluant l'étage de pixelisation GPU avant l'encodeur.
mos-dashcam Index de segments (SQLite en mémoire), enforcer de rétention et méthode de service Protect — cycle de vie complet des médias stockés sans une seule écriture flash pendant l'enregistrement normal.
flash-aware segment sink Renommage atomique à la fermeture du segment — frontière de segment sûre en cas de perte d'alimentation. Aucun segment partiel dans l'index après un arrêt inattendu.
mp4mux + h264parse + hw-encoder
Pipeline encodeur sélectionné à l'exécution — encodeur matériel H.264 sur silicium classe
IA, encodeur V4L2 H.264 sur l'autre variante. h264parse normalise le bytestream
; mp4mux multiplexe en MP4.
Diffusion en direct
Diffusez en direct vers un navigateur, un lecteur ou un relais cloud.
Trois chemins en direct — WebRTC (WHEP compatible navigateur), RTSP / RTSPS et SRT. SRT pour la longue distance à faible latence sur cellulaire avec pertes. Le micro service gère l'établissement de session ; la signalisation est transparente pour l'intégration.
La caméra alimente l'encodeur H.264 ; l'encodeur distribue vers un serveur RTSP (rtsps:// avec TLS), un endpoint WHEP et un listener SRT ; RTSP alimente les lecteurs VLC/ffmpeg, WHEP alimente un navigateur, SRT alimente un relais cloud.
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]
| Protocole | URI | Élément | Usage |
|---|---|---|---|
| WebRTC (WHEP) | http(s)://…/whep | whepsrc | Lecture navigateur ; vue embarquée dans l'UI flotte |
| WebRTC (signalisation WS) | ws(s)://… | webrtcsrc | Serveur de signalisation personnalisé |
| RTSP | rtsp://… | rtspsrc | VLC · ffmpeg · ingestion NVR |
| RTSPS (RTSP + TLS) | rtsps://… | rtspsrc protocols=tcp+srtp | Bundle CA validé TLS pour la production |
| SRT | srt://… | srtsink / srtsrc | Longue distance à faible latence sur cellulaire avec pertes |
whepsrc / webrtcsrc Éléments source WebRTC — WHEP offer/answer sur HTTP, signalisation WebSocket, collecte ICE, handshake DTLS. Vous fournissez l'URI ; l'élément négocie la session.
rtspsrc
Source RTSP et RTSPS — rtsp:// simple ou rtsps:// validé TLS
avec protocols=tcp+srtp. Bundle CA épinglé en production ; en développement
on peut définir tls-validation-flags=0.
plomberie SRT
Listener SRT via srtsink / srtsrc — récupération de paquets sur cellulaire
avec pertes sans head-of-line blocking TCP. Longue distance vers un relais cloud sans code d'intégration
côté relais.
établissement session ICE / DTLS Cycle de vie complet de session WebRTC — collecte de candidats, traversée STUN/TURN, accord de clés DTLS-SRTP. Le micro service expose le flux RTP une fois la session active ; l'intégration ne touche pas au handshake.
validation TLS pour rtsps://
Validation de chaîne de certificats X.509, épinglage de bundle CA et dérivation de clé
SRTP — tout dans rtspsrc. Aucune plomberie OpenSSL dans la couche
d'intégration.
Récupérer un clip
Récupérez un clip à la demande. Envoyez-le vers votre cloud.
Sept opérations de service couvrent le cycle de vie des médias stockés. Extraction de clip par copie de flux — sans décodage, sans ré-encodage, ~1–2 s de slop sur les bords. Upload SFTP avec épinglage de clé serveur, garde contre path-traversal et compactage de charge utile avant upload.
GetSegments requête l'index de segments par lentille et plage de temps ; ExtractClip effectue l'extraction par copie de flux avec ~1–2 s de slop ; Upload envoie en SFTP avec épinglage de clé hôte ; la charge utile est compactée (atomes redondants retirés, offsets de chunks patchés) avant le transfert. Snapshot (keyframe vers JPEG ~50 ms) et Protect/Unprotect sont montrés en chemins latéraux pointillés.
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
| Opération | Entrée | Sortie |
|---|---|---|
| GetSegments | lens, start_ts, end_ts | liste de SegmentRow |
| ExtractClip | segment_id, start_offset, end_offset | chemin du clip sur disque |
| Snapshot | segment_id, keyframe_offset | chemin JPEG |
| Protect | segment_id | — (idempotent) |
| Unprotect | segment_id | — (idempotent) |
| Remove | segment_id | — (supprime fichier + ligne) |
| Upload | paths, destination_uri, options | flux de statut d'upload |
mos-dashcam Index de segments (SQLite, en mémoire avec snapshots), enforcer de rétention et les sept opérations de service — GetSegments, ExtractClip, Snapshot, Protect, Unprotect, Remove, Upload. Prêt production sur les chemins d'enregistrement interne.
splitmuxsrc ! qtmux ! filesink
Pipeline GStreamer mux-only pour ExtractClip — splitmuxsrc lit le segment source
; qtmux remultiplexe le flux ; filesink écrit le clip de sortie. Sans
décodage, sans ré-encodage, sans aller-retour pixel.
russh-sftp ring backend
Transport d'upload SFTP — russh-sftp avec backend ring, épinglage de clé hôte,
garde contre path-traversal et substitution d'URL par jeton de contexte. L'intégration fournit
une URI ; le micro service gère le handshake SSH et le transfert.
mp4-reduce
Retire les atomes free et skip du conteneur MP4, puis patche les tables
d'offsets de chunks stco / co64 pour garder le fichier valide. Réduit
la charge utile d'upload sans ré-encoder une seule frame.
dashcam-controller
Intégration dashcam externe en marque blanche sur Wi-Fi HTTP et notification TCP. File de
requêtes en attente avec TTL pour gérer les coupures de connectivité. Distinct de
mos-dashcam — ce micro service pilote une unité matérielle externe, pas le pipeline
d'enregistrement interne du boîtier MOS4.
mos-dashcam vs dashcam-controller
mos-dashcam est l'enregistreur interne : il tourne sur le boîtier MOS4, possède le FIFO de segments et expose les sept opérations de service documentées ci-dessus. dashcam-controller pilote une unité dashcam externe en marque blanche sur Wi-Fi HTTP et notification TCP — matériel séparé, cycle de vie séparé, même véhicule. Les deux peuvent tourner simultanément ; ils ne partagent pas d'état.
Réveil sur événement
Réveil sur impact. Réveil sur trame CAN. Réveil sur commande cloud.
Sept sources de réveil couvrent le cycle de vie d'un véhicule à l'arrêt ou en sommeil. Le délai de mise en service est inférieur à cinq secondes — assez rapide pour rattraper un véhicule qui vient de démarrer.
Sept sources de réveil — Allumage, Alarme, RTC, trame CAN, Mouvement, Modem, Perturbation — alimentent toutes le gestionnaire d'alimentation, qui amène le boîtier à l'état prêt en moins de cinq secondes.
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]
| Source | Déclencheur | Usage | Délai de mise en service |
|---|---|---|---|
| Allumage | Signal d'allumage du véhicule | Boîtier flotte standard | < 5 s |
| Alarme | Entrée d'alarme externe | Cambriolage / bouton panique | < 5 s |
| RTC | Horloge planifiée ou timer relatif | Upload santé périodique / fin de journée | < 5 s |
| Trame CAN | Correspondance ID CAN | Réveil sur signal spécifique — défaut harnais / porte ouverte | < 5 s |
| Mouvement | Seuil d'accéléromètre | Véhicule en mouvement à l'arrêt → réveil pour enregistrer | < 5 s |
| Modem | Réveil distant émis par le cloud | Opérateur réveille pour flux en direct / récupération de clip | < 5 s |
| Perturbation | Seuil d'impact capteur G | Capture événement crash / effraction | < 5 s |
configure_wake_events Bitmask de sources de réveil du gestionnaire d'alimentation — configurez quelles sources parmi les sept sont actives pour le prochain cycle de sommeil. Un seul appel ; le micro service possède les écritures de registres matériels et l'arbitrage des sources.
set_rtc_wake_time Planificateur de réveil RTC — fixez un timestamp horloge murale ou un offset relatif pour le prochain réveil planifié. Utilisé pour l'upload santé périodique, le reporting de fin de journée ou tout cycle de reprise piloté par le temps.
get_wake_reason / clear_wake_reason Lecture et effacement du motif de réveil — appelez une fois après reprise pour lire le bitmask identifiant la source déclenchante, puis effacez avant le prochain sommeil. Le gestionnaire d'alimentation possède le registre de motif et distingue automatiquement boot et réveil.
distinction boot vs réveil Le gestionnaire d'alimentation distingue un boot à froid d'un réveil depuis le sommeil au démarrage. Le code d'intégration voit un bitmask de motif de réveil propre — aucune inspection de registre matériel brut requise.
request_reboot_on_idle / request_shutdown_on_idle Hooks d'override au prochain idle — planifiez un reboot ou un shutdown à la fin de la fenêtre active courante sans interrompre l'enregistrement ou l'upload en cours. Le micro service attend la condition d'idle avant d'exécuter.
IA cloud
NPU embarqué aujourd'hui. IA cloud sur les octets que vous uploadez.
Le triage IA embarqué tourne avant qu'un octet ne quitte le boîtier — les frames sont cropées et analysées sur le NPU. Un produit cloud Munic exécute ensuite une IA plus lourde par clip sur les segments uploadés et fusionne avec le flux d'événements du cycle de vie — comportement conducteur, codes défauts (DTC), position OBD-II, pose GNSS. Le clip est conforme RGPD au moment où le cloud le voit.
La capture avec flou RGPD en direct alimente le triage NPU embarqué et le segment enregistreur. Le segment est uploadé via SFTP comme octets conformes RGPD vers l'IA cloud. Comportement conducteur, DTC/position OBD et pose GNSS alimentent le flux d'événements du cycle de vie, qui fusionne avec l'inférence IA cloud par clip et sort vers le tableau de bord flotte.
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]
Le triage embarqué tourne avant qu'un octet ne quitte le boîtier — l'extraction de région d'intérêt plus l'inférence NPU écartent les frames non pertinentes. Ce qui atteint le cloud est déjà anonymisé et déjà filtré. L'IA cloud exécute des modèles par clip plus lourds et fusionne avec le flux d'événements du cycle de vie AI Funnel pour la corrélation comportement conducteur et incidents à l'échelle flotte.
mos-roi-shader Extraction ROI Vulkan avec zero-copy dmabuf-vers-NPU sur silicium classe IA supporté — sans copie pixel CPU dans le chemin IA. Les régions d'intérêt sont extraites et délivrées au NPU sans quitter le domaine mémoire de l'accélérateur.
mos-ai-runtime Inférence NPU .tflite sur silicium classe IA — exécution concurrente multi-modèles sur les slices NPU, gérée par le micro service. Apportez votre fichier modèle .tflite ; le runtime gère l'ordonnancement, la mémoire et la livraison des résultats.
AI Funnel Ré-entraînement cloud, quantisation et livraison OTA de modèle — gérés par le pipeline AI Funnel. Les modèles ré-entraînés atterrissent sur l'appareil sans cycle de mise à jour firmware. Aucun code d'intégration requis pour câbler la boucle de feedback.
corrélation d'événements du cycle de vie Un flag de fiabilité temporelle est attaché à chaque événement du cycle de vie — comportement conducteur, codes défauts (DTC), position OBD-II, pose GNSS. L'IA cloud utilise ce flag pour rejeter les correspondances de timestamp ambiguës avant la fusion avec les résultats d'inférence par clip. La posture RGPD est documentée sur /fr/platform/compliance.
Frontière de périmètre
Un produit cloud Munic spécifique fournit l'inférence par clip et la fusion du cycle de vie décrits dans cette section. Le nom du produit, la tarification et l'architecture cloud sont hors périmètre de cette page — cette conversation démarre avec l'ingénierie. Utilisez le CTA ci-dessous pour vous connecter.
Catalogue de cas d’usage IA
DMS, ADAS et sécurité flotte — le catalogue complet.
Surveillance conducteur, aide à la conduite, sécurité chantier et sécurité des biens — chacune un modèle embarqué fusionné avec la télémétrie véhicule en direct. Apportez votre propre modèle ou faites-en entraîner un à partir de vos images.
Voir le catalogue complet des cas d’usage IA →FAQ
Questions fréquentes
-
La pile vidéo tourne-t-elle sur du matériel classe modem ?
La capture et l'enregistrement dashcam tournent sur des appareils classe compute. L'inférence NPU (crop GPU, runtime IA embarqué) nécessite du silicium classe IA — il n'y a pas de fallback CPU en production.
-
Où se déroule l'anonymisation RGPD ?
Dans le pipeline de capture, avant qu'une image n'atteigne l'encodeur, le runtime IA ou tout consommateur. Les segments enregistrés sont déjà conformes ; les consommateurs en aval reçoivent des frames pré-floutées.
-
Dois-je écrire du code d'encodeur ou de pipeline ?
Non. Le micro service de capture caméra possède le pipeline vidéo de bout en bout — démarrage, arrêt, récupération d'erreur, hot-plug — sur cinq transports et deux familles matérielles.
-
Quelle est la différence entre la dashcam externe en marque blanche et l'enregistrement interne ?
mos-dashcam est l'enregistreur interne ; dashcam-controller pilote le matériel dashcam externe en marque blanche via Wi-Fi HTTP et notification TCP. Les deux peuvent coexister sur le même véhicule.
Apportez deux caméras et un cas d'usage.
Transport de capture, stratégie d'enregistrement, protocole en direct, source de réveil, modèle IA, forme de déploiement — apportez ce que vous avez et nous esquisserons le pipeline pendant l'appel. Les flottes multi-caméras sur véhicules autonomes se couplent aussi avec Remote Care.