4K 프레임에는 8백만 개 이상의 픽셀이 포함됩니다. 압축 없이 초당 30개의 프레임을 전송하면 매우 큰 데이터 스트림이 생성됩니다. 따라서 USB 카메라 모듈은 JPEG 압축이 USB 링크를 통해 전송되어야 하는 데이터 양을 줄여주기 때문에 MJPEG를 자주 사용합니다.
USB2.0은 USB3.x보다 실제 대역폭이 훨씬 적습니다. USB3.x에서도 압축되지 않은 고비트 전송률 모드는 다른 장치 및 호스트 컨트롤러 제한과 경쟁할 수 있습니다. MJPEG를 사용하면 프레임당 바이트 수를 줄여 동일한 물리적 인터페이스로 더 높은 해상도 또는 프레임 속도를 처리할 수 있습니다.
H.264/H.265와 같은 장기 GOP 비디오 코덱과 달리 MJPEG는 개별 프레임을 JPEG 이미지로 압축합니다. 이렇게 하면 임의 프레임 액세스가 비교적 간단해지고 프레임 간 예측 종속성이 방지됩니다. 일부 비전 애플리케이션의 경우 압축 아티팩트가 남아 있더라도 이러한 단순성이 유용합니다.
압축은 데이터를 사라지게 하는 것이 아니라 다른 곳으로 이동시킵니다. 카메라 또는 브리지가 이미지를 압축하고 호스트가 이를 디코딩합니다. 약한 임베디드 프로세서는 USB 버스가 처리할 수 있더라도 여러 4K MJPEG 스트림을 처리하는 데 어려움을 겪을 수 있습니다.
다중 카메라 시스템의 경우 USB 사용률과 CPU/GPU 디코딩 부하를 모두 측정하십시오.
호스트는 여전히 모드를 협상하고 스트림을 수신하고 프레임을 디코딩하여 메모리로 이동해야 합니다. 소프트웨어 프레임워크는 버퍼를 복사하거나 색상 형식을 변환하여 지연 시간을 추가할 수 있습니다. 케이블 품질 및 USB 컨트롤러 공유도 지속적인 성능에 영향을 미칠 수 있습니다.
사양은 데스크톱 PC에서 성공적인 테스트를 가정하는 대신 최종 호스트에서 확인해야 합니다.
알고리즘이 JPEG 아티팩트에 민감하거나 일관된 픽셀 값을 요구하거나 디코더 지연 시간을 피해야 하는 경우 YUY2 또는 다른 압축되지 않은/원시 경로를 선호할 수 있습니다. 이 경우 USB3.x, 낮은 해상도, 낮은 프레임 속도 또는 다른 인터페이스가 필요할 수 있습니다.
모드 테이블을 비교하십시오: 해상도, 프레임 속도 및 형식. 그런 다음 USB 버전, 호스트 디코딩 부하, 지연 시간 및 애플리케이션이 모든 프레임을 처리하는지 확인하십시오. ‘4K30’을 광고하는 모듈은 해당 모드가 MJPEG, H.264 또는 다른 형식인지에 따라 매우 다르게 작동할 수 있습니다.
단일 4K30 MJPEG 카메라는 호스트에서 안정적으로 스트리밍될 수 있지만, 동일한 카메라 4대는 USB 토폴로지 또는 디코더 리소스를 압도할 수 있습니다. 압축은 각 링크의 대역폭을 줄였지만, 전체 시스템은 여전히 4개의 스트림을 수신하고 디코딩해야 합니다. 따라서 다중 카메라 설계는 카메라당 가정이 아닌 총체적인 측정이 필요합니다.
완전한 명세에는 형식과 인터페이스가 포함되어야 합니다. 예를 들어, 특정 USB 링크에서 MJPEG로 30fps의 3840×2160입니다. 형식 없이는 숫자가 주요 엔지니어링 제약을 숨깁니다. 이 읽기 습관은 많은 선택 실수를 방지합니다.
손실 압축 형식이므로 아티팩트가 발생할 수 있습니다. 압축 설정 및 애플리케이션에 따라 달라집니다.
H.265는 더 효율적으로 압축할 수 있지만 코덱 복잡성과 종종 더 많은 지연 시간을 추가합니다. MJPEG는 간단하고 프레임 독립적입니다.
일부 형식 및 구현에서는 가능할 수 있지만 정확한 데이터 속도, 프로토콜 오버헤드 및 호스트 파이프라인을 확인해야 합니다. 인터페이스 이름만으로 가정하지 마십시오.
