[Windows Mobile] Programming Camera Driver #4

[Windows Mobile] Programming Camera Driver #4

Video Format Negotiation

   

DirectShow middleware와 같은 camera client는 CSPROPERTY_PIN_DATARANGES (see CSPROPERTY_PIN) property를 이용하여, 주어진 pin이 지원하는 모든 video formats을 알아보기 위해, camera driver로 query할 수 있다. Camera driver는 pin이 지원하는 모든 video formats을 나타내는 structure 배열을 return함으로써, 이 query에 대해 응답해야만 한다.

아래의 list는 video formats을 나타낼 때, 사용되는 structure를 보여준다.

CS_DATARANGE_VIDEO

CS_DATARANGE_VIDEO2

   

Client는 CSPROPERTY_PIN_DATAINTERSECTION (see CSPROPERTY_PIN)을 이용하여 stream type을 협의하며, CSPROPERTY_CONNECTION_DATAFORMAT을 이용하여, 상호 협의된 format 하나를 선택한다.

   

   

   

Buffer Management by the Camera Driver

   

Buffers는 camera driver 또는 client에 의해 할당될 수 있다. Client는 buffer 할당에 대한 역할이 자신에게 있는지 driver에 있는지를 detect할 수 있다. client에서 사용되는 buffer의 전체 수는 hardware의 capabilities 또는 DMA channel의 수에 의해 제한된다.

   

Allocation and Initialization

driver상의 나타난 Buffer의 수는 고정적이다. Client는 CSPROPSETID_Connection property set (see IOCTL_CS_PROPERTY)의 CSPROPERTY_CONNECTION_ALLOCATORFRAMING property (see CSPROPERTY_CONNECTION)를 이용한 query 후, 그에 대한 응답을 통해, buffer allocation에 대한 응답을 통해, hardware capabilities를 결정할 수 있다.

   

이것을 통해, 할당된 buffer의 수를 return 하고, software 또는 hardware상의 allocation type에 대해서 나타낸다. Client와 driver는 driver 초기 작업으로 buffer list를 협의한다.

   

Buffers는 buffer header structure CSSTREAM_HEADER를 통해, client와 driver사이에서 전달된다. Header는 CS_FRAME_INFO structure를 이용하여 설정되며, data packet 상의 특정 data type의 추가적인 정보를 위해 header를 보완하게 된다.

   

Video capture streams를 위한 최소한의 buffer 수는 보장할 수 없다. 그 Architecture는 성능에 따른 문제로, driver는 하나 이상의 buffer를 사용해야 하며, driver 개발자는 그러한 지원을 제공해야 한다는 것을 기초로 고안된다.

   

YUV 422 format을 위해, 3개의 buffer가 있다면, 모든 buffer는 single image를 위해 사용되며, 그 중 하나는 driver로부터 할당된 것이어야 한다.

   

Buffers allocated by the driver

Hardware memory에 할당된 buffer의 경우, driver는 자신의 memory 할당자 (allocator)를 가지고 있어야 하며, client는 driver로부터 할당된 buffer list를 받아야만 한다.

   

Driver는 CSPROPERTY_BUFFER_DRIVER property (see CSPROPERTY_BUFFER_MODE)를 통해, buffer allocation model에 대한 driver의 지원을 나타내야 한다.

Client는 CSPROPSETID_Connection property set (see IOCTL_CS_PROPERTY)의 CSPROPERTY_CONNECTION_ALLOCATORFRAMING property (see CSPROPERTY_CONNECTION)을 이용하여 query함으로써, driver가 어떤 framing model을 지원하는지 결정한다.

   

Client는 IOCTL_CS_BUFFERS와 열거된 CS_ALLOCATE (see BUFFER_COMMANDS)을 포함하는 DeviceIoControl 함수를 호출함으로써, buffer list를 얻을 수 있다.

   

Buffers allocated by the client

Buffer가 system memory상의 할당되어있을 경우, client는 pin이 stop mode인 상태에서 driver에게 buffer list를 전달해야 한다. Stop mode인 상태로 pin이 놓여지는 것은 driver가 buffer를 전달하기 위한 direct memory access (DMA) operation을 준비할 수 있도록 해준다. Client는 driver가 DMA operation을 준비하기 전에, buffers를 초기화 해야 한다. Client는 buffer를 통한 작업을 완료하면, buffer를 위한 memory를 free시켜야 한다. Client는 client의 DMA capabilities를 기반으로 buffer 할당에 대한 두 가지 다른 접근 방법 중 하나를 취한다.

   

만약 driver의 DMA 준비 시간이 느리다면, driver는 client로부터 모든 버퍼에 대해 먼저 알아야 한다. Driver는 CSPROPERTY_BUFFER_CLIENT_LIMITED property을 통해, buffer allocation model에 대한 이러한 지원을 나타내고 있다.

   

만약 driver DMA 준비 시간이 빠르다면, client는 buffer가 필요할 때마다, buffer를 allocation, initiation, release 할 수 있다. Driver는 CSPROPERTY_BUFFER_CLIENT_UNLIMITED property를 통해, buffer allocation model에 대한 이러한 지원을 나타내고 있다.

   

Client는 CSPROPERTY_CONNECTION_ALLOCATORFRAMING property를 통해 query함으로써, driver가 지원하는 framing model이 어떤 것인지를 결정한다.

   

Client는 IOCTL_CS_PROPERTY 및 CSPROPERTY_BUFFER_COUNT property를 이용한 DeviceIoControl 함수를 호출함으로써 buffer의 수를 협상할 수 있다.

   

Client는 IOCTL_CS_BUFFERS 및 CS_ENQUEUE를 이용하여, driver에게 buffer를 전달한다. Client는 IOCTL_CS_BUFFERS 및 CS_DEALLOCATE를 이용하여, 사용된 buffer를 release한다.

   

Buffer rotation

Idle buffers를 위한 queue와 ready buffers를 위한 queue로, 두 가지의 buffer queue가 존재한다. Client는 idle buffers를 위한 queue를 관리하며, driver는 ready buffers를 위한 queue를 관리한다.

   

Driver 초기화 이후, 모든 capture buffer는 client idle queue에 놓여진다. 이때, driver는 해당 buffers에 대해 알고 있지만 그것들을 제어하지는 않는다. Driver가 buffer를 제어할 수 있도록 하기 위해서, client는 idle queue에서 ready queue로 해당 buffer를 전달해야만 한다. Client는 CS_ENQUEUE property (see BUFFER_COMMANDS)를 셋팅하여, IOCTL_CS_PROPERTY를 호출한다.

   

IOCTL은 CS_STREAM_DESCRIPTOR structure의 pointer를 취하며, 하나의 상태를 return 한다. CS_STREAM_DESCRIPTOR structure의 모든 멤버는 채워져야 한다. CS_STREAM_DESCRIPTOR structure는 application에 의해 할당되어야 하며, driver가 application에게 buffer를 return할 때까지, 유효한 상태로 남아있어야 한다.

   

Driver가 IOCTL 호출을 받았을 때, driver는 pointer를 확인하기 위해 handle을 사용하며, descriptor의 shadow copy를 받는다. Driver는 descriptor에 대한 shadow copy를 연결하고, buffer를 ready queue에 추가한다.

   

Hardware가 buffer를 다 채운다면, driver는 message queue를 사용하여 application에게 buffer를 return 해야 한다. 그렇게 하기 위해, driver는 message queue를 이용하여, Read function을 통해, 전달된 stream descriptor에 대한 pointer를 돌려준다.

   

   

   

Asynchronous Data Flow and Buffer Management in Camera Drivers

   

Windows Embedded CE Camera Device Driver Interface는 message queue를 이용하여, asynchronous operation을 지원한다. Client는 CreateMsgQueue function을 이용하여 massage queue를 생성하며, driver에게 해당 queue object에 대한 핸들을 전달한다. Driver는 해당 queue를 이용하여, 완성된 video frames를 client에게 전달한다. Client는 일반적으로 WaitForSingleObject 또는 ReadMsgQueue 함수를 통해 제어되는 worker thread를 사용한다. Worker thread는 사용 가능한 video frame을 처리하며, IOCTL_CS_BUFFERS를 통한 재사용을 위해, buffer를 되돌려주는 역할을 담당한다.

   

아래의 code는 message queue에 대한 external interface를 나타내고 있다.

CSPROPERTY_CONNECTION_STATE/CSSTATE_PAUSE

   

HANDLE WINAPI CreateMsgQueue(LPCWSTR lpszName,

LPMSGQUEUEOPTIONS lpOptions);

BOOL WINAPI ReadMsgQueue(HANDLE hMsgQ, LPVOID lpBuffer,

DWORD cbBufferSize,

LPDWORD lpNumberOfBytesRead,

DWORD dwTimeout, DWORD *pdwFlags);

BOOL WINAPI WriteMsgQueue(HANDLE hMsgQ, LPVOID lpBuffer,

DWORD cbDataSize, DWORD dwTimeout,

DWORD dwFlags);

   

   

October 9, 2007

from Hoya^^

   

원본 위치 <http://www.devpia.com/Maeul/Contents/Detail.aspx?BoardID=60&MAEULNO=23&no=267&page=2>