2012-10-18 3 views
7

우리는 GigE YUV 비디오 스트림을 읽고 그것을 화면에 표시하는 응용 프로그램을 가지고 있습니다. 프로파일 링을 통해 우리는 YUV (UYVY)에서 RGB24로 각 프레임을 변환하는 기능이 카메라 - 스크린 (camera-to-screen) 파이프 라인의 다른 어떤 부분보다 적어도 시간과 CPU가 더 오래 걸리는 것을 알게되었습니다.YUV -> RGB 변환을 하드웨어 가속화 할 수 있습니까?

우리가 사용하는 변환 함수의 GigE 소프트웨어 벤더 (Pleora)가 제공하고 자신의 ''(비 최적화)보다 약간 빠른 구현이다. 우리는 나머지 파이프 라인에 대해 DirectShow를 사용하고 있습니다. '작업 관리자 벤치마킹'은 전환 기능을 호출 할 때 전환을 건너 뛸 때 4-5 %의 CPU 사용량과 CPU 사용량이 15-19 % 인 1080p 30fps 스트림을 보여줍니다.

질문은 우리는 한 :

  1. 우리를 위해이 변환을 수행하는 DirectShow 필터가 아니라 제 3 자 SDK 또는 우리 자신의 (CPU-에 의존하지 않고, 잘하면 더 성능이 좋은 방법으로, 거기에 기반, 직렬) 변환 기능?
  2. 이 변환을 CPU에서 수행해야합니까? 아니면 병렬 처리를 위해 GPU로 어떻게로드 오프 할 수 있습니까?

고마워요! 에릭.

+0

비용은 이미지의 모든 바이트를 읽고 쓰므로 메모리 대역폭을 포화 시키므로 발생합니다. GPU 프로세싱은 낮은 대역폭 비율에 대한 높은 계산 오버 헤드에 대해서만 유익합니다. 이것은 YUV 오버레이를 사용하는 비디오 카드의 장점 중 하나입니다. –

답변

3

아마도 변환은 GPU 처리를위한 좋은 후보 일 수 있지만 변환 된 데이터로 무엇을 할 것입니까? 소프트웨어에서 추가 처리가 필요한 경우 비디오 어댑터에서 다시 읽음으로써 GPU로 처리를 오프로드하여 얻을 수있는 모든 이득을 망칠 수 있습니다. 프리젠 테이션 목적으로 만 필요하다면 변환 할 필요가 없으며 YUV 이미지를 비디오 어댑터에 바로 전달할 수 있으며이 방식으로 제시 할 수 있습니다 (파이프 라인의 이상적인 구성입니다. 모든 전환).

  1. 표준 윈도우 비스타 + DMO
  2. : 소프트웨어 변환에 대해 이야기

    , 그러나 나는 매우 (SIMD이 가능)을 사용할 수 변환이 최적화되어, 당신이 지금 사용하고있는 변환의 품질에 대한 확실하지 않다

  3. 는 FFmpeg의 libswscale
  4. 인텔 IPP 프리미티브는

세보다 다소 쉽게 DirectShow를 파이프 라인에 플러그 가능합니다. 또한 고해상도 이미지는 병렬 소프트웨어 처리를위한 좋은 후보입니다.

+0

고마워요! 우수하고 명확한 답장. 최종 출력물은 Direct3D RGB32 표면이어야한다는 WPF D3DImage에 대한 것이므로 비디오 카드에 YUV로 표시하도록 요청하는 것은 옵션이 아닙니다. 내가 추천하는 3 개의 libs를 살펴보고 가능한 최선의 해결책으로 삼을 것이다. – user1757226

관련 문제