디바이스 MFT 디자인 가이드
Windows의 비디오 캡처 스택은 DMFT 형식의 사용자 모드 확장을 지원합니다. IHV가 제공하는 디바이스별 확장 구성 요소이며 캡처 파이프라인이 첫 번째 변환인 사후 캡처로 삽입됩니다. DMFT는 디바이스에서 사후 처리된 프레임을 수신합니다. 프레임에 대한 추가 사후 처리 작업은 DMFT 내에서 수행할 수 있습니다. DMFT는 디바이스의 모든 스트림에서 프레임을 수신할 수 있으며 요구 사항에 따라 여러 출력 스트림을 노출할 수 있습니다.
이 항목에서는 모든 스트림에 공통적인 후처리를 수행하는 데 사용할 수 있는 사용자 모드에서 실행되는 디바이스 전체 확장의 디자인에 대해 간략하게 설명합니다.
용어
| 용어 | Description |
|---|---|
| KS | 커널 스트리밍 드라이버 |
| AvStream | 오디오 비디오 스트리밍 드라이버 모델 |
| 필터 | 디바이스 instance 나타내는 개체 |
| 디바이스 MFT | IHV에서 제공하는 사용자 모드 캡처 드라이버 확장 |
| Devproxy | MF <-> AvStream 마샬러 |
| DTM | devproxy 및 Device MFT를 관리하는 디바이스 변환 관리자입니다. MF 파이프라인의 디바이스를 나타냅니다. |
설계 목표
디바이스 필터와 수명이 동일한 디바이스 필터 전체 사용자 모드 확장
디바이스에서 들어오는 입력 수를 지원합니다.
모든 수의 출력을 지원합니다(현재 요구 사항은 미리 보기, 레코드 및 사진의 세 가지 스트림임).
모든 디바이스 컨트롤을 디바이스 MFT로 라우팅합니다(필요에 따라 디바이스를 처리하거나 디바이스에 전달).
캡처된 스트림의 병렬 사후 처리
프레임 속도와 무관하게 3A 처리 허용
한 스트림의 메타데이터를 다른 스트림 간에 공유할 수 있도록 허용
GPU 리소스에 대한 액세스
MF MMCSS 작업 큐에 대한 액세스
MF 할당자에 대한 액세스
단순 인터페이스(MFT와 유사)
IHV/OEM 확장성을 위한 유연한 내부 아키텍처
디자인 제약 조건
캡처 API 화면이 변경되지 않음
이전 버전과의 호환성을 완료합니다. 예를 들어 레거시 앱 및 시나리오를 사용하는 동안에는 회귀가 없습니다.
스택 아키텍처 캡처
이 항목에서는 캡처 드라이버에 대한 필터 전체 사용자 모드 확장에 대한 지원에 대해 설명합니다. 이 구성 요소는 MF API, 스레드 풀, GPU 및 ISP 리소스에 액세스할 수 있습니다. 필터 와이드 확장은 자체 및 디바이스 Ks 필터 간에 스트림 수를 유연하게 사용할 수 있습니다. 이러한 유연성을 통해 전용 메타데이터 및 3A 처리 스트림에 사용할 수 있는 사용자 모드 확장과 드라이버 간의 원활한 대역 외 통신이 가능합니다.
DTM(디바이스 변환 관리자)
캡처 스택에는 새로운 시스템 제공 구성 요소인 DTM(디바이스 변환 관리자)이 도입되었습니다. DeviceSource 내에 상주하며 Devproxy MFT 및 디바이스 MFT를 관리합니다. DTM은 MediaType 협상, 샘플 전파 및 모든 MFT 이벤트 처리를 수행합니다. 또한 DeviceSource 및 DeviceSource에서 디바이스 스트림을 관리하는 데 필요한 기타 필요한 프라이빗 인터페이스에 IMFTransform 인터페이스를 노출합니다. 이 구성 요소는 파이프라인에서 Devproxy 및 Device MFT를 추상화합니다. 파이프라인은 DTM을 디바이스로 보고 디바이스 스트림으로 DTM에서 스트림합니다.
Devproxy
Devproxy는 AvStream 카메라 드라이버와 Media Foundation 간에 명령 및 비디오 프레임을 마샬링하는 비동기 MFT입니다. 이는 Windows에서 제공하며 카메라 드라이버의 n개 출력 을 지원합니다. 또한 디바이스에서 노출하는 모든 핀에 대한 할당자를 소유합니다.
디바이스 MFT
디바이스 MFT는 캡처 드라이버에 대한 사용자 모드 확장입니다. m x n 비동기 MFT입니다. 캡처 드라이버가 있는 시스템에 설치되며 캡처 드라이버 공급업체에서 제공합니다.
디바이스 MFT의 입력 스트림 수는 디바이스에서 노출하는 Ks 핀 수와 동일해야 합니다. 디바이스 MFT의 입력 스트림에서 지원하는 미디어 형식은 KS 핀에 의해 노출되는 미디어 형식과 동일해야 합니다.
Device MFT에서 노출하는 출력 스트림 수는 DeviceSource 및 캡처 스택, 캡처 API 및 애플리케이션에서 볼 수 있는 스트림이며 1, 2 또는 3개의 스트림일 수 있습니다. 디바이스 MFT의 입력 및 출력 스트림 수는 동일할 필요가 없습니다. 또한 입력 및 출력 스트림에는 동일한 미디어 형식이 필요하지 않으며 일반적으로 다른 mediatype이 있습니다. mediatype의 수도 일치하지 않아도 됩니다.
Devproxy의 출력 스트림에 의해 사용자 모드로 표현되는 첫 번째 Ks 핀은 디바이스 MFT의 첫 번째 입력 스트림과 연결되고, 두 번째 Ks 핀은 디바이스 MFT의 두 번째 입력 스트림이 있는 Devproxy의 출력 스트림에 의해 사용자 모드로 표현됩니다.
디바이스 MFT에는 Devproxy, DX 디바이스 및 MF WorkQueue ID에 대한 포인터가 제공됩니다. 디바이스에서 나오는 프레임은 해당 디바이스 MFT의 입력에 MF 샘플로 직접 공급됩니다. 이 모든 것을 통해 Device MFT는 캡처된 샘플을 처리하고 미리 보기, 녹화 및 사진 핀에 샘플을 제공할 수 있습니다.
디바이스로 가는 모든 명령 및 컨트롤이 디바이스 MFT로 다시 할당됩니다. 디바이스 MFT는 컨트롤을 처리하거나 Devproxy를 통해 드라이버에 전달합니다. 이렇게 하면 캡처 드라이버 스택에 의한 명령 처리가 간소화됩니다.
기능 개요
캡처 파이프라인을 초기화할 때 디바이스에 대한 디바이스 MFT가 있는 경우 DeviceSource는 DTM을 인스턴스화합니다. 디바이스를 나타내는 Devproxy의 instance DTM의 초기화 루틴에 전달합니다. DTM은 디바이스 MFT를 공동 만들고 기본 유효성 검사를 수행합니다. 예를 들어 Devproxy의 출력 핀 수가 디바이스 MFT의 입력 핀 수, 필수 인터페이스 지원 등과 동일한지 확인합니다.
DeviceSource는 DTM을 쿼리하여 지원되는 출력 mediatype을 가져옵니다. DTM은 디바이스 MFT의 출력 핀에서 이러한 항목을 가져옵니다. DeviceSource는 이 정보를 기반으로 프레젠테이션 설명자 및 Stream 설명자를 캡처 파이프라인에 노출합니다.
SourceReader는 DeviceSource의 노출된 미디어 형식을 사용하고 각 스트림에서 기본 mediatype을 설정합니다. 차례로 DeviceSource는 DTM의 출력 스트림에서 기본 mediatype을 설정합니다. DTM은 SetOutputStreamState 메서드를 사용하여 Device MFT의 출력 스트림에서 mediatype을 설정합니다.
SetOutputStreamState가 호출되면 디바이스 MFT는 DTM에 메시지를 게시하여 선택한 출력 mediatype 및 대기에 따라 입력 스트림의 mediatype을 변경합니다. 이 메시지에 대한 응답으로 DTM은 GetPreferredInputStreamState를 사용하여 디바이스 MFT의 입력 스트림에 대한 기본 입력 미디어 형식을 쿼리합니다. 그러면 Devproxy의 해당 출력 스트림에서 mediatype이 설정됩니다. 성공하면 DTM은 SetInputStreamState를 사용하여 디바이스 MFT의 입력 스트림에 동일한 mediatype을 설정합니다. 이 호출을 받은 후 디바이스 MFT 는 SetOutputStreamState를 완료합니다.
CaptureEngine은 DeviceSource에서 특정 스트림을 사용하도록 설정하여 개별 스트림을 선택합니다. SetOutputStreamState 호출을 통해 DTM에서 디바이스 MFT로 전파됩니다. 디바이스 MFT는 특정 출력 스트림을 요청된 상태로 배치합니다. 위에서 설명한 대로 디바이스 MFT는 DTM에 사용하도록 설정해야 하는 필요한 입력 스트림에 대해서도 알 수 있습니다. 이로 인해 DTM이 스트림 선택을 Devproxy로 전파합니다. 이 프로세스가 끝나면 Devproxy 및 Device MFT에서 필요한 모든 스트림을 스트리밍할 준비가 됩니다.
CaptureEngine이 ReadSample을 호출하면 SourceReader가 DeviceSource를 시작합니다. 차례로 DeviceSource는 파이프라인의 시작을 나타내는 MFT_MESSAGE_NOTIFY_BEGIN_STREAMING 및 MFT_MESSAGE_NOTIFY_START_OF_STREAM 메시지를 전송하여 DTM을 시작합니다. DTM은 MFT_MESSAGE_NOTIFY_BEGIN_STREAMING 전파하고 메시지를 MFT_MESSAGE_NOTIFY_START_OF_STREAM Devproxy 및 Device MFT를 시작합니다.
참고 디바이스 MFT 초기화 대신 스트리밍을 시작할 때 필요한 리소스를 할당합니다.
DTM은 스트리밍 상태 매개 변수를 사용하여 디바이스 MFT의 출력에서 SetOutputStreamState 를 호출합니다. 디바이스 MFT는 해당 출력 스트림에서 스트리밍을 시작합니다. DTM은 유효한 미디어 형식이 설정된 Devproxy 출력 스트림에서 스트리밍을 시작합니다. Devproxy는 샘플을 할당하고 디바이스에서 가져옵니다. 이러한 샘플은 관련 입력 핀의 디바이스 MFT에 공급됩니다. 디바이스 MFT는 이러한 샘플을 처리하고 DeviceSource에 출력을 제공합니다. DeviceSource에서 샘플은 SourceReader를 통해 CaptureEngine으로 흐릅니다.
CaptureEngine은 DeviceSource의 내부 인터페이스를 통해 개별 스트림을 사용하지 않도록 설정하여 개별 스트림을 중지합니다. 이는 SetOutputStreamState를 통해 디바이스 MFT에서 비활성화되는 특정 출력 스트림으로 변환됩니다. 따라서 디바이스 MFT는 METransformInputStreamStateChanged 이벤트를 통해 특정 입력 스트림을 사용하지 않도록 설정할 것을 요청할 수 있습니다. DTM은 이를 해당 Devproxy 스트림에 전파합니다.
디바이스 MFT 자체가 스트리밍 상태인 한 모든 입력 스트림을 요청하여 유효한 DeviceStreamState로 전환할 수 있습니다. 예를 들어 다른 스트림에 영향을 주지 않고 DeviceStreamState_Stop 또는 DeviceStreamState_Run 또는 DeviceStreamState_Pause 보낼 수 있습니다.
그러나 출력 스트림 전환은 캡처 파이프라인에 의해 제어됩니다. 예를 들어 미리 보기, 레코드 및 사진 스트림은 캡처 파이프라인에서 사용하거나 사용하지 않도록 설정됩니다. 출력을 사용하지 않도록 설정한 경우에도 디바이스 MFT 자체가 스트리밍 상태인 한 입력 스트림이 계속 스트리밍될 수 있습니다.
디바이스 MFT의 수명
KS 필터를 만든 후 디바이스 MFT가 로드됩니다. KS 필터를 닫기 전에 언로드됩니다.
파이프라인 관점에서 DeviceSource를 만들 때 디바이스 MFT가 생성되고 DeviceSource가 종료되면 디바이스 MFT가 동기적으로 종료됩니다.
종료를 지원하려면 디바이스 MFT가 IMFShutdown 인터페이스를 지원해야 합니다. 디바이스 MFT-Shutdown>이 호출된 후 디바이스 MFT에 대한 다른 모든 인터페이스 호출은 MF_E_SHUTDOWN 오류를 반환해야 합니다.
메모리 유형
프레임은 카메라 드라이버의 기본 설정에 따라 시스템 메모리 버퍼 또는 DX 메모리 버퍼로 캡처할 수 있습니다. 카메라 드라이버에서 나오는 버퍼는 추가 처리를 위해 디바이스 MFT에 직접 공급됩니다.
Devproxy는 드라이버의 기본 설정에 따라 버퍼를 할당합니다. MF 할당자 API를 사용하여 위치가 아닌 변환에 필요한 출력 핀에 필요한 샘플을 할당하려면 Device MFT가 필요합니다.
스트리밍하는 동안 미디어 형식 변경
SourceReader의 클라이언트는 디바이스 MFT의 출력 스트림에서 노출되는 미디어 형식을 기본적으로 지원되는 미디어 형식으로 볼 수 있습니다. 네이티브 mediatype이 변경되면 SourceReader는 DeviceSource를 통해 Device MFT에 mediatype 알림 호출을 보냅니다. 디바이스 MFT는 해당 스트림의 큐에서 보류 중인 모든 샘플을 플러시하고 적시에 해당 스트림의 새 mediatype으로 전환해야 합니다. 입력 미디어 형식을 변경해야 하는 경우 현재 입력 미디어 형식을 해당 미디어 형식으로 변경해야 합니다. DTM은 디바이스 MFT의 입력 스트림에서 현재 mediatype을 가져오고 각 네이티브 미디어 형식이 변경된 후 Devproxy의 출력 스트림 및 디바이스 MFT의 입력에 설정합니다.
디바이스 MFT의 입력 Mediatype 변경
m x n MFT이므로 출력 스트리밍 핀의 미디어 형식 또는 상태가 변경될 때 입력 스트리밍 핀의 미디어 형식 및 상태 변경에 영향을 미칠 수 있습니다. 특히 다음과 같은 변경이 발생하는 경우:
출력 Mediatype 변경 내용
애플리케이션이 네이티브 mediatype을 변경하면 출력 핀 미디어 형식이 변경되면 캡처 스택을 통해 디바이스 MFT로 계단식으로 이동합니다.
출력 미디어 형식이 변경되면 입력 미디어 형식 변경을 트리거할 수 있습니다. 예를 들어 모든 출력 핀이 720p에서 스트리밍된다고 가정합니다. 이로 인해 720p에서 카메라에서 스트리밍됩니다. 다음으로 레코드 스트림이 네이티브 mediatype을 1080p로 변경한다고 가정합니다. 이 경우 레코드 스트림으로 데이터를 가져온 디바이스 MFT 입력 스트림 중 하나가 해당 미디어 형식을 변경해야 합니다.
출력 핀이 비활성화됨
- 애플리케이션이 두 개 이상의 출력에서 동일한 입력을 공유할 때 디바이스 MFT의 출력 중 하나를 사용하지 않도록 설정하면 최적화를 위해 입력이 mediatype을 변경해야 할 수 있습니다. 예를 들어 1080p 출력 스트림이 중지되고 하나의 입력을 공유하는 다른 모든 스트림이 720p에서 스트리밍되는 경우 입력 스트림은 전원을 절약하고 성능을 향상시키기 위해 mediatype을 720p로 변경해야 합니다.
DTM은 디바이스 MFT에서 METransformInputStreamStateChanged 알림을 처리하여 이러한 조건에서 디바이스 MFT 입력 및 Devproxy 출력의 미디어 형식 및 상태를 변경합니다.
디바이스 MFT의 기본 출력 미디어 형식
디바이스 MFT는 NV12 형식을 사용하여 생성하는 것이 좋습니다. YUY2는 다음으로 가장 좋은 대안입니다. MJPEG 및 RGB 미디어 유형은 권장되지 않습니다.
디바이스 MFT 플러시
디바이스 MFT를 관리하는 동안 다음 두 가지 유형의 플러시가 필요합니다.
전역 플러시
디바이스 MFT 전체 플러시. 이는 일반적으로 DTM이 디바이스 MFT에 스트리밍 중지 메시지를 보내려고 할 때 발생합니다.
디바이스 MFT는 입력 및 출력 큐에서 모든 샘플을 삭제하고 동기적으로 반환해야 합니다.
디바이스 MFT는 새 입력을 요청하거나 사용 가능한 새 출력에 대한 알림을 보내서는 안 됩니다.
로컬 플러시
- 출력 핀별 플러시. 이는 일반적으로 스트림이 중지될 때 발생합니다.
플러시 전에 게시된 모든 이벤트는 디바이스 MFT 관리자에 의해 삭제됩니다. 플러시 후 디바이스 MFT는 내부 METransformHaveOutput 추적 횟수를 다시 설정합니다.
디바이스 MFT 드레이닝
라이브 캡처 원본에서 드레이닝할 필요가 없으므로 디바이스 MFT는 별도의 드레이닝 메시지를 받지 않습니다.
사진 트리거
이 모델에서는 사진 트리거 및 사진 시퀀스 시작 및 중지 트리거를 드라이버에 직접 보내는 대신 디바이스 MFT로 다시 라우팅됩니다. 디바이스 MFT는 트리거를 처리하거나 필요에 따라 카메라 드라이버에 전달합니다.
웜 부팅
DeviceSource는 스트림을 일시 중지 상태로 전환하여 특정 출력 스트림을 웜 시작하려고 합니다. 따라서 DTM은 디바이스 MFT에서 IMFDeviceTransform::SetOutputStreamState 메서드를 호출하여 특정 출력 스트림을 일시 중지 상태로 전환합니다. 그러면 해당 입력 스트림이 일시 중지됩니다. 이를 위해 디바이스 MFT는 METM에 METransformInputStreamStateChanged 를 요청하고 IMFDeviceTransform::SetInputStreamState 메서드를 처리합니다.
가변 사진 시퀀스
이 아키텍처를 통해 사진 시퀀스는 카메라 디바이스 드라이버 및 디바이스 MFT를 사용하여 구현되어 카메라 디바이스 드라이버의 복잡성을 크게 줄입니다. 시작 및 중지 사진 시퀀스 트리거는 디바이스 MFT로 전송되고 사진 시퀀스를 더 쉽게 처리합니다.
사진 확인
디바이스 MFT는 IMFCapturePhotoConfirmation 인터페이스를 통해 사진 확인을 지원합니다. 파이프라인은 IMFGetService::GetService 메서드를 통해 이 인터페이스를 검색합니다.
메타데이터
Devproxy는 드라이버에 메타데이터 버퍼 크기를 쿼리하고 메타데이터에 대한 메모리를 할당합니다. 드라이버에서 오는 메타데이터는 여전히 샘플에서 Devproxy에 의해 설정됩니다. 디바이스 MFT는 샘플의 메타데이터를 사용합니다. 메타데이터는 출력 스트림을 통해 샘플로 전달되거나 사후 처리에만 사용할 수 있습니다.
디바이스 MFT가 다양한 입력을 지원하므로 전용 입력 핀을 메타데이터 또는 대역 외 메타데이터에만 사용할 수 있습니다. 이 핀의 mediatype은 사용자 지정이며 드라이버는 버퍼의 크기와 수를 결정합니다.
이 메타데이터 스트림은 DTM을 넘어 노출됩니다. 디바이스 MFT가 스트리밍을 시작할 때 스트림을 스트리밍 상태로 전환할 수 있습니다. 예를 들어 스트리밍을 위해 출력 스트림을 선택한 경우 디바이스 MFT는 METransformInputStreamStateChanged 이벤트를 사용하여 하나 이상의 비디오 스트림과 메타데이터 스트림을 시작하도록 DTM에 요청할 수 있습니다.
참고: 이 모델의 출력 핀 수와 일치하는 입력 핀 수는 필요하지 않습니다. 메타데이터 또는 3A 전용으로 별도의 핀이 있을 수 있습니다.
DTM(디바이스 변환 관리자) 이벤트 처리
디바이스 변환 관리자 이벤트는 다음 참조 topics 정의됩니다.
IMFDeviceTransform 인터페이스
IMFDeviceTransform 인터페이스는 디바이스 MFT와 상호 작용하도록 정의됩니다. 이 인터페이스는 m 입력 및 n 출력 디바이스 MFT의 관리를 용이하게 합니다. 디바이스 MFT는 다른 인터페이스와 함께 이 인터페이스를 구현해야 합니다.
일반 이벤트 전파
Devproxy(또는 디바이스 내부)에서 이벤트가 발생하면 이를 디바이스 MFT 및 DeviceSource로 전파해야 합니다.
디바이스 MFT 요구 사항
인터페이스 요구 사항
디바이스 MFT는 다음 인터페이스를 지원해야 합니다.
-
이렇게 하면 모든 ksproperties, 이벤트 및 메서드가 디바이스 MFT를 통과할 수 있습니다. 이를 통해 디바이스 MFT는 디바이스 MFT 내에서 이러한 함수 호출을 처리하거나 드라이버에 전달할 수 있습니다. KsEvent 메서드를 처리하는 경우 디바이스 MFT는 다음을 수행해야 합니다.
Device MFT가 KSEVENT_TYPE_ONESHOT 이벤트를 처리하는 경우 KSEVENT_TYPE_ENABLE 수신할 때 핸들을 복제합니다.
이벤트 설정 또는 발생이 완료되면 중복 핸들에서 CloseHandle 을 호출합니다.
디바이스 MFT가 KSEVENT_TYPE_ONESHOT 이외의 이벤트를 처리하는 경우 첫 번째 매개 변수(ks 이벤트 ID ) 및 두 번째 매개 변수(이벤트 길이)가 0으로 설정된 KsEvent 함수를 호출하여 ks 이벤트가 비활성화될 때 중복 핸들에서 KSEVENT_TYPE_ENABLE 수신할 때 핸들을 복제하고 CloseHandle 을 호출해야 합니다. 이벤트 데이터와 길이가 유효합니다. 이벤트 데이터는 특정 ks 이벤트를 고유하게 식별합니다.
디바이스 MFT가 KSEVENT_TYPE_ONESHOT 이외의 이벤트를 처리하는 경우 KSEVENT_TYPE_ENABLE 수신할 때 핸들을 복제해야 하며 모든 매개 변수가 0으로 설정된 KsEvent 함수를 호출하여 ks 이벤트가 비활성화될 때 중복 핸들에서 CloseHandle 을 호출해야 합니다.
알림 요구 사항
디바이스 MFT는 다음 메시지를 사용하여 DTM에 샘플의 가용성, 입력 스트림 상태 변경 등에 대해 알려야 합니다.
스레드 요구 사항
디바이스 MFT는 자체 스레드를 만들면 안 됩니다. 대신 IMFRealTimeClientEx 인터페이스를 통해 DMFT에 전달된 ID에 따라 할당되는 Media Foundation 작업 큐를 사용해야 합니다. 이는 디바이스 MFT에서 실행되는 모든 스레드가 캡처 파이프라인이 실행되는 올바른 우선 순위를 가져오고 스레드 우선 순위 반전을 방지하도록 하기 위한 것입니다.
InputStream 요구 사항
Stream Count
- 디바이스 MFT의 입력 스트림 수는 드라이버에서 지원하는 스트림 수와 동일해야 합니다.
MediaTypes
디바이스 MFT의 입력에서 지원하는 미디어 형식 수와 실제 미디어 형식은 드라이버에서 지원하는 미디어 형식의 수와 유형과 일치해야 합니다.
디바이스 MFT의 입력에서 지원하는 mediatype이 드라이버에서 지원하는 mediatype의 하위 집합인 경우에만 숫자가 다를 수 있습니다.
디바이스 MFT의 드라이버 및 입력에서 지원하는 미디어 형식은 표준 또는 사용자 지정 미디어 형식일 수 있습니다.
디바이스 MFT를 등록하려면
카메라 디바이스 INF에는 디바이스 MFT의 CoClass의 CLSID를 지정하는 다음 디바이스 인터페이스 항목이 있어야 합니다.
[CaptureAvstrm.Device.NTarm.Interfaces]
AddInterface = %KSCATEGORY_VIDEO_CAMERA%, %Capture.FilterDescBack%, Capture.FilterBack
[Capture.FilterBack]
AddReg = Capture.FilterBack.AddReg, PinNames.AddReg
[Capture.FilterBack.AddReg]
HKR,,FriendlyName,,%Capture.FilterDescBack%
HKR,,CameraDeviceMftClsid,,%CameraDeviceMFT.Clsid%
위의 INF 항목으로 인해 다음 레지스트리 키가 입력됩니다.
참고
이는 예제일 뿐입니다(실제 regkey는 아님).
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{E5323777-F976-4f5b-9B55-B94699C46E44}\##?#USB#VID_045E&PID_075D&MI_00#8&23C3DB65&0&0000#{E5323777-F976-4f5b-9B55-B94699C46E44}\#GLOBAL\Device Parameters]
"CLSID"="{17CCA71B-ECD7-11D0-B908-00A0C9223196}"
"FriendlyName"="USB Video Device"
"CameraDeviceMftClsid"="{3456A71B-ECD7-11D0-B908-00A0C9223196}"<<< Device MFT CoClass ID >>>
디바이스 MFT 체인
디바이스 MFT는 Windows에서 카메라 기능을 확장하기 위해 IHV 및 OEM에 권장되는 사용자 모드 플러그 인 메커니즘입니다.
Windows 10 버전 1703 이전에는 카메라 파이프라인이 하나의 DMFT 확장 플러그 인만 지원했습니다.
Windows 10 버전 1703부터 Windows 카메라 파이프라인은 최대 2개의 DMFT가 있는 선택적 DMFT 체인을 지원합니다.
Windows 11 버전 22H2부터 Windows 카메라 파이프라인은 최대 4개의 DMFT가 있는 선택적 DMFT 체인을 지원합니다.
이렇게 하면 OEM 및 IHV가 후처리 카메라 스트림의 형태로 부가 가치를 제공할 수 있는 유연성이 향상됩니다. 예를 들어 디바이스는 IHV DMFT 및 OEM DMFT와 함께 PDMFT를 사용할 수 있습니다.
다음 그림에서는 DMFT 체인과 관련된 아키텍처를 보여 줍니다.
카메라 드라이버에서 DevProxy로 샘플 흐름을 캡처한 다음 DMFT 체인을 통과합니다. 체인의 모든 DMFT는 샘플을 처리할 수 있습니다. DMFT가 샘플을 처리하지 않으려는 경우 다음 DMFT에 샘플을 전달하는 통과로 작동할 수 있습니다.
KsProperty와 같은 컨트롤의 경우 호출이 스트림으로 이동합니다. 체인의 마지막 DMFT는 먼저 호출을 받거나, 호출을 처리하거나 체인의 이전 DMFT에 전달될 수 있습니다.
오류가 DMFT에서 DTM으로 전파된 다음 애플리케이션으로 전파됩니다. IHV/OEM DMFT의 경우 DMFT가 인스턴스화에 실패하면 DTM에 심각한 오류가 발생합니다.
DMFT에 대한 요구 사항:
DMFT의 입력 핀 수는 이전 DMFT의 출력 핀 수와 일치해야 합니다. 그렇지 않으면 초기화 중에 DTM이 실패합니다. 그러나 동일한 DMFT의 입력 및 출력 핀 수는 일치시킬 필요가 없습니다.
DMFT는 인터페이스를 지원해야 합니다. IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl 및 IMFMediaEventGenerator; MFT0이 구성되어 있거나 체인의 다음 DMFT에 IMFTransform 지원이 필요한 경우 IMFTransform을 지원해야 할 수 있습니다.
프레임 서버를 사용하지 않는 64비트 시스템에서는 32비트 및 64비트 DMFT를 모두 등록해야 합니다. USB 카메라가 임의의 시스템에 연결될 수 있다는 점을 감안할 때 "외부"(또는 받은 편지함이 아닌) USB 카메라의 경우 USB 카메라 공급업체는 32비트 및 64비트 DMFT를 모두 제공해야 합니다.
DMFT 체인 구성
카메라 디바이스는 필요에 따라 받은 편지함 USBVideo.INF의 섹션을 사용하는 사용자 지정 INF 파일을 사용하여 DLL에서 DMFT COM 개체를 제공할 수 있습니다.
사용자 지정 에서 INF 파일의 "Interface AddReg" 섹션에서 다음 레지스트리 항목을 추가하여 DMFT CLSID를 지정합니다.
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%
아래 샘플 INF 설정에 표시된 것처럼(%Dmft0.CLSID% 및 % Dmft1.CLSID%를 DMFT에 사용하는 실제 CLSID 문자열로 대체) Windows 10, 버전 1703에서 허용되는 CLSID는 최대 2개이며, 첫 번째 CLSID는 DevProxy에 가장 가깝고 마지막 CLMFT는 체인의 마지막 DMFT입니다.
플랫폼 DMFT CLSID는 {3D096DDE-8971-4AD5-98F9-C74F56492630}입니다.
일부 예제 CameraDeviceMftCLSIDChain 설정:
IHV/OEM DMFT 또는 플랫폼 DMFT 없음
- CameraDeviceMftCLSIDChain = ""(또는 이 레지스트리 항목을 지정할 필요가 없음)
IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
플랫폼 DMFT <-> IHV/OEM DMFT
CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%
다음은 체인에 플랫폼 DMFT 및 DMFT(GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}가 있는 USB 카메라의 결과 레지스트리 키 스크린샷입니다.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
참고
CameraDeviceMftCLSIDChain에는 최대 2개의 CLSID가 있을 수 있습니다.
CameraDeviceMftCLSIDChain이 구성된 경우 레거시 CameraDeviceMftCLSID 설정은 DTM에서 건너뜁니다.
CameraDeviceMftCLSIDChain이 구성되지 않고 레거시 CameraDeviceMftCLSID가 구성된 경우 그러면 체인이 (USB 카메라와 플랫폼 DMFT 및 플랫폼 DMFT에서 지원되는 경우) DevProxy <– Platform DMFT <–>> OEM/IHV DMFT 또는 (카메라가 플랫폼 DMFT 또는 플랫폼 DMFT에서 지원되지 않는 경우) DevProxy <-> OEM/IHV DMFT와 같습니다.
INF 파일 설정 예제:
[USBVideo.Interface.AddReg]
HKR,,CLSID,,%ProxyVCap.CLSID%
HKR,,FriendlyName,,%USBVideo.DeviceDesc%
HKR,,RTCFlags,0x00010001,0x00000010
HKR,,EnablePlatformDmft,0x00010001,0x00000001
HKR,,DisablePlatformDmftFeatures,0x00010001,0x00000001
HKR,,CameraDeviceMftCLSIDChain, 0x00010000,%Dmft0.CLSID%,%Dmft1.CLSID%
Com 개체 및 디바이스 MFT의 MFT 등록
드라이버 COM 개체를 전역적으로 등록하는 대신 이제 드라이버 COM 개체가 디바이스 키 아래에 등록됩니다. 이렇게 하면 컨테이너 내에서 MFT COM을 등록할 수 있으며 전역 레지스트리 키가 생성되지 않으므로 드라이버 패키지 격리가 유지됩니다. 이제 비슷한 이유로 디바이스 키 아래에 MFT가 등록됩니다.
드라이버 INF 변경 내용
디바이스 드라이버를 설치할 때 INF는 이제 디바이스 키 아래에 모든 COM 개체 및 MFT 등록을 만들어야 합니다. MFT 및 COM 등록은 아래와 같이 변경해야 합니다.
MFT 등록:
| 이전 | After |
|---|---|
| INF AddReg: HKCR,MediaFoundation\Transforms\{clsid}\... |
Per-Instance 디바이스 소프트웨어 INF AddReg: HKR,MediaFoundation\Transforms\{clsid}\... |
| 레지스트리 위치: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
레지스트리 위치: software key\MediaFoundation\Transforms\{clsid}\... |
COM 등록:
| 이전 | After |
|---|---|
| INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Per-Instance 디바이스 소프트웨어 INF AddReg: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
OS 버전을 기반으로 차별화하기 위한 INF 구문은 플랫폼 확장과 운영 체제 버전 결합에서 찾을 수 있습니다. 창 11 25300부터 INF는 이러한 새 레지스트리 키를 준수해야 합니다. 이전 OS 버전은 호환성을 위해 기존 레지스트리 키를 계속 사용합니다. INF는 이전 OS 빌드의 이전 위치에 이러한 레지스트리 키를 설치하고 새 OS 빌드를 위한 새 위치에 새 키를 만들어야 합니다. 예를 들어 이전 빌드에서 MFT 등록의 경우 INF는 다음 아래에 키를 만듭니다.
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
새 빌드에서 MFT 등록의 경우 INF는 다음 아래에 키를 만듭니다.
**software key**\MediaFoundation\Transforms\{clsid}\
여기서 소프트웨어 키 는 디바이스의 소프트웨어 키를 나타냅니다. 디바이스의 소프트웨어 키 열기를 참조하세요.
다양한 OS 버전을 대상으로 하는 구문 예제는 아래에서 확인할 수 있습니다.
[Manufacturer]
%Msft% = Msft, NTamd64,NTamd64.10.0...25300
; -------------- ;
; Models Section ;
; -------------- ;
; Targets old builds
[Msft.NTamd64]
%DeviceDesc% = ExampleDDInstall_Old, ExampleHardwareId
[ExampleDDInstall_Old]
AddReg = MFT_Registration_Old
[MFT_Registration_Old]
; INF work for older build here
; Windows 10 build with build number equal to or greater than 25300
[msft.ntamd64.10.0...25300]
%DeviceDesc% = ExampleDDInstall_New, ExampleHardwareId
[ExampleDDInstall_new]
AddReg = MFT_Registration_new
[MFT_Registration_new]
; INF work for newer build here
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기