Panduan desain MFT perangkat

2024-06-27

Tumpukan pengambilan video di Windows mendukung ekstensi mode pengguna dalam bentuk DMFT. Ini adalah komponen ekstensi per perangkat yang disediakan IHV, dan sisipan alur penangkapan sebagai transformasi pertama, pasca-pengambilan. DMFT menerima bingkai pasca-diproses dari perangkat. Operasi pasca pemrosesan lebih lanjut pada bingkai dapat dilakukan di dalam DMFT. DMFT dapat menerima bingkai dari semua aliran perangkat dan dapat mengekspos sejumlah aliran output sesuai persyaratan.

Artikel ini menguraikan desain ekstensi di seluruh perangkat yang berjalan dalam mode pengguna yang dapat digunakan untuk melakukan pasca-pemrosesan umum untuk semua aliran.

Terminologi

Persyaratan	Deskripsi
KS	Driver Streaming Kernel
AVStream	Model driver Streaming Video Audio
Filter	Objek yang mewakili instans perangkat
MFT Perangkat	Ekstensi driver pengambilan mode pengguna yang disediakan oleh IHV
Devproxy	MF <-> Marshaler AVStream
DTM	Device Transform Manager yang mengelola devproxy dan Device MFT. Mewakili perangkat dalam alur MF.

Tujuan Desain

Ekstensi mode pengguna di seluruh filter perangkat yang memiliki masa pakai yang sama dengan Filter Perangkat
Mendukung sejumlah input yang berasal dari perangkat
Mendukung sejumlah output (persyaratan saat ini adalah tiga aliran: pratinjau, rekaman, dan foto)
Merutekan semua kontrol perangkat ke Device MFT (yang secara opsional menangani atau meneruskannya ke perangkat)
Pemrosesan posting paralel dari aliran yang diambil
Izinkan pemrosesan 3A independen dari kecepatan bingkai
Izinkan metadata dari satu aliran dibagikan di antara aliran lainnya
Akses ke sumber daya GPU
Akses ke Antrean Kerja MF MMCSS
Akses ke Alokator MF
Antarmuka sederhana (mirip dengan MFT)
Arsitektur internal yang fleksibel untuk ekstensibilitas IHV/OEM

Batasan desain

Tidak ada perubahan di permukaan Capture API
Selesaikan kompatibilitas mundur. Misalnya, tidak ada regresi saat bekerja dengan aplikasi dan skenario warisan.

Menangkap arsitektur tumpukan

Artikel ini menjelaskan dukungan untuk ekstensi mode pengguna di seluruh filter ke driver pengambilan. Komponen ini memiliki akses ke API MF, kumpulan utas, GPU, dan sumber daya ISP. Ekstensi lebar filter memberikan fleksibilitas memiliki sejumlah aliran antara dirinya sendiri dan filter Ks perangkat. Fleksibilitas ini memungkinkan komunikasi di luar band yang mulus antara ekstensi mode pengguna dan driver yang dapat digunakan untuk metadata khusus dan aliran pemrosesan 3A.

menangkap arsitektur tumpukan.

arsitektur mft perangkat.

Device Transform Manager (DTM)

Tumpukan tangkapan memperkenalkan komponen baru yang disediakan sistem, Device Transform Manager (DTM). Ini berada di dalam DeviceSource dan mengelola Devproxy MFT dan Device MFT. DTM melakukan negosiasi MediaType, penyebaran sampel, dan semua penanganan peristiwa MFT. Ini juga mengekspos antarmuka IMFTransform ke DeviceSource dan antarmuka privat lain yang diperlukan DeviceSource untuk mengelola aliran perangkat. Komponen ini mengabstraksi Devproxy dan Device MFT dari alur. Alur hanya melihat DTM sebagai perangkat dan aliran keluar dari DTM saat perangkat mengalir.

Devproxy

Devproxy adalah MFT asinkron yang melakukan marsekal perintah dan bingkai video antara driver kamera AVStream dan Media Foundation. Ini disediakan oleh Windows dan mendukung n jumlah output dari driver kamera. Selain itu, ini memiliki alokator untuk semua pin yang diekspos oleh perangkat.

MFT Perangkat

MFT perangkat adalah ekstensi mode pengguna untuk driver pengambilan. Ini MFT asinkron m x n . Ini diinstal pada sistem dengan driver tangkapan dan disediakan oleh vendor driver tangkapan.

Jumlah aliran input MFT Perangkat harus sama dengan jumlah pin Ks yang diekspos oleh perangkat. Jenis media yang didukung oleh aliran input MFT Perangkat harus sama dengan mediatipe yang diekspos oleh pin KS.

Jumlah aliran output yang diekspos oleh Device MFT adalah aliran yang dilihat oleh DeviceSource dan menangkap tumpukan, menangkap API dan aplikasi dan dapat berupa satu, dua, atau tiga aliran. Jumlah aliran input dan output MFT Perangkat tidak perlu sama. Selain itu, aliran input dan output tidak perlu memiliki jenis media yang sama, dan biasanya memiliki jenis media yang berbeda. Jumlah mediatipe juga tidak perlu cocok.

Pin Ks pertama yang diwakili dalam mode pengguna oleh aliran output Devproxy dikaitkan dengan aliran input pertama MFT Perangkat, Ks Pin kedua yang diwakili dalam mode pengguna oleh aliran output Devproxy dengan aliran input kedua MFT Perangkat, dan sebagainya.

MFT perangkat diberikan penunjuk ke Devproxy, perangkat DX, dan ID Antrean Kerja MF. Bingkai yang keluar dari perangkat disalurkan langsung ke input MFT Perangkat yang sesuai sebagai Sampel MF. Dengan semua ini, Device MFT dapat memposting proses sampel yang diambil dan menyajikan sampel ke pratinjau, rekaman, dan pin foto.

Semua perintah dan kontrol yang masuk ke perangkat akan dialihkan ke MFT Perangkat. MFT perangkat menangani kontrol atau meneruskannya ke driver melalui Devproxy. Ini menyederhanakan penanganan perintah oleh tumpukan driver pengambilan.

Gambaran umum fungsi

Pada inisialisasi alur pengambilan, jika ada MFT Perangkat untuk perangkat, DeviceSource membuat instans DTM. Ini meneruskan instans Devproxy yang mewakili perangkat ke rutinitas inisialisasi DTM. DTM membuat kokreasi MFT Perangkat dan melakukan validasi dasar, misalnya, memverifikasi jumlah pin output Devproxy sama dengan jumlah pin input MFT Perangkat, dukungan untuk antarmuka wajib, dan sebagainya.

DeviceSource meminta DTM untuk mendapatkan mediatipe output yang didukung. DTM mendapatkan ini dari pin output MFT Perangkat. DeviceSource mengekspos Deskriptor Presentasi dan Deskriptor Aliran berdasarkan informasi ini ke alur pengambilan.

SourceReader menggunakan mediatipe DeviceSource yang diekspos dan mengatur mediatipe default pada setiap aliran. Pada gilirannya, DeviceSource mengatur mediatipe default pada aliran output DTM. DTM mengatur mediatype pada aliran output MFT Perangkat menggunakan metode SetOutputStreamState .

Saat SetOutputStreamState dipanggil, Device MFT memposting pesan ke DTM untuk mengubah mediatype aliran inputnya berdasarkan mediatipe output yang dipilih dan menunggu. Sebagai respons terhadap pesan ini, DTM meminta mediatipe input pilihan untuk aliran input MFT Perangkat menggunakan GetPreferredInputStreamState. Ini mengatur mediatype pada aliran output Devproxy yang sesuai. Jika berhasil, maka DTM mengatur jenis media yang sama ke aliran input MFT Perangkat menggunakan SetInputStreamState. Setelah menerima panggilan ini, MFT Perangkat menyelesaikan SetOutputStreamState.

CaptureEngine memilih aliran individual dengan mengaktifkan aliran tertentu di DeviceSource. Ini disebarkan ke MFT Perangkat oleh DTM melalui panggilan SetOutputStreamState . MFT perangkat menempatkan aliran output tertentu dalam status yang diminta. Seperti disebutkan di atas, Device MFT juga memberi tahu DTM tentang aliran input yang diperlukan yang perlu diaktifkan. Ini menghasilkan DTM menyebarkan pilihan aliran ke Devproxy. Pada akhir proses ini, semua aliran yang diperlukan, di Devproxy dan Device MFT, siap untuk melakukan streaming.

SourceReader memulai DeviceSource saat CaptureEngine memanggil ReadSample. Pada gilirannya, DeviceSource memulai DTM dengan mengirim pesan MFT_MESSAGE_NOTIFY_BEGIN_STREAMING dan MFT_MESSAGE_NOTIFY_START_OF_STREAM yang menunjukkan dimulainya alur. DTM memulai Devproxy dan Device MFT dengan menyebarkan pesan MFT_MESSAGE_NOTIFY_BEGIN_STREAMING dan MFT_MESSAGE_NOTIFY_START_OF_STREAM.

Catatan

Alokasikan sumber daya yang diperlukan saat memulai streaming alih-alih Inisialisasi MFT Perangkat.

DTM memanggil SetOutputStreamState pada output Device MFT dengan parameter status streaming. MFT perangkat mulai mengalir di aliran output tersebut. DTM memulai streaming pada aliran output Devproxy yang memiliki set mediatype yang valid. Devproxy mengalokasikan sampel dan mengambilnya dari perangkat. Sampel ini disalurkan ke MFT Perangkat dalam pin input yang relevan. MFT perangkat memproses sampel ini dan memberikan output ke DeviceSource. Dari DeviceSource, sampel mengalir melalui SourceReader ke CaptureEngine.

CaptureEngine menghentikan aliran individual dengan menonaktifkan aliran individual melalui antarmuka internal di DeviceSource. Ini diterjemahkan ke dalam streaming output tertentu yang menonaktifkan pada Device MFT melalui SetOutputStreamState. Pada gilirannya, Device MFT dapat meminta untuk menonaktifkan aliran input tertentu melalui peristiwa METransformInputStreamStateChanged . DTM menyebarluaskan ini ke aliran Devproxy yang sesuai.

Selama MFT Perangkat itu sendiri dalam status streaming, ia dapat meminta aliran input apa pun untuk transisi ke salah satu DeviceStreamState yang valid. Misalnya, dapat mengirimkannya ke DeviceStreamState_Stop atau DeviceStreamState_Run atau DeviceStreamState_Pause, dan sebagainya, tanpa memengaruhi aliran lain.

Namun, transisi aliran output dikontrol oleh alur pengambilan. Misalnya, pratinjau, rekaman, dan aliran foto diaktifkan atau dinonaktifkan oleh alur pengambilan. Bahkan ketika output dinonaktifkan, aliran input masih dapat di-streaming selama MFT Perangkat itu sendiri dalam status streaming.

urutan pratinjau alur mft perangkat.

perangkat mft mengambil urutan foto.

Masa Pakai MFT Perangkat

MFT perangkat dimuat setelah Filter KS dibuat. Ini dibongkar sebelum Filter KS ditutup.

Dari perspektif alur, saat DeviceSource dibuat, MFT Perangkat dibuat, dan ketika DeviceSource dimatikan, MFT Perangkat dimatikan secara sinkron.

Untuk mendukung matikan, MFT Perangkat harus mendukung antarmuka IMFShutdown . Setelah Device MFT-Shutdown> dipanggil, panggilan antarmuka lain ke MFT Perangkat harus mengembalikan kesalahan MF_E_SHUTDOWN.

Jenis memori

Bingkai dapat ditangkap ke dalam buffer memori sistem, atau buffer memori DX, sesuai preferensi driver kamera. Buffer apa pun yang keluar dari driver kamera langsung dimasukkan ke MFT Perangkat untuk diproses lebih lanjut.

Devproxy mengalokasikan buffer berdasarkan preferensi driver. Kami memerlukan MFT Perangkat untuk menggunakan API alokator MF untuk mengalokasikan sampel yang diperlukan untuk pin outputnya untuk transformasi noninplace.

Mediatype berubah saat streaming

Klien SourceReader dapat melihat jenis media yang diekspos oleh aliran output MFT Perangkat sebagai mediatipe yang didukung secara asli. Ketika mediatipe asli diubah, SourceReader mengirimkan panggilan pemberitahuan mediatype ke MFT Perangkat melalui DeviceSource. Ini adalah tanggung jawab MFT Perangkat untuk menghapus semua sampel yang tertunda dari antrean aliran tersebut dan beralih ke mediatipe baru pada aliran tersebut secara tepat waktu. Jika ada kebutuhan untuk mengubah mediatipe input, maka harus mengubah mediatipe input saat ini menjadi yang itu. DTM mendapatkan jenis media saat ini dari aliran input MFT Perangkat dan mengaturnya pada aliran output Devproxy dan input MFT Perangkat setelah setiap perubahan mediatipe asli.

Input Perubahan Mediatype di Device MFT

Karena ini adalah m x n MFT, mungkin ada dampak pada mediatipe pin streaming input dan perubahan status saat mediatipe pin streaming output atau perubahan status. Khususnya ketika perubahan berikut terjadi:

Perubahan Mediatype Output
- Ketika aplikasi mengubah mediatipe asli, aplikasi melakukan cascades melalui tumpukan tangkapan ke Device MFT sebagai mediatipe pin output berubah.
- Ketika mediatipe output berubah, itu dapat memicu perubahan mediatipe input. Misalnya, asumsikan semua pin output streaming pada 720p. Ini menghasilkan streaming dari kamera pada 720p. Selanjutnya, asumsikan aliran rekaman mengubah mediatipe aslinya menjadi 1080p. Dalam hal ini, salah satu aliran input MFT Perangkat yang mengambil data ke aliran rekaman harus mengubah jenis medianya.
Pin output dinonaktifkan
- Ketika aplikasi menonaktifkan salah satu output MFT Perangkat ketika input yang sama dibagikan oleh lebih dari satu output, untuk pengoptimalan, input mungkin harus mengubah jenis media. Misalnya, jika aliran output 1080p berhenti, dan semua aliran lainnya, berbagi satu input, dialirkan pada 720p, maka aliran input harus mengubah mediatype-nya menjadi 720p untuk menghemat daya dan meningkatkan performa.

DTM menangani pemberitahuan METransformInputStreamStateChanged dari Device MFT untuk mengubah mediatype dan status pada input MFT Perangkat dan output Devproxy dalam kondisi ini.

Mediatipe output pilihan MFT Perangkat

Sebaiknya MFT Perangkat menghasilkan jenis media output menggunakan format NV12. YUY2 adalah alternatif terbaik berikutnya. Jenis media MJPEG dan RGB tidak disarankan.

Flush Device MFT

Dua jenis pembilasan diperlukan saat mengelola MFT Perangkat:

Flush global
- Perangkat MFT-wide flush. Ini biasanya terjadi ketika DTM akan mengirim pesan stop streaming ke Device MFT.
- MFT perangkat diharapkan untuk menghilangkan semua sampel dari antrean input dan outputnya dan kembali secara sinkron.
- MFT perangkat tidak boleh meminta input baru atau mengirim pemberitahuan pada output baru yang tersedia.
Flush lokal
- Keluaran flush khusus pin. Ini biasanya terjadi ketika aliran dihentikan.

Semua peristiwa yang diposting sebelum flush dihilangkan oleh Device MFT Manager. Setelah memerah, MFT Perangkat mengatur ulang jumlah pelacakan METransformHaveOutput internalnya.

Pengurasan MFT Perangkat

MFT perangkat tidak akan menerima pesan pengurasan terpisah karena tidak perlu dikosongkan di sumber pengambilan langsung.

Pemicu foto

Dalam model ini, alih-alih mengirim pemicu foto dan urutan foto dimulai dan menghentikan pemicu langsung ke driver, mereka dialihkan ke Device MFT. MFT perangkat menangani pemicu atau meneruskannya ke driver kamera seperlunya.

Awal yang hangat

DeviceSource mencoba menghangatkan memulai aliran output tertentu dengan mentransisikan aliran ke status jeda. Pada gilirannya, DTM memanggil metode IMFDeviceTransform::SetOutputStreamState pada MFT Perangkat untuk melakukan transisi aliran output tertentu ke status jeda. Ini menghasilkan aliran input yang sesuai untuk dimasukkan ke dalam jeda. Ini dicapai oleh MFT Perangkat dengan meminta METransformInputStreamStateChanged ke DTM dan menangani metode IMFDeviceTransform::SetInputStreamState .

Urutan foto variabel

Dengan arsitektur ini, urutan foto diimplementasikan dengan driver perangkat kamera dan Device MFT, sangat mengurangi kompleksitas driver perangkat kamera. Pemicu urutan foto mulai dan berhenti dikirim ke Device MFT dan menangani urutan foto dengan lebih mudah.

Konfirmasi foto

Device MFT mendukung konfirmasi foto melalui antarmuka IMFCapturePhotoConfirmation . Alur mengambil antarmuka ini melalui metode IMFGetService::GetService .

Metadata

Devproxy meminta driver untuk ukuran buffer metadata dan mengalokasikan memori untuk metadata. Metadata yang berasal dari driver masih ditetapkan oleh Devproxy pada sampel. MFT perangkat menggunakan metadata sampel. Metadata dapat diteruskan dengan sampel melalui aliran outputnya atau digunakan untuk pemrosesan postingannya.

Dengan MFT Perangkat yang mendukung sejumlah input, pin input khusus dapat digunakan hanya untuk metadata atau metadata di luar band. Jenis media untuk pin ini kustom dan driver memutuskan ukuran dan jumlah buffer.

Aliran metadata ini diekspos di luar DTM. Aliran dapat dimasukkan ke dalam status streaming saat MFT Perangkat mulai streaming. Misalnya, ketika aliran output dipilih untuk streaming, MFT Perangkat dapat meminta DTM untuk memulai satu atau beberapa aliran video, dan aliran metadata juga, menggunakan peristiwa METransformInputStreamStateChanged .

Catatan: Tidak ada persyaratan untuk jumlah pin input agar sesuai dengan jumlah pin output dalam model ini. Mungkin ada pin terpisah yang didedikasikan untuk metadata atau 3A.

Penanganan peristiwa Device Transform Manager (DTM)

Peristiwa Device Transform Manager didefinisikan dalam artikel referensi berikut:

Antarmuka IMFDeviceTransform

Antarmuka IMFDeviceTransform didefinisikan untuk berinteraksi dengan MFT Perangkat. Antarmuka ini memfasilitasi manajemen input m dan MFT Perangkat output n . Bersama dengan antarmuka lain, MFT Perangkat harus mengimplementasikan antarmuka ini.

Penyebaran acara umum

Ketika peristiwa terjadi di Devproxy (atau di dalam perangkat), kita perlu menyebarluaskan itu ke Device MFT dan ke DeviceSource.

Persyaratan MFT perangkat

Persyaratan antarmuka

MFTs perangkat harus mendukung antarmuka berikut:

IMFDeviceTransform
IKsControl
- Ini memungkinkan semua ksproperti, peristiwa, dan metode untuk melalui MFT Perangkat. Ini memberi MFT Perangkat kemampuan untuk menangani panggilan fungsi ini di dalam MFT Perangkat atau hanya meneruskannya ke driver. Dalam kasus di mana ia menangani metode KsEvent, maka MFT Perangkat harus melakukan langkah-langkah berikut:
  - Jika Device MFT menangani peristiwa KSEVENT_TYPE_ONESHOT apa pun, maka perangkat akan menduplikasi handel saat menerima KSEVENT_TYPE_ENABLE.
  - Setelah selesai mengatur atau menaikkan acara, itu memanggil CloseHandle pada handel duplikat.
  - Jika Device MFT menangani peristiwa non-KSEVENT_TYPE_ONESHOT, maka harus menduplikasi handel saat menerima KSEVENT_TYPE_ENABLE dan memanggil CloseHandle pada handel duplikat saat peristiwa ks dinonaktifkan dengan memanggil fungsi KsEvent dengan parameter pertama (ID peristiwa ks) dan parameter kedua (panjang peristiwa) diatur ke nol. Data peristiwa dan panjangnya valid. Data peristiwa secara unik mengidentifikasi peristiwa ks tertentu.
  - Jika Device MFT menangani peristiwa non-KSEVENT_TYPE_ONESHOT, maka harus menduplikasi handel ketika menerima KSEVENT_TYPE_ENABLE dan harus memanggil CloseHandle pada handel duplikat saat peristiwa ks dinonaktifkan dengan memanggil fungsi KsEvent dengan semua parameter yang diatur ke nol.
IMFRealTimeClientEx
IMFMediaEventGenerator
IMFShutdown
IMFSampleAllocatorControl

Persyaratan pemberitahuan

MFTs perangkat harus menggunakan pesan berikut untuk memberi tahu DTM tentang ketersediaan sampel, setiap perubahan status aliran input, dan sebagainya.

Persyaratan utas

MFT perangkat tidak boleh membuat utasnya sendiri. Sebagai gantinya, ia harus menggunakan Antrean Kerja Media Foundation, yang dialokasikan berdasarkan ID yang diteruskan ke DMFT melalui antarmuka IMFRealTimeClientEx . Ini untuk memastikan bahwa semua utas yang berjalan di MFT Perangkat mendapatkan prioritas yang benar di mana alur tangkapan berjalan dan menghindari inversi prioritas utas.

Persyaratan InputStream

Jumlah aliran

Jumlah aliran input dalam MFT Perangkat harus sama dengan jumlah aliran yang didukung oleh driver.

MediaTypes

Jumlah jenis media dan jenis media aktual yang didukung oleh input MFT Perangkat harus cocok dengan jumlah dan jenis mediatipe yang didukung oleh driver.
Jumlahnya bisa berbeda hanya jika mediatipe yang didukung oleh input MFT Perangkat adalah subset dari jenis media yang didukung oleh driver.
Jenis media yang didukung oleh driver dan input MFT Perangkat bisa berupa mediatipe standar atau kustom.

Cara mendaftarkan MFT Perangkat

INF perangkat kamera harus memiliki entri antarmuka perangkat berikut yang menentukan CLSID CoClass dari MFT Perangkat.

[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%

Entri INF ini mengakibatkan kunci registri berikut dimasukkan:

Catatan

Ini adalah contoh saja (bukan regkey aktual)

[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 >>>

Rantai MFT perangkat

Device MFT adalah mekanisme plugin mode pengguna yang direkomendasikan untuk IHV dan OEM untuk memperluas fungsionalitas kamera di Windows.

Sebelum Windows 10, versi 1703, alur kamera hanya mendukung satu plugin ekstensi DMFT.

Dimulai dengan Windows 10, versi 1703, alur kamera Windows mendukung rantai opsional DMFTs dengan maksimum dua DMFTs.

Mulai Windows 11, versi 22H2, alur kamera Windows mendukung rantai DMFTs opsional dengan maksimum empat DMFT.

Ini memberikan fleksibilitas yang lebih besar bagi OEM dan IHV untuk memberikan nilai tambah dalam bentuk aliran kamera pasca pemrosesan. Misalnya, perangkat dapat menggunakan PDMFT bersama dengan IHV DMFT dan OEM DMFT.

Gambar berikut mengilustrasikan arsitektur yang melibatkan rantai DMFTs.

Rantai DMFT.

Ambil sampel mengalir dari driver kamera ke DevProxy, lalu melalui rantai DMFT. Setiap DMFT dalam rantai memiliki kesempatan untuk memproses sampel. Jika DMFT tidak ingin memproses sampel, DMFT dapat bertindak sebagai pass-through hanya meneruskan sampel ke DMFT berikutnya.

Untuk kontrol seperti KsProperty, panggilan akan naik streaming - DMFT terakhir dalam rantai mendapatkan panggilan terlebih dahulu. Panggilan dapat ditangani di sana atau diteruskan ke DMFT sebelumnya dalam rantai.

Kesalahan disebarluaskan dari DMFT ke DTM kemudian ke aplikasi. Untuk DMFTs IHV/OEM, salah satu DMFT gagal membuat instans adalah kesalahan fatal untuk DTM.

Persyaratan tentang DMFTs:

Jumlah pin input DMFT harus cocok dengan jumlah pin output DMFT sebelumnya. Jika tidak, DTM akan gagal selama inisialisasi. Namun, jumlah pin input dan output dari DMFT yang sama tidak perlu cocok.
DMFT perlu mendukung antarmuka - IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl, dan IMFMediaEventGenerator; IMFTransform mungkin perlu didukung jika ada MFT0 yang dikonfigurasi atau DMFT berikutnya dalam rantai memerlukan dukungan IMFTransform.
Pada sistem 64-bit yang tidak menggunakan Frame Server, DMFTs 32-bit dan 64-bit harus didaftarkan. Mengingat bahwa kamera USB mungkin dicolokkan ke dalam sistem arbitrer, untuk kamera USB "eksternal" (atau noninbox), vendor kamera USB harus menyediakan DMFT 32-bit dan 64-bit.

Mengonfigurasi rantai DMFT

Perangkat kamera dapat secara opsional menyediakan objek DMFT COM di DLL menggunakan file INF kustom yang menggunakan bagian kotak masuk USBVideo.INF.

Dalam kustom . Bagian "Interface AddReg" file INF, tentukan CLSID DMFT dengan menambahkan entri registri berikut:

CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%

Seperti yang ditunjukkan pada contoh pengaturan INF di bawah ini (ganti %Dmft0.CLSID% dan % Dmft1.CLSID% dengan string CLSID aktual yang Anda gunakan untuk DMFTs Anda), ada maksimum 2 CLSID yang diizinkan di Windows 10, versi 1703, dan yang pertama paling dekat dengan DevProxy dan yang terakhir adalah DMFT terakhir dalam rantai.

Platform DMFT CLSID adalah {3D096DDE-8971-4AD5-98F9-C74F56492630}.

Beberapa contoh pengaturan CameraDeviceMftCLSIDChain :

Tidak ada DMFT IHV/OEM atau Platform DMFT
- CameraDeviceMftCLSIDChain = "" (atau tidak perlu menentukan entri registri ini)
IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
Platform DMFT <-> IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%
- Berikut adalah cuplikan layar kunci registri hasil untuk kamera USB dengan Platform DMFT dan DMFT (dengan GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) dalam rantai.

Rantai DMFT editor registri.

IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,

Catatan

CameraDeviceMftCLSIDChain dapat memiliki maksimum 2 CLSID.

Jika CameraDeviceMftCLSIDChain dikonfigurasi, pengaturan CameraDeviceMftCLSID warisan dilewati oleh DTM.

Jika CameraDeviceMftCLSIDChain tidak dikonfigurasi dan CameraDeviceMftCLSID warisan dikonfigurasi, maka rantai akan terlihat seperti (jika kamera USB-nya dan didukung oleh Platform DMFT dan Platform DMFT diaktifkan) DevProxy <–> Platform DMFT <–> OEM/IHV DMFT atau (jika kamera tidak didukung oleh Platform DMFT atau Platform DMFT dinonaktifkan) DevProxy <-> OEM/IHV DMFT.

Contoh pengaturan file 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%

Objek com dan pendaftaran MFT MFTs Perangkat

Daripada mendaftarkan objek COM driver secara global, objek COM driver terdaftar di bawah kunci perangkat. Ini memungkinkan pendaftaran MFT COM dari dalam kontainer dan mencegah kunci registri global dibuat, sehingga mempertahankan isolasi paket driver. MFTs terdaftar di bawah kunci perangkat juga karena alasan serupa.

Perubahan pada INF driver

Setelah penginstalan driver perangkat, INF sekarang harus membuat semua objek COM dan pendaftaran MFT di bawah kunci perangkat. Pendaftaran MFT dan COM harus berubah seperti yang ditunjukkan di sini:

Pendaftaran MFT

Sebelumnya	Sesudahnya
INF AddReg: HKCR, MediaFoundation\Transforms\{clsid}\...	Perangkat lunak perangkat per instans INF AddReg: HKR, MediaFoundation\Transforms\{clsid}\...
Lokasi Registri: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\...	Lokasi Registri: software key\MediaFoundation\Transforms\{clsid}\...

Pendaftaran COM

Di Windows 26100 dan yang lebih baru, semua pendaftaran COM untuk MFT Perangkat harus menggunakan direktif AddComServer/AddComClass di INF. Contoh sintaks ditampilkan di sini:

[AvsCamera.COM]
AddComServer = AvsCameraMFT,,AvsCamera.COMInstall

[AvsCamera.COMInstall]
ServerType = 1; in-proc
ServerBinary = %13%\AvsCameraDMFT.dll
AddComClass = %DMFT.CLSID%,, AvsCamera.COMClassInstall


[AvsCamera.COMClassInstall]
ThreadingModel = Both
Description = %AvsCamera.ComServerDescription%

Versi Pendaftaran MFT COM Perangkat sebelumnya menggunakan AddReg untuk menginstal kelas COM secara manual.

Sebelumnya	Sesudahnya
INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\...	Perangkat lunak perangkat per instans INF AddReg: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\...

Sintaks INF untuk membedakan berdasarkan versi OS dapat ditemukan di Menggabungkan ekstensi platform dengan versi sistem operasi. Mulai dari Jendela 11 25300, INF harus sesuai dengan kunci registri baru ini. Versi OS yang lebih lama menggunakan kunci registri tradisional untuk kompatibilitas. INF harus menyiapkan kunci registri ini di lokasi lama pada build OS yang lebih lama dan membuat kunci baru di lokasi baru mereka untuk build OS yang lebih baru. Misalnya, untuk pendaftaran MFT pada build yang lebih lama, INF membuat kunci di bawah entri registri berikut:

HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\

Untuk pendaftaran MFT pada build baru, INF membuat kunci di bawah entri registri berikut:

**software key**\MediaFoundation\Transforms\{clsid}\

Entri ini menentukan di mana kunci perangkat lunak mewakili kunci perangkat lunak perangkat.

Untuk informasi selengkapnya, lihat Membuka kunci perangkat lunak perangkat.

Contoh sintaks menargetkan versi OS yang berbeda diperlihatkan di sini:

[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

Bagikan melalui

Panduan desain MFT perangkat

Terminologi

Tujuan Desain

Batasan desain

Menangkap arsitektur tumpukan

Device Transform Manager (DTM)

Devproxy

MFT Perangkat

Gambaran umum fungsi

Masa Pakai MFT Perangkat

Jenis memori

Mediatype berubah saat streaming

Input Perubahan Mediatype di Device MFT

Mediatipe output pilihan MFT Perangkat

Flush Device MFT

Pengurasan MFT Perangkat

Pemicu foto

Awal yang hangat

Urutan foto variabel

Konfirmasi foto

Metadata

Penanganan peristiwa Device Transform Manager (DTM)

Antarmuka IMFDeviceTransform

Penyebaran acara umum

Persyaratan MFT perangkat

Persyaratan antarmuka

Persyaratan pemberitahuan

Persyaratan utas

Persyaratan InputStream

Jumlah aliran

MediaTypes

Cara mendaftarkan MFT Perangkat

Rantai MFT perangkat

Mengonfigurasi rantai DMFT

Objek com dan pendaftaran MFT MFTs Perangkat

Perubahan pada INF driver

Pendaftaran MFT

Pendaftaran COM

Saran dan Komentar

Sumber Daya Tambahan: