Une image 4K contient plus de huit millions de pixels. L'envoi de trente de ces images par seconde sans compression crée un flux de données très important. Les modules de caméra USB utilisent donc souvent le MJPEG car la compression JPEG réduit la quantité de données qui doivent transiter par le lien USB.
L'USB 2.0 a une bande passante pratique beaucoup plus faible que l'USB 3.x. Même sur l'USB 3.x, les modes à haut débit sans compression peuvent entrer en concurrence avec d'autres appareils et les limites du contrôleur hôte. Le MJPEG permet à la même interface physique de transporter une résolution ou une fréquence d'images plus élevée en réduisant le nombre d'octets par image.
Contrairement aux codecs vidéo à longue GOP comme H.264/H.265, le MJPEG compresse les images individuelles comme des images JPEG. Cela rend l'accès aléatoire aux images relativement simple et évite les dépendances de prédiction inter-images. Pour certaines applications de vision, cette simplicité est utile même si des artefacts de compression subsistent.
La compression ne fait pas disparaître les données ; elle déplace le travail ailleurs. La caméra ou le pont compresse l'image, et l'hôte la décode. Un processeur embarqué faible peut avoir du mal avec plusieurs flux MJPEG 4K même si le bus USB peut les transporter.
Pour les systèmes multi-caméras, mesurez l'utilisation de l'USB et la charge de décodage CPU/GPU.
L'hôte doit toujours négocier le mode, recevoir le flux, décoder les images et les déplacer dans la mémoire. Les frameworks logiciels peuvent copier des tampons ou convertir des formats de couleur, ajoutant de la latence. La qualité du câble et le partage du contrôleur USB peuvent également affecter les performances soutenues.
Une spécification doit être vérifiée sur l'hôte final plutôt que supposée à partir d'un test réussi sur un PC de bureau.
Si un algorithme est sensible aux artefacts JPEG, nécessite des valeurs de pixels cohérentes ou évite la latence du décodeur, le YUY2 ou un autre chemin non compressé/brut peut être préféré. Dans ce cas, l'USB 3.x, une résolution plus faible, une fréquence d'images plus faible ou une interface différente peuvent être nécessaires.
Comparez la table des modes : résolution, fréquence d'images et format. Vérifiez ensuite la version de l'USB, la charge de décodage de l'hôte, la latence et si l'application traite chaque image. Un module annonçant ‘4K30’ peut se comporter très différemment selon que ce mode est MJPEG, H.264 ou un autre format.
Une seule caméra MJPEG 4K30 peut fonctionner de manière fiable sur un hôte, mais quatre caméras identiques peuvent submerger la topologie USB ou les ressources du décodeur. La compression a réduit la bande passante de chaque lien, mais le système combiné doit toujours recevoir et décoder quatre flux. La conception multi-caméras nécessite donc des mesures globales, pas une hypothèse par caméra.
L'énoncé complet doit inclure le format et l'interface : par exemple, 3840×2160 à 30 ips en MJPEG sur un lien USB spécifique. Sans le format, le nombre masque la contrainte d'ingénierie clé. Cette habitude de lecture évite de nombreuses erreurs de sélection.
C'est un format de compression avec perte, donc des artefacts sont possibles. S'ils sont importants dépend des paramètres de compression et de l'application.
Le H.265 peut compresser plus efficacement mais ajoute de la complexité au codec et souvent plus de latence. Le MJPEG est simple et indépendant des images.
Cela peut être possible pour certains formats et implémentations, mais le débit de données exact, la surcharge du protocole et le pipeline hôte doivent être vérifiés. Ne le supposez pas à partir du nom de l'interface seul.
