Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Tumpukan pengambilan video di Windows mendukung ekstensi mode pengguna dalam bentuk DMFT. Ini adalah komponen ekstensi per-perangkat yang disediakan oleh IHV, dan alur penangkapan memasukkannya sebagai transformasi pertama setelah pengambilan. DMFT menerima bingkai pasca-diproses dari perangkat. Operasi pasca pemrosesan lebih lanjut pada bingkai dapat dilakukan di dalam DMFT. DMFT dapat menerima frame dari semua aliran perangkat dan dapat menampilkan sejumlah aliran keluaran sesuai kebutuhan.
Artikel ini menguraikan desain ekstensi yang mencakup seluruh perangkat yang berjalan dalam mode pengguna dan dapat digunakan untuk melakukan pemrosesan lanjutan umum untuk semua aliran.
Terminologi
| Istilah | Deskripsi |
|---|---|
| KS | Driver Kernel Streaming |
| AVStream | Model Driver Streaming Audio Video |
| Filter | Objek yang mewakili instans perangkat |
| Perangkat MFT | Ekstensi driver penangkapan mode pengguna yang disediakan oleh Penyedia Perangkat Keras Independen |
| Devproxy | MF <-> AVStream Marshaler |
| DTM | Device Transform Manager yang mengelola devproxy dan Device MFT. Mewakili perangkat dalam alur MF. |
Tujuan desain
Ekstensi modus pengguna yang berlaku sepanjang filter perangkat dan 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 secara independen dari frame rate
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
Kompatibilitas mundur penuh. Misalnya, tidak ada regresi saat bekerja dengan aplikasi dan skenario warisan.
Menangkap arsitektur tumpukan
Artikel ini menjelaskan dukungan untuk ekstensi mode pengguna yang khusus untuk setiap filter pada driver capture. Komponen ini memiliki akses ke API MF, kumpulan utas, GPU, dan sumber daya ISP. Ekstensi lebar filter memberikan fleksibilitas untuk memiliki sejumlah aliran antara dirinya sendiri dan filter perangkat Ks. 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.
Manajer Transformasi Perangkat (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 mengalihkan 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.
Perangkat MFT
MFT perangkat adalah ekstensi mode pengguna untuk driver pengambilan. Ini adalah 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 jenis media yang diekspos oleh pin KS.
Jumlah aliran output yang diekspos oleh Device MFT adalah aliran yang terlihat oleh DeviceSource, tumpukan penangkapan, API penangkapan, dan aplikasi. Aliran tersebut dapat berupa satu, dua, atau tiga aliran. Jumlah aliran input dan output "Device MFT" 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 dari MFT Perangkat. Pin Ks kedua yang diwakili dalam mode pengguna oleh aliran output Devproxy dikaitkan dengan aliran input kedua dari MFT Perangkat, dan seterusnya.
MFT perangkat diberi penunjuk ke Devproxy, perangkat DX, dan ID Antrean Kerja MF. Bingkai yang keluar dari perangkat disalurkan langsung ke input Device MFT yang sesuai sebagai MF Samples. 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 Device MFT. MFT perangkat menangani kontrol atau meneruskannya ke driver melalui Devproxy. Ini menyederhanakan penanganan perintah oleh rangkaian driver penangkapan.
Gambaran umum fungsi
Pada inisialisasi rangkaian penangkapan, jika ada Device MFT untuk perangkat, DeviceSource membuat instans DTM. Proses ini meneruskan instans Devproxy, yang mewakili perangkat tersebut, ke dalam rutinitas inisialisasi DTM. DTM membuat bersama Perangkat MFT dan melakukan validasi dasar, misalnya memverifikasi bahwa jumlah pin output Devproxy sama dengan jumlah pin input Perangkat MFT, mendukung antarmuka wajib, dan sebagainya.
DeviceSource meminta DTM untuk mendapatkan mediatipe output yang didukung. DTM mendapatkan ini dari pin output Device MFT. DeviceSource mengekspos Deskriptor Presentasi dan Deskriptor Aliran berdasarkan informasi ini ke alur pengambilan data.
SourceReader menggunakan jenis media dari DeviceSource yang telah diekspos dan mengatur jenis media default pada setiap stream. 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 tipe media pada aliran keluaran yang sesuai dari Devproxy. Jika itu berhasil, maka DTM mengatur jenis media yang sama pada aliran input Device MFT menggunakan SetInputStreamState. Setelah menerima panggilan ini, MFT Perangkat menyelesaikan SetOutputStreamState.
CaptureEngine memilih aliran individual dengan mengaktifkan aliran tertentu di DeviceSource. Ini diteruskan 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.
Nota
Alokasikan sumber daya yang diperlukan saat memulai streaming alih-alih inisialisasi Device MFT.
DTM memanggil SetOutputStreamState pada output Device MFT dengan parameter status streaming. Perangkat MFT mulai mengalirkan data pada aliran keluaran tersebut. DTM memulai streaming pada aliran output Devproxy yang memiliki set mediatype yang valid. Devproxy mengalokasikan sampel dan mengambilnya dari perangkat. Sampel-sampel ini disalurkan ke MFT Perangkat melalui 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 diterapkan sebagai penonaktifkan aliran keluaran tertentu pada Device MFT melalui SetOutputStreamState. Pada gilirannya, MFT Perangkat dapat meminta untuk menonaktifkan aliran input tertentu melalui peristiwa METransformInputStreamStateChanged . DTM menyebarluaskan ini ke aliran Devproxy yang sesuai.
Selama Device MFT berada dalam status streaming, ia dapat meminta aliran input apa pun untuk bertransisi ke salah satu dari semua 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 mengalir selama Perangkat MFT itu sendiri dalam status streaming.
Masa Pakai Perangkat MFT
MFT dimuat setelah perangkat Filter KS dibuat. Ini akan dibongkar sebelum KS Filter ditutup.
Dari perspektif pipeline, ketika DeviceSource dibuat, Device MFT juga dibuat, dan ketika DeviceSource dimatikan, Device MFT dimatikan secara sinkron.
Untuk mendukung penghentian, Perangkat MFT harus mendukung antarmuka IMFShutdown. Setelah Device MFT->Shutdown dipanggil, panggilan antarmuka lain ke Device MFT 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 Device MFT untuk diproses lebih lanjut.
Devproxy mengalokasikan buffer berdasarkan preferensi driver. Kami memerlukan Perangkat MFT untuk menggunakan API alokator MF guna mengalokasikan sampel yang diperlukan untuk pin keluarannya untuk transformasi yang tidak dilakukan di tempat yang sama.
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 Perangkat MFT untuk menghapus semua sampel yang tertunda dari antrean aliran tersebut dan beralih ke media type baru pada aliran tersebut dengan 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.
Perubahan Tipe Media Input di Perangkat MFT
Karena ini adalah m x n MFT, mungkin ada konsekuensi pada tipe media dan perubahan status pin streaming input ketika tipe media atau status pin streaming output berubah. Khususnya ketika perubahan berikut terjadi:
Perubahan Tipe Media Output
Ketika aplikasi mengubah mediatipe asli, perubahan tersebut tercascading melalui tumpukan tangkapan hingga menyebabkan perubahan mediatipe sebagai output pin pada Device MFT.
Ketika mediatipe output berubah, itu dapat memicu perubahan mediatipe input. Misalnya, anggaplah semua pin output melakukan streaming dalam 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 untuk aliran rekaman harus mengubah jenis medianya.
Pin output dinonaktifkan
- Ketika sebuah aplikasi menonaktifkan salah satu output Device MFT saat input yang sama digunakan oleh lebih dari satu output, demi pengoptimalan, input mungkin perlu 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 jenis media dan status pada input Device MFT dan output Devproxy dalam kondisi ini.
Madiatipe output yang diutamakan pada MFT Perangkat
Kami merekomendasikan agar MFT perangkat menghasilkan tipe media keluaran menggunakan format NV12. YUY2 adalah alternatif terbaik berikutnya. Jenis media MJPEG dan RGB tidak disarankan.
Perangkat Pembilas MFT
Dua jenis pembilasan diperlukan saat mengelola Device MFT:
Pengosongan Global
Perangkat penyiraman luas MFT. 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 bila output baru tersedia.
Pembilasan lokal
- Keluaran flush khusus pin. Ini biasanya terjadi ketika aliran dihentikan.
Semua peristiwa yang diposting sebelum proses flush dihapus oleh Device MFT Manager. Setelah penghapusan, Perangkat MFT mengatur ulang pelacakan jumlah METransformHaveOutput internalnya.
Pembuangan MFT Perangkat
MFT perangkat tidak akan menerima pesan pembuangan data terpisah karena tidak diperlukan pembuangan pada sumber penangkapan langsung.
Pemicu Kamera
Dalam model ini, alih-alih mengirim pemicu foto serta pemicu mulai dan berhenti urutan foto langsung ke driver, mereka dialihkan ke Device MFT. Device MFT menangani pemicu atau meneruskannya ke driver kamera jika diperlukan.
Awal yang hangat
DeviceSource mencoba memulai ulang dengan cepat aliran keluaran tertentu dengan mengubah aliran ke keadaan jeda. Pada gilirannya, DTM memanggil metode IMFDeviceTransform::SetOutputStreamState pada MFT Perangkat untuk melakukan transisi aliran output tertentu ke status jeda. Ini menyebabkan aliran input yang bersangkutan dijeda. Ini dicapai oleh Device MFT 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 untuk mempermudah penanganan urutan foto.
Konfirmasi foto
Device MFT mendukung konfirmasi foto melalui antarmuka IMFCapturePhotoConfirmation . Alur mengambil antarmuka ini melalui metode IMFGetService::GetService .
Metainformasi
Devproxy meminta driver untuk ukuran buffer metadata dan mengalokasikan memori untuk metadata. Metadata yang berasal dari driver ditetapkan oleh Devproxy pada sampel. Perangkat MFT menggunakan metadata sampel. Metadata dapat diteruskan bersama sampel melalui aliran keluarannya atau digunakan untuk pemrosesan setelahnya.
Dengan Device MFT yang mendukung berbagai jumlah 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 dialihkan ke mode streaming ketika Device MFT mulai streaming. Misalnya, ketika aliran output dipilih untuk streaming, Perangkat MFT dapat meminta DTM untuk memulai satu atau beberapa aliran video, serta aliran metadata, 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 Perangkat MFT. Antarmuka ini memfasilitasi manajemen m input dan n output Device MFT. Bersama dengan antarmuka lain, Device MFT 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:
-
Ini memungkinkan semua kSProperti, Peristiwa, dan Metode untuk melalui Perangkat MFT. Ini memberi MFT Perangkat kemampuan untuk menangani panggilan fungsi ini di dalam MFT Perangkat atau hanya meneruskannya ke driver. Dalam kasus ketika ia menangani metode KsEvent, maka MFT Perangkat harus melakukan langkah-langkah berikut ini:
Jika Device MFT menangani peristiwa KSEVENT_TYPE_ONESHOT apa pun, maka akan menduplikasi handle saat menerima KSEVENT_TYPE_ENABLE.
Setelah selesai mengatur atau memicu peristiwa, fungsi tersebut memanggil CloseHandle pada pegangan yang digandakan.
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 suatu peristiwa ks tertentu.
Jika Device MFT menangani peristiwa non-KSEVENT_TYPE_ONESHOT, maka harus menduplikasi handel saat 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.
Persyaratan pemberitahuan
MFTs perangkat harus menggunakan pesan berikut untuk memberi tahu DTM tentang ketersediaan sampel, setiap perubahan status aliran input, dan sebagainya.
Persyaratan utas
Perangkat MFT 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 Device MFT mendapatkan prioritas yang benar pada tingkat di mana alur kerja penangkapan beroperasi dan menghindari inversi prioritas utas.
Persyaratan InputStream
Jumlah aliran
- Jumlah aliran input dalam Device MFT 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 media yang didukung oleh driver.
Jumlahnya bisa berbeda hanya jika jenis media yang didukung oleh input Device MFT 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 perangkat MFT
INF perangkat kamera harus memiliki entri antarmuka perangkat berikut yang menentukan CLSID CoClass dari Device MFT.
[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:
Nota
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 pada Windows 10, versi 1703, alur kamera Windows mendukung rangkaian opsional DMFT dengan maksimal dua DMFT.
Mulai dari Windows 11, versi 22H2, alur kamera Windows mendukung rangkaian DMFT 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 DMFT.
Aliran sampel ditangkap 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 perantara dengan hanya meneruskan sampel ke DMFT berikutnya.
Untuk kontrol seperti KsProperty, panggilan akan naik ke atas aliran - 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 DMFT IHV/OEM, jika salah satu DMFT gagal menginstansiasi merupakan kesalahan fatal bagi DTM.
Persyaratan mengenai 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 perlu didaftarkan. Mengingat bahwa kamera USB mungkin dicolokkan ke dalam sistem acak, 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 bagian "Interface AddReg" dari file .INF kustom, tentukan CLSID DMFT dengan memasukkan 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.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Nota
CameraDeviceMftCLSIDChain dapat memiliki maksimum 2 CLSID.
Jika CameraDeviceMftCLSIDChain sudah dikonfigurasi, pengaturan CameraDeviceMftCLSID lama dilewati oleh DTM.
Jika CameraDeviceMftCLSIDChain tidak dikonfigurasi dan CameraDeviceMftCLSID lama dikonfigurasi, maka rantai akan terlihat seperti ini: (jika kamera adalah USB yang 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 dimatikan) 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 perangkat
Daripada mendaftarkan objek COM driver secara global, objek COM driver terdaftar di bawah kunci perangkat. Ini memungkinkan pendaftaran MFT COM dari dalam wadah dan mencegah pembuatan kunci registri global, sehingga mempertahankan isolasi paket driver. MFTs terdaftar di bawah kunci perangkat juga karena alasan serupa.
Perubahan driver INF
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 | Setelahnya |
|---|---|
| INF AddReg: HKCR, MediaFoundation\Transforms\{clsid}\... |
Per-Instance perangkat lunak perangkat INF AddReg: HKR, MediaFoundation\Transforms\{clsid}\... |
| Lokasi Registri: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Lokasi Registri: software key\MediaFoundation\Transforms\{clsid}\... |
Pendaftaran COM
Pada Windows 26100 dan versi yang lebih baru, semua registrasi COM untuk MFT Perangkat harus menggunakan direktif AddComServer/AddComClass dalam file 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 | Setelahnya |
|---|---|
| INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Per-Instance perangkat lunak perangkat 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