Um quadro 4K contém mais de oito milhões de pixels. Enviar trinta desses quadros por segundo sem compressão cria um fluxo de dados muito grande. Módulos de câmera USB, portanto, frequentemente usam MJPEG porque a compressão JPEG reduz a quantidade de dados que precisam viajar pelo link USB.
USB2.0 tem largura de banda muito menor na prática do que USB3.x. Mesmo em USB3.x, modos de alta taxa de bits sem compressão podem competir com outros dispositivos e limites do controlador host. MJPEG permite que a mesma interface física transporte uma resolução ou taxa de quadros mais alta, reduzindo o número de bytes por quadro.
Ao contrário de codecs de vídeo long-GOP como H.264/H.265, MJPEG comprime quadros individuais como imagens JPEG. Isso torna o acesso aleatório a quadros relativamente simples e evita dependências de predição inter-quadros. Para algumas aplicações de visão, essa simplicidade é útil, mesmo que artefatos de compressão permaneçam.
A compressão não faz os dados desaparecerem; ela move o trabalho para outro lugar. A câmera ou ponte comprime a imagem e o host a decodifica. Um processador embarcado fraco pode ter dificuldades com vários fluxos MJPEG 4K, mesmo que o barramento USB possa carregá-los.
Para sistemas com várias câmeras, meça tanto a utilização do USB quanto a carga de decodificação da CPU/GPU.
O host ainda precisa negociar o modo, receber o fluxo, decodificar quadros e movê-los para a memória. Frameworks de software podem copiar buffers ou converter formatos de cor, adicionando latência. A qualidade do cabo e o compartilhamento do controlador USB também podem afetar o desempenho sustentado.
Uma especificação deve ser verificada no host final em vez de assumida a partir de um teste bem-sucedido em um PC desktop.
Se um algoritmo for sensível a artefatos JPEG, exigir valores de pixel consistentes ou evitar latência do decodificador, YUY2 ou outro caminho não comprimido/cru pode ser preferível. Nesse caso, USB3.x, resolução mais baixa, taxa de quadros mais baixa ou uma interface diferente podem ser necessários.
Compare a tabela de modos: resolução, taxa de quadros e formato. Em seguida, verifique a versão do USB, a carga de decodificação do host, a latência e se a aplicação processa todos os quadros. Um módulo anunciando ‘4K30’ pode se comportar de maneira muito diferente, dependendo se esse modo é MJPEG, H.264 ou outro formato.
Uma única câmera 4K30 MJPEG pode transmitir de forma confiável em um host, mas quatro câmeras idênticas podem sobrecarregar a topologia USB ou os recursos do decodificador. A compressão reduziu a largura de banda de cada link, mas o sistema combinado ainda precisa receber e decodificar quatro fluxos. O design de várias câmeras, portanto, precisa de medições agregadas, não de uma suposição por câmera.
A declaração completa deve incluir formato e interface: por exemplo, 3840×2160 a 30 fps em MJPEG sobre um link USB específico. Sem o formato, o número esconde a principal restrição de engenharia. Esse hábito de leitura evita muitos erros de seleção.
É um formato de compressão com perdas, portanto, artefatos são possíveis. Se eles importam depende das configurações de compressão e da aplicação.
H.265 pode comprimir de forma mais eficiente, mas adiciona complexidade de codec e geralmente mais latência. MJPEG é simples e independente de quadro.
Pode ser possível para alguns formatos e implementações, mas a taxa de dados exata, a sobrecarga do protocolo e o pipeline do host devem ser verificados. Não assuma isso apenas pelo nome da interface.
