Руководство по проектированию MFT устройства

Стек захвата видео в Windows поддерживает расширение пользовательского режима в виде DMFT. Это компонент расширения на уровне устройства, который поставляется OEM, и конвейер захвата вставляет его как первое преобразование после завершения захвата. DMFT получает обработанные кадры от устройства. Дальнейшие операции после обработки кадров можно выполнить внутри DMFT. DMFT может получать кадры из всех потоков устройства, и он может предоставлять любое количество выходных потоков в зависимости от требования.

В этой статье описывается разработка расширения на уровне устройства, работающего в пользовательском режиме, которое можно использовать для постобработки, общей для всех потоков.

Терминология

Срок	Описание
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. Он также предоставляет интерфейс IMFTransform для 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. Он передает в подпрограмму инициализации DTM экземпляр Devproxy, представляющий устройство. DTM совместно создаёт устройство MFT и выполняет основные проверки, например, проверяет, совпадает ли количество выходных пинов Devproxy с количеством входных пинов устройства MFT, поддерживается ли обязательная интерфейсы и другие аналогичные проверки.

DeviceSource запрашивает DTM, чтобы получить поддерживаемые выходные типы мультимедиа. DTM получает это из выходных контактов устройства MFT. DeviceSource предоставляет дескриптор презентации и дескриптор потока на основе этих сведений конвейеру захвата.

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 о необходимых входных потоках, которые необходимо включить. Это приводит к тому, что 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 создается Device MFT, а при завершении работы DeviceSource, Device MFT завершается синхронно.

Для поддержки завершения работы устройство MFT должно поддерживать интерфейс IMFShutdown. После вызова Device 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, изменения в типах носителей или состоянии выходного потокового пина могут повлиять на типы носителей и состояние входного потокового пина. В частности, если происходят следующие изменения:

• Изменения типа выходных носителей

  • Когда приложение изменяет родной тип медиа, это приводит к изменению типа медиа на выходном контакте в устройстве 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 устройства. После очистки Device MFT сбрасывает свой внутренний счётчик METransformHaveOutput.

Очистка MFT устройства

Устройство MFT не получит отдельное сообщение о завершении, так как в источнике живого захвата это не требуется.

Триггер фотографии

В этой модели вместо отправки управляющих сигналов для фото и последовательности фотографий непосредственно драйверу они перенаправляются на устройство MFT. Устройство MFT обрабатывает триггер или пересылает его драйверу камеры по мере необходимости.

Теплое начало

DeviceSource пытается постепенно перезапустить определенный выходной поток, переводя его в состояние паузы. В свою очередь DTM вызывает метод IMFDeviceTransform::SetOutputStreamState на устройстве MFT, чтобы перевести определенный выходной поток в состояние паузы. Это приводит к приостановке соответствующего входного потока. Это достигается устройством MFT путем запроса METransformInputStreamStateChanged в DTM и обработки метода IMFDeviceTransform::SetInputStreamState .

Переменная последовательность фотографий

Благодаря этой архитектуре последовательность фотографий реализуется с помощью драйвера камеры и MFT устройства, что значительно снижает сложность драйвера камеры. Триггеры запуска и остановки последовательности фотографий отправляются на Device MFT и упрощают обработку последовательности фотографий.

Подтверждение фотографии

Устройство MFT поддерживает подтверждение фотографии через интерфейс IMFCapturePhotoConfirmation. Конвейер извлекает этот интерфейс с помощью метода IMFGetService::GetService.

Метаданные

Devproxy запрашивает драйвер для размера буфера метаданных и выделяет память для метаданных. Метаданные, поступающие из драйвера, задаются Devproxy на образце. MFT устройства потребляет метаданные образца. Метаданные можно передавать вместе с образцом через его выходной поток или использовать для последующей обработки.

При использовании MFT устройства, поддерживающего любое количество входных данных, выделенный пин-код ввода можно использовать только для метаданных или метаданных вне диапазона. Тип носителя для этого пина настраивается, и драйвер определяет размер и количество буферов.

Этот поток метаданных предоставляется за пределами DTM. Поток можно поместить в состояние потоковой передачи, когда Device MFT начинает потоковую передачу. Например, если выходные потоки выбраны для потоковой передачи, устройство MFT может запросить DTM, чтобы запустить один или несколько видеопотоков и поток метаданных с помощью события METransformInputStreamStateChanged.

Примечание: в этой модели нет требования, чтобы количество входных пинов совпадало с количеством выходных пинов. Можно выделить отдельный пин-код для метаданных или 3A.

Обработка событий диспетчера преобразований устройств (DTM)

События диспетчера преобразований устройств определяются в следующих справочных статьях:

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

Интерфейс IMFDeviceTransform

Интерфейс IMFDeviceTransform определяется для взаимодействия с Устройством MFT. Этот интерфейс упрощает управление m входами и n выходом Device MFT. Наряду с другими интерфейсами, устройство Device MFT должно реализовать этот интерфейс.

Распространение глобальных событий

При возникновении события в Devproxy (или внутри устройства) необходимо распространить это на устройство MFT и в DeviceSource.

Требования к устройству MFT

Требования к интерфейсу

MFT устройства должны поддерживать следующие интерфейсы:

• IMFDeviceTransform

• IKsControl

  • Это позволяет всем ksproperties, событиям и методам проходить через MFT устройства. Это дает устройству MFT возможность обрабатывать вызовы этих функций внутри Device MFT или просто перенаправляет их в драйвер. В случае, если устройство MFT обрабатывает методы KsEvent, оно должно выполнить следующие действия:

    • Если компонент MFT устройства обрабатывает событие KSEVENT_TYPE_ONESHOT, то он дублирует дескриптор при получении KSEVENT_TYPE_ENABLE.

    • После завершения настройки или вызова события он вызывает CloseHandle на повторяющийся дескриптор.

    • Если устройство MFT обрабатывает события, отличные от KSEVENT_TYPE_ONESHOT, оно должно дублировать дескриптор при получении KSEVENT_TYPE_ENABLE и вызывать CloseHandle на дублированном дескрипторе, когда событие ks отключается путем вызова функции KsEvent с первым параметром (идентификатором события ks) и вторым параметром (длиной события), установленными в ноль. Данные события и длина действительны. Данные события однозначно идентифицируют определенное событие ks.

    • Если устройство MFT обрабатывает события, отличные от KSEVENT_TYPE_ONESHOT, оно должно дублировать дескриптор при получении KSEVENT_TYPE_ENABLE и вызывать CloseHandle на дублированные дескрипторы, когда события KsEvent отключены путем вызова функции KsEvent со всеми параметрами, установленными в ноль.

• МВФRealTimeClientEx

• МВФMediaEventGenerator

• МВФShutdown

• IMFSampleAllocatorControl

Требования к уведомлениям

Устройства MFT должны использовать следующие сообщения, чтобы сообщить DTM о доступности образцов, изменении состояния входного потока и т. д.

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

Требования к потокам

MFT устройства не должно создавать собственные потоки. Вместо этого он должен использовать Media Foundation Work Queues, которые выделяются на основе идентификатора, переданного DMFT через интерфейс IMFRealTimeClientEx. Это позволяет убедиться, что все потоки, работающие в MFT устройства, получают правильный приоритет, который соответствует приоритету работы конвейера захвата, и избежать инверсий приоритета потоков.

Требования к InputStream

Число потоков

• Количество входных потоков в MFT устройства должно совпадать с количеством потоков, поддерживаемых драйвером.

Типы носителей

• Количество типов мультимедиа и фактических типов носителей, поддерживаемых входными данными Устройства 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 приводят к вводу следующих разделов реестра:

Замечание

Это только пример (не фактический ключ реестра)

[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, состоящую максимум из двух элементов.

Начиная с Windows 11 версии 22H2 конвейер камеры Windows поддерживает необязательную цепочку DMFT с максимальным количеством четырех DMFT.

Это обеспечивает большую гибкость для изготовителей оборудования и IHV для предоставления дополнительных значений в виде потоков камеры после обработки. Например, устройство может использовать PDMFT вместе с DMFT IHV и DMFT OEM.

На следующем рисунке показана архитектура, включающая цепочку DMFT.

Образцы передаются из драйвера камеры в DevProxy, а затем проходят через цепочки DMFT. Каждый DMFT в цепочке имеет возможность обработать выборку. Если DMFT не хочет обработать образец, он может работать как канал передачи, передав его следующему DMFT.

Для таких элементов управления, как KsProperty, вызов идет вверх по потоку — последний DMFT в цепочке получает вызов первым. Вызов может обрабатываться там или передаваться предыдущему DMFT в цепочке.

Ошибки распространяются из DMFT в DTM, а затем в приложения. Для IHV/OEM DMFT, отказ в создании экземпляра любого из DMFT является фатальной ошибкой для DTM.

Требования к DMFTs:

• Число входных контактов DMFT должно совпадать с числом выходных контактов предыдущего DMFT. В противном случае DTM выйдет из строя во время инициализации. Однако количество входных и выходных контактов одной и той же DMFT не обязательно совпадает.

• DMFT необходимо поддерживать интерфейсы – IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl и IMFMediaEventGenerator; IMFTransform может потребоваться поддерживать, если MFT0 настроен в цепочке или следующий DMFT в цепочке требует поддержки IMFTransform.

• В 64-разрядных системах, которые не используют frame Server, необходимо зарегистрировать как 32-разрядные, так и 64-разрядные DMFT. Учитывая, что USB-камера может быть подключена к произвольной системе, для "внешних" (или не встроенных) USB-камер поставщик должен предоставлять как 32-разрядные, так и 64-разрядные DMFT.

Настройка цепочки DMFT

Устройство камеры может при необходимости предоставить COM-объект DMFT в библиотеке DLL с помощью пользовательского INF-файла, использующего разделы папки "Входящие USBVideo.INF".

В разделе "Interface AddReg" пользовательского .INF-файла укажите CLSID DMFT, добавив следующую запись в реестр:

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

Как показано в примерах параметров INF ниже (замените %Dmft0.CLSID% и % Dmft1.CLSID% фактическими строками CLSID, которые вы используете для ваших DMFT), в Windows 10 версии 1703 допускается максимум 2 CLSID. Первый из них находится ближе всего к DevProxy, а последний является последним в цепочке 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%

  • Снимок экрана раздела реестра результатов для USB-камеры с платформой DMFT и DMFT (с GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) в цепочке.

• IHV/OEM DMFT0 <—> IHV/OEM DMFT1

  • CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,

Замечание

CameraDeviceMftCLSIDChain может иметь не более 2 CLSID.

Если настроена CameraDeviceMftCLSIDChain, устаревшие параметры CameraDeviceMftCLSID пропускаются DTM.

Если параметр CameraDeviceMftCLSIDChain не настроен, а настроен устаревший идентификатор CameraDeviceMftCLSID, цепочка будет выглядеть следующим образом: если это USB-камера и она поддерживается платформой DMFT и включена, то DevProxy <—> Platform DMFT <—> OEM/IHV 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}\...	Per-Instance программное обеспечение устройств 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}\...	Per-Instance программное обеспечение устройств INF AddReg: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\...

Синтаксис INF для различения на основе версии ОС можно найти в сочетании расширений платформы с версиями операционной системы. Начиная с Windows 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