Руководство по проектированию MFT устройства
Стек захвата видео в Windows поддерживает расширение пользовательского режима в виде DMFT. Это компонент расширения для каждого устройства, который предоставляет IHV, и конвейер записи вставляется в качестве первого преобразования после захвата. DMFT получает от устройства после обработки кадры. Дальнейшие операции после обработки кадров можно выполнить внутри DMFT. DMFT может получать кадры из всех потоков устройства, и он может предоставлять любое количество выходных потоков в зависимости от требования.
В этой статье описывается проектирование расширения на уровне устройства, работающего в пользовательском режиме, который можно использовать для выполнения после обработки общих для всех потоков.
Терминология
| Термин | Description |
|---|---|
| KS | Драйвер потоковой передачи ядра |
| AVStream | Модель драйвера потоковой передачи аудио видео |
| Фильтр | Объект, представляющий экземпляр устройства |
| MFT устройства | Расширение драйвера отслеживания в пользовательском режиме, предоставленное IHVs |
| Devproxy | MF <—> маршалер AVStream |
| DTM | Диспетчер преобразования устройств, который управляет devproxy и Device MFT. Представляет устройство в конвейере MF. |
Цели разработки
Расширение пользовательского режима фильтра устройства, которое имеет то же время существования, что и фильтр устройств
Поддерживает любое количество входных данных, поступающих с устройства.
Поддерживает любое количество выходных данных (текущее требование — три потока: предварительная версия, запись и фотография)
Перенаправляет все элементы управления устройства на устройство MFT (который при необходимости обрабатывает или передает его на устройство)
Параллельная после обработки захваченного потока
Разрешить обработку 3A независимо от частоты кадров
Разрешить совместное использование метаданных из одного потока между другими потоками
Доступ к ресурсам GPU
Доступ к рабочим очередям MF MMCSS
Доступ к MF Allocator
Простой интерфейс (аналогично MFT)
Гибкая внутренняя архитектура для расширяемости IHV/OEM
Ограничения разработки
Изменения в области API записи не изменяются
Полная обратная совместимость. Например, при работе с устаревшими приложениями и сценариями не выполняется регрессия.
Архитектура стека записи
В этой статье описывается поддержка расширения пользовательского режима на уровне фильтра для драйвера записи. Этот компонент имеет доступ к API-интерфейсам MF, пулам потоков, ресурсам GPU и ISP. Расширение для широкого фильтра обеспечивает гибкость при наличии любого количества потоков между собой и фильтром Ks устройств. Эта гибкость обеспечивает простое взаимодействие между расширением пользовательского режима и драйвером, который можно использовать для выделенных метаданных и потоков обработки 3A.
Диспетчер преобразования устройств (DTM)
Стек захвата представляет новый системный компонент, диспетчер преобразования устройств (DTM). Это находится в DeviceSource и управляет Devproxy MFT и Device MFT. DTM выполняет согласование MediaType, распространение образцов и обработку событий MFT. Он также предоставляет интерфейс МВФTransform deviceSource и другие необходимые частные интерфейсы, которые DeviceSource должны управлять потоками устройств. Этот компонент абстрагирует Devproxy и Device MFT из конвейера. Конвейер просто видит DTM как устройство и потоки из DTM в качестве потоков устройств.
Devproxy
Devproxy — это асинхронный MFT, который маршалирует команды и видеокадры между драйвером камеры AVStream и Media Foundation. Это предоставляется Windows и поддерживает n число выходных данных драйвера камеры. Кроме того, это владеет распределителями для всех контактов, предоставляемых устройством.
MFT устройства
MFT устройства — это расширение пользовательского режима для драйвера записи. Это m x n async MFT. Он установлен в системе с драйвером записи и предоставляется поставщиком драйвера записи.
Количество входных потоков MFT устройства должно совпадать с количеством контактов Ks, предоставляемых устройством. Тип мультимедиа, поддерживаемый входными потоками MFT устройства, должен совпадать с типами мультимедиа, предоставляемыми пин-кодами KS.
Число выходных потоков, предоставляемых устройством MFT, — это потоки, которые отображаются в DeviceSource и стеке захвата, API записи и приложениях и могут быть одним, двумя или тремя потоками. Количество входных и выходных потоков устройства MFT не должно совпадать. Кроме того, входные и выходные потоки не должны иметь одинаковые медиатипы, и обычно имеет разные медиатипы. Количество медиатипов не совпадает.
Первый пин-код Ks, представленный в пользовательском режиме выходным потоком Devproxy, связывается с первым входным потоком устройства MFT, вторым пин-кодом Ks, представленным в пользовательском режиме выходным потоком Devproxy со вторым входным потоком устройства MFT и т. д.
MFT устройства получает указатель на Devproxy, устройство DX и идентификатор MF WorkQueue. Кадры, исходящие из устройства, передаются непосредственно в соответствующие входные данные устройства MFT в качестве примеров MF. При этом устройство MFT может отправлять записанные образцы и служить образцам для предварительного просмотра, записи и закреплений фотографий.
Все команды и элементы управления, которые собираются на устройство, перенаправляются на MFT устройства. MFT устройства обрабатывает элементы управления или передает их драйверу через Devproxy. Это упрощает обработку команд стеком драйверов записи.
Обзор функциональных возможностей
При инициализации конвейера захвата, если для устройства есть MFT устройства, DeviceSource создает экземпляр DTM. Он передает экземпляр Devproxy, представляющий устройство в подпрограмму инициализации DTM. DTM cocreates Device MFT и выполняет основные проверки, например, проверяет количество выходных пинов Devproxy совпадает с количеством входных пинов устройства MFT, поддержкой обязательных интерфейсов и т. д.
DeviceSource запрашивает DTM, чтобы получить поддерживаемые выходные типы мультимедиа. DTM получает это из выходных закреплений MFT устройства. DeviceSource предоставляет дескриптор презентации и дескриптор Stream на основе этих сведений конвейеру записи.
SourceReader использует предоставленные медиатипы DeviceSource и задает стандартные типы мультимедиа для каждого потока. В свою очередь DeviceSource задает стандартные медиатипы в выходных потоках DTM. DTM задает тип мультимедиа в выходном потоке MFT устройства с помощью метода SetOutputStreamState .
При вызове SetOutputStreamState устройство MFT отправляет сообщение в DTM, чтобы изменить тип медиатипа входного потока на основе выбранного выходного медиатипа и ожиданий. В ответ на это сообщение DTM запрашивает предпочтительный входной тип мультимедиа для входного потока MFT устройства с помощью GetPreferredInputStreamState. Этот параметр задает тип мультимедиа в соответствующем выходном потоке Devproxy. Если это успешно, DTM задает тот же тип мультимедиа в входном потоке устройства MFT с помощью SetInputStreamState. После получения этого вызова устройство MFT завершает SetOutputStreamState.
CaptureEngine выбирает отдельные потоки, включив определенные потоки в DeviceSource. Это распространяется на устройство MFT по DTM через вызов SetOutputStreamState . MFT устройства помещает определенные выходные потоки в запрошенное состояние. Как упоминалось выше, устройство MFT также уведомляет DTM о необходимых входных потоках, которые необходимо включить. Это приводит к распространению выделения потока в Devproxy. В конце этого процесса все необходимые потоки в Devproxy и Device MFT готовы к потоковой передаче.
SourceReader запускает DeviceSource при вызове CaptureEngine вызовов ReadSample. В свою очередь DeviceSource запускает DTM, отправляя MFT_MESSAGE_NOTIFY_BEGIN_STREAMING и MFT_MESSAGE_NOTIFY_START_OF_STREAM сообщения, указывающие на начало конвейера. DTM запускает Devproxy и Device MFT, распространяя MFT_MESSAGE_NOTIFY_BEGIN_STREAMING и MFT_MESSAGE_NOTIFY_START_OF_STREAM сообщения.
Примечание.
Выделите необходимые ресурсы при запуске потоковой передачи вместо инициализации MFT устройства.
DTM вызывает SetOutputStreamState в выходных данных MFT устройства с параметром состояния потоковой передачи. MFT устройства начинает потоковую передачу в этих выходных потоках. DTM запускает потоковую передачу на выходных потоках Devproxy с допустимым набором типов мультимедиа. Devproxy выделяет образцы и извлекает их с устройства. Эти примеры передаются в MFT устройства в соответствующем пин-коде ввода. MFT устройства обрабатывает эти примеры и предоставляет выходные данные в DeviceSource. Из DeviceSource примеры передаются через SourceReader в CaptureEngine.
CaptureEngine останавливает отдельные потоки, отключая отдельные потоки через внутренний интерфейс в DeviceSource. Это преобразуется в определенный выходной поток, отключаемый на устройстве MFT через SetOutputStreamState. В свою очередь MFT устройства может запросить отключение определенных входных потоков через событие METransformInputStreamStateChanged . DTM распространяет это на соответствующие потоки Devproxy.
Если устройство MFT само по себе в состоянии потоковой передачи, оно может запросить любой входной поток для перехода на любой из допустимых DeviceStreamState. Например, он может отправлять его в DeviceStreamState_Stop или DeviceStreamState_Run или DeviceStreamState_Pause и т. д., не затрагивая другие потоки.
Однако переход выходного потока управляется конвейером захвата. Например, предварительный просмотр, запись и фотопотоки включены или отключены конвейером захвата. Даже если выходные данные отключены, входной поток по-прежнему может быть потоковой передачи до тех пор, пока само устройство MFT находится в состоянии потоковой передачи.
Время существования MFT устройства
MFT устройства загружается после создания фильтра KS. Он выгружается до закрытия фильтра KS.
С точки зрения конвейера при создании DeviceSource создается MFT устройства и при завершении работы DeviceSource MFT устройство завершается синхронно.
Для поддержки завершения работы устройство MFT должно поддерживать интерфейс МВФShutdown . После вызова устройства MFT-Shutdown> любой другой вызов интерфейса в MFT устройства должен вернуть ошибку MF_E_SHUTDOWN.
Тип памяти
Кадры можно записывать в системные буферы памяти или буферы памяти DX в предпочтениях драйвера камеры. Какой бы буфер не вышел из драйвера камеры, напрямую помещается в MFT устройства для дальнейшей обработки.
Devproxy выделяет буферы на основе предпочтений драйвера. Для выделения примеров, необходимых для вывода выходных закреплений для преобразования, неуместного преобразования, требуется использование API-интерфейсов распределителя MF.
Изменение типа мультимедиа во время потоковой передачи
Клиенты SourceReader могут видеть медиатипы, предоставляемые выходными потоками MFT устройства, как собственные поддерживаемые медиатипы. При изменении собственного типа мультимедиа SourceReader отправляет вызовы уведомлений о типе мультимедиа в устройство MFT через DeviceSource. Это ответственность за MFT устройства для очистки всех ожидающих примеров из очереди этого потока и своевременного перехода на новый тип медиатипа в этом потоке. Если есть необходимость изменить входной тип медиатипа, он должен изменить текущий входной тип медиатипа на тот. DTM получает текущий тип мультимедиа из входного потока MFT устройства и задает его в выходных потоках Devproxy и входных данных устройства MFT после каждого изменения собственного типа мультимедиа.
Изменение входного типа мультимедиа в MFT устройства
Так как это m x n MFT, могут возникнуть последствия для типов носителей входной потоковой передачи и изменения состояния при изменении типов носителей или состояний пин-кода потоковой передачи. В частности, если происходят следующие изменения:
Изменения типа выходных носителей
Когда приложение изменяет собственный тип мультимедиа, он каскадирует стек захвата в Device MFT в качестве изменения типа носителя выходного пин-кода.
При изменении выходного типа медиатипа он может активировать изменение входного типа мультимедиа. Например, предположим, что все выходные контакты потоковой передачи выполняются в 720p. Это приводит к потоковой передаче с камеры в 720p. Затем предположим, что поток записей изменяет собственный тип мультимедиа на 1080p. В этом случае один из входных потоков устройства MFT, которые извлекали данные в поток записей, придется изменить его тип мультимедиа.
Выходной пин-код отключен
- Если приложение отключает один из выходных данных MFT устройства, если одни и те же входные данные совместно используются несколькими выходными данными, для оптимизации входные данные могут потребоваться изменить тип носителя. Например, если выходной поток 1080p останавливается, а все остальные потоки, совместное использование одного входного ввода, потоковая передача выполняется в 720p, то входной поток должен изменить его тип мультимедиа на 720p, чтобы сохранить мощность и повысить производительность.
DTM обрабатывает уведомления METransformInputStreamStateChanged от Device MFT, чтобы изменить тип мультимедиа и состояние на входных данных Устройства MFT и выходных данных Devproxy в этих условиях.
Предпочтительный выходной тип мультимедиа устройства MFT
Мы рекомендуем использовать MFT устройства для создания типов выходных носителей с использованием формата NV12. YuY2 является следующей лучшей альтернативой. Типы мультимедиа MJPEG и RGB не рекомендуется.
Очистка MFT устройства
При управлении MFT устройства требуются два типа очистки:
Глобальный сброс
Очистка устройства на уровне MFT. Обычно это происходит, когда DTM будет отправлять сообщение о остановке потоковой передачи на устройство MFT.
Ожидается, что MFT устройства удаляет все примеры из очередей входных и выходных данных и возвращается синхронно.
MFT устройства не должен запрашивать новые входные данные или отправлять уведомления о новых доступных выходных данных.
Локальный сброс
- Вывод пин-кода, характерный для очистки. Обычно это происходит при остановке потока.
Все события, которые были размещены до очистки, удаляются диспетчером MFT устройства. После очистки MFT устройства сбрасывает его внутреннее число отслеживания METransformHaveOutput .
Очистка MFT устройства
Устройство MFT не получит отдельное сообщение о сливе, так как в источнике динамического захвата не требуется.
Триггер фотографии
В этой модели вместо отправки триггера фото и последовательности фотографий запуска и остановки триггеров непосредственно драйверу они перенаправляются на устройство MFT. Устройство MFT обрабатывает триггер или пересылает его драйверу камеры по мере необходимости.
Теплое начало
DeviceSource пытается запустить определенный выходной поток путем перехода потока на приостановку состояния. В свою очередь DTM вызывает метод IMFDeviceTransform::SetOutputStreamState на устройстве MFT для перехода определенного выходного потока для приостановки состояния. Это приводит к приостановке соответствующего входного потока. Это достигается устройством MFT путем запроса METransformInputStreamStateChanged в DTM и обработки метода IMFDeviceTransform::SetInputStreamState .
Последовательность фотографий переменной
Благодаря этой архитектуре последовательность фотографий реализуется с помощью драйвера устройства камеры и MFT устройства, что значительно снижает сложность драйвера устройства камеры. Триггеры последовательности фотографий запуска и остановки отправляются на устройство MFT и обрабатывают последовательность фотографий проще.
Подтверждение фотографии
Устройство MFT поддерживает подтверждение фотографии через интерфейс МВФCapturePhotoConfirmation . Конвейер извлекает этот интерфейс с помощью метода МВФGetService::GetService .
Метаданные
Devproxy запрашивает драйвер для размера буфера метаданных и выделяет память для метаданных. Метаданные, поступающие из драйвера, по-прежнему задаются Devproxy в примере. MFT устройства использует метаданные примера. Метаданные можно передавать с помощью примера через выходной поток или использовать для последующей обработки.
При использовании MFT устройства, поддерживающего любое количество входных данных, выделенный пин-код ввода можно использовать только для метаданных или метаданных вне диапазона. Тип носителя для этого пин-кода настраивается, и драйвер решает размер и количество буферов.
Этот поток метаданных предоставляется за пределами DTM. Поток можно поместить в состояние потоковой передачи при запуске MFT устройства. Например, если выходные потоки выбраны для потоковой передачи, MFT устройства может запросить DTM для запуска одного или нескольких видеопотоков, а также потока метаданных с помощью события METransformInputStreamStateChanged .
Примечание. Количество входных закреплений в этой модели не требуется. Можно выделить отдельный пин-код для метаданных или 3A.
Обработка событий диспетчера преобразований устройств (DTM)
События диспетчера преобразований устройств определяются в следующих справочных статьях:
Интерфейс IMFDeviceTransform
Интерфейс IMFDeviceTransform определяется для взаимодействия с Устройством MFT. Этот интерфейс упрощает управление входными данными m и N output Device MFT. Наряду с другими интерфейсами MFT устройство должно реализовать этот интерфейс.
Распространение общих событий
При возникновении события в Devproxy (или внутри устройства) необходимо распространить это на устройство MFT и в DeviceSource.
Требования к MFT устройства
Требования к интерфейсу
MFT устройства должны поддерживать следующие интерфейсы:
-
Это позволяет всем ksproperties, событиям и методам проходить через MFT устройства. Это дает устройству MFT возможность обрабатывать вызовы этих функций внутри Device MFT или просто перенаправляет их в драйвер. В случае, когда он обрабатывает методы KsEvent, необходимо выполнить следующие действия:
Если устройство MFT обрабатывает любое событие KSEVENT_TYPE_ONESHOT , оно дублирует дескриптор при получении KSEVENT_TYPE_ENABLE.
После завершения настройки или вызова события он вызывает CloseHandle на повторяющийся дескриптор.
Если устройство MFT обрабатывает события, отличные от KSEVENT_TYPE_ONESHOT событий, то он должен дублировать дескриптор при получении KSEVENT_TYPE_ENABLE и вызывать CloseHandle в повторяющемся дескрипторе при отключении события KsEvent путем вызова функции KsEvent с первым параметром (идентификатором события ks) и вторым параметром (длина события) равным нулю. Допустимы данные события и длина. Данные события однозначно идентифицируют определенное событие ks.
Если устройство MFT обрабатывает события, отличные от KSEVENT_TYPE_ONESHOT, то он должен дублировать дескриптор при получении KSEVENT_TYPE_ENABLE и вызывать CloseHandle на повторяющиеся дескрипторы, когда события KsEvent отключены путем вызова функции KsEvent со всеми параметрами, заданными нулю.
Требования к уведомлениям
MFTs устройства должны использовать следующие сообщения, чтобы сообщить DTM о доступности примеров, изменении состояния входного потока и т. д.
Требования к потокам
MFT устройства не должно создавать собственные потоки. Вместо этого он должен использовать очереди работы Media Foundation, которые выделяются на основе идентификатора, переданного DMFT через интерфейс МВФRealTimeClientEx . Это позволяет убедиться, что все потоки, выполняемые в MFT устройства, получают правильный приоритет, с которым выполняется конвейер захвата, и избегайте инверсий приоритета потока.
Требования к InputStream
Число потоков
- Количество входных потоков в MFT устройства должно совпадать с количеством потоков, поддерживаемых драйвером.
MediaTypes
Количество типов мультимедиа и фактических типов носителей, поддерживаемых входными данными Устройства MFT, должно соответствовать количеству и типам медиатипов, поддерживаемых драйвером.
Число может отличаться, только если медиатипы, поддерживаемые входными данными Device MFT, являются подмножеством типов носителей, поддерживаемых драйвером.
Медиатипы, поддерживаемые драйвером и вводом MFT устройства, могут быть стандартными или настраиваемыми типами мультимедиа.
Регистрация MFT устройства
Inf-файл устройства камеры должен иметь следующую запись интерфейса устройства, указывающую CLSID coClass устройства 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%
Эти записи 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 устройства — это рекомендуемый механизм подключаемого модуля пользовательского режима для IHV и OEM для расширения функциональных возможностей камеры в Windows.
До Windows 10 версии 1703 конвейер камеры поддерживает только один подключаемый модуль расширения DMFT.
Начиная с Windows 10 версии 1703 конвейер камеры Windows поддерживает необязательную цепочку DMFT с максимальным количеством двух DMFT.
Начиная с Windows 11 версии 22H2 конвейер камеры Windows поддерживает необязательную цепочку DMFT с максимальным количеством четырех DMFT.
Это обеспечивает большую гибкость для изготовителей оборудования и IHV для предоставления дополнительных значений в виде потоков камеры после обработки. Например, устройство может использовать PDMFT вместе с DMFT IHV и OEM DMFT.
На следующем рисунке показана архитектура, связанная с цепочкой DMFT.
Потоковая запись примеров из драйвера камеры в DevProxy, а затем проходит через цепочки DMFT. Каждый DMFT в цепочке имеет возможность обработать выборку. Если DMFT не хочет обработать пример, он может выступать в качестве сквозной передачи, просто передать пример следующему DMFT.
Для таких элементов управления, как KsProperty, вызов идет вверх по потоку — последний DMFT в цепочке получает вызов первым. Вызов может обрабатываться там или передаваться предыдущему DMFT в цепочке.
Ошибки распространяются из DMFT в DTM, а затем в приложения. Для IHV/OEM DMFTs любой из DMFT не удалось создать экземпляр является неустранимой ошибкой для DTM.
Требования к DMFTs:
Число входных закреплений DMFT должно совпадать с числом выходных закреплений предыдущего DMFT. В противном случае DTM завершится ошибкой во время инициализации. Однако счетчики входных и выходных закреплений одного и того же DMFT не должны соответствовать.
DMFT необходимо поддерживать интерфейсы — МВФDeviceTransform, МВФShutdown, МВФRealTimeClientEx, IKsControl и МВФMediaEventGenerator; МВФTransform может потребоваться поддерживаться, если в цепочке настроенА MFT0 или следующая DMFT в цепочке требуется поддержка МВФTransform.
В 64-разрядных системах, которые не используют frame Server, необходимо зарегистрировать как 32-разрядные, так и 64-разрядные DMFT. Учитывая, что USB-камера может быть подключена к произвольной системе для "внешних" (или noninbox) USB-камер, поставщик USB-камеры должен предоставлять как 32-разрядные, так и 64-разрядные DMFT.
Настройка цепочки DMFT
Устройство камеры может при необходимости предоставить COM-объект DMFT в библиотеке DLL с помощью пользовательского INF-файла, использующего разделы папки "Входящие USBVideo.INF".
В пользовательском. В разделе INF-файла "Interface AddReg" укажите CLSID DMFT, добавив следующую запись реестра:
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%
Как показано в приведенном ниже примере параметров INF (замените %Dmft0.CLSID% и % Dmft1.CLSID% фактическими строками CLSID, которые вы используете для DMFTs), в Windows 10 версии 1703 разрешено не более 2 CLSID, а первый — ближе всего к DevProxy, а последний — последний DMFT в цепочке.
Платформа DMFT CLSID — {3D096DDE-8971-4AD5-98F9-C74F56492630}.
Некоторые примеры параметровChain CameraDeviceMftCLSIDChain :
Нет IHV/OEM DMFT или DMFT платформы
- CameraDeviceMftCLSIDChain = "" (или нет необходимости указывать эту запись реестра)
IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
Платформа DMFT —> IHV/OEM DMFT <
CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%
Ниже приведен снимок экрана: раздел реестра результатов для USB-камеры с платформой DMFT и DMFT (с GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) в цепочке.
IHV/OEM DMFT0 <—> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Примечание.
Chain CameraDeviceMftCLSIDChain может иметь не более 2 CLSID.
Если настроена цепочкаchain CameraDeviceMftCLSID, устаревшие параметры CameraDeviceMftCLSID пропускаются DTM.
Если параметр CameraDeviceMftCLSIDChain не настроен и настроен устаревший идентификатор CameraDeviceMftCLSID, цепочка будет выглядеть следующим образом (если ее USB-камера и поддерживается платформой DMFT и платформой DMFT) DevProxy —> <Platform DMFT — 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 устройств
Вместо глобальной регистрации COM-объекта драйвера объект COM драйвер регистрируется в ключе устройства. Это позволяет регистрации COM MFT из контейнера и предотвращает создание глобальных разделов реестра, что позволяет сохранить изоляцию пакета драйвера. MFT регистрируются в ключе устройства, а также по аналогичным причинам.
Изменения в INF драйвера
После установки драйвера устройства inf теперь необходимо сделать все COM-объект и регистрацию MFT под ключом устройства. Регистрация MFT и COM должна измениться, как показано здесь:
Регистрация MFT
| Перед | После |
|---|---|
| INF AddReg: HKCR, MediaFoundation\Transforms\{clsid}\... |
Программное обеспечение для каждого экземпляра устройства INF AddReg: HKR, MediaFoundation\Transforms\{clsid}\... |
| Расположение реестра: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Расположения реестра: программный ключ\MediaFoundation\Transforms\{clsid}\... |
Регистрация COM
В Windows 26100 и более поздних версий все регистрации COM для MFT устройств должны использовать директивы AddComServer/AddComClass в INF. Ниже показан пример синтаксиса:
[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%
Предыдущие версии регистрации COM для устройства MFT использовали AddReg для установки com-класса вручную.
| Перед | После |
|---|---|
| INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Программное обеспечение для каждого экземпляра устройства INF AddReg: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
Синтаксис INF для различения на основе версии ОС можно найти в сочетании расширений платформы с версиями операционной системы. Начиная с окна 11 25300, INF-файл должен соответствовать этим новым разделам реестра. Старые версии ОС используют традиционные разделы реестра для совместимости. INF-файл должен настроить эти разделы реестра в старом расположении в старых сборках ОС и создать новые ключи в новом расположении для новых сборок ОС. Например, для регистрации MFT в более старой сборке INF создается раздел под следующей записью реестра:
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
Для регистрации MFT в новой сборке INF создает ключ под следующей записью реестра:
**software key**\MediaFoundation\Transforms\{clsid}\
Эта запись определяет, где ключ программного обеспечения представляет ключ программного обеспечения устройства.
Дополнительные сведения см. в разделе "Открытие ключа программного обеспечения устройства".
Ниже показан пример синтаксиса для назначения различных версий ОС:
[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