Un fotogramma 4K contiene più di otto milioni di pixel. L'invio di trenta di questi fotogrammi al secondo senza compressione crea un flusso di dati molto ampio. I moduli fotocamera USB utilizzano quindi spesso MJPEG perché la compressione JPEG riduce la quantità di dati che devono viaggiare attraverso il collegamento USB.
USB2.0 ha una larghezza di banda pratica molto inferiore rispetto a USB3.x. Anche su USB3.x, le modalità non compresse ad alto bit-rate possono competere con altri dispositivi e limiti del controller host. MJPEG consente alla stessa interfaccia fisica di trasportare una risoluzione o un frame rate più elevati riducendo il numero di byte per fotogramma.
A differenza dei codec video long-GOP come H.264/H.265, MJPEG comprime i singoli fotogrammi come immagini JPEG. Ciò rende l'accesso casuale ai fotogrammi relativamente semplice ed evita dipendenze di predizione inter-fotogramma. Per alcune applicazioni di visione, tale semplicità è utile anche se rimangono artefatti di compressione.
La compressione non fa scomparire i dati; sposta il lavoro altrove. La fotocamera o il bridge comprimono l'immagine e l'host la decodifica. Un processore embedded debole può faticare con diversi flussi MJPEG 4K anche se il bus USB può trasportarli.
Per sistemi multi-fotocamera, misurare sia l'utilizzo USB che il carico di decodifica CPU/GPU.
L'host deve comunque negoziare la modalità, ricevere lo stream, decodificare i fotogrammi e spostarli in memoria. I framework software possono copiare buffer o convertire formati colore, aggiungendo latenza. La qualità del cavo e la condivisione del controller USB possono anche influire sulle prestazioni sostenute.
Una specifica dovrebbe essere verificata sull'host finale piuttosto che assunta da un test riuscito su un PC desktop.
Se un algoritmo è sensibile agli artefatti JPEG, richiede valori di pixel coerenti o evita la latenza del decoder, si può preferire YUY2 o un altro percorso non compresso/raw. In tal caso, potrebbero essere necessari USB3.x, risoluzione inferiore, frame rate inferiore o un'interfaccia diversa.
Confrontare la tabella delle modalità: risoluzione, frame rate e formato. Quindi controllare la versione USB, il carico di decodifica dell'host, la latenza e se l'applicazione elabora ogni fotogramma. Un modulo che pubblicizza ‘4K30’ può comportarsi in modo molto diverso a seconda che tale modalità sia MJPEG, H.264 o un altro formato.
Una singola fotocamera MJPEG 4K30 può trasmettere in modo affidabile su un host, ma quattro fotocamere identiche possono sopraffare la topologia USB o le risorse del decoder. La compressione ha ridotto la larghezza di banda di ogni collegamento, eppure il sistema combinato deve ancora ricevere e decodificare quattro flussi. La progettazione multi-fotocamera richiede quindi misurazioni aggregate, non un'assunzione per fotocamera.
L'affermazione completa dovrebbe includere formato e interfaccia: ad esempio, 3840×2160 a 30 fps in MJPEG su un collegamento USB specifico. Senza il formato, il numero nasconde il vincolo ingegneristico chiave. Questa abitudine di lettura previene molti errori di selezione.
È un formato di compressione lossy, quindi sono possibili artefatti. Se siano importanti dipende dalle impostazioni di compressione e dall'applicazione.
H.265 può comprimere in modo più efficiente ma aggiunge complessità al codec e spesso più latenza. MJPEG è semplice e indipendente dal fotogramma.
Potrebbe essere possibile per alcuni formati e implementazioni, ma è necessario verificare la velocità dati esatta, l'overhead del protocollo e la pipeline dell'host. Non darlo per scontato solo dal nome dell'interfaccia.
