Потоки захвата веб-камеры MJPG недоступны в Windows 10

Question

В Windows 10 build 10.1607.14393.10 (aka Anniversary edition) Я больше не могу получать потоки захвата MJPG. Используемый для разрешения MJPG и YUY2, теперь я получаю только YUY2 в DirectShow (Kernel Streaming), а в Media Foundation MJPG преобразует типы медиа в NV12 до того, как источник IBaseFilter подключен ко всему. Пробовал несколько систем с разными камерами. Какие-нибудь идеи, что может быть неправильным?

 640x480 @30 YUY2 
    ... 
    640x480 @30 MJPG <- gone 
... 
DirectShow: 
    com_t<IAMStreamConfig> sc; 
    if_failed_return_result(camera_output_pin->QueryInterface(&sc)); 
    int number_of_capabilities = 0; 
    int capability_size = 0; 
    if_failed_return(sc->GetNumberOfCapabilities(&number_of_capabilities, &capability_size), -1); 
    for (int i = 0; i < number_of_capabilities && k < count; i++) { 
     VIDEO_STREAM_CONFIG_CAPS scc; 
     assert(sizeof(scc) == capability_size); 
     AM_MEDIA_TYPE* mt = null; 
     if_failed_return(sc->GetStreamCaps(i, &mt, (BYTE*)&scc), -1); 
... 

В ММФ:

640x480 @30 YUY2 
    ... 
    640x480 @30 NV12 // camera reports MJPG 4cc in USBView and KsStudio 

for (int i = 0; k < count; i++) { 
    com_t<IMFMediaType> type; 
    if (d->reader->GetNativeMediaType(VIDEO_STREAM, i, &type) != 0) { 
     break; 
    } 
    GUID guid_major_type = {0}; 
    if_failed_return_result(type->GetMajorType(&guid_major_type)); 
    if (guid_major_type == MFMediaType_Video) { 
     GUID guid_subtype = {0}; 
     if_failed_return_result(type->GetGUID(MF_MT_SUBTYPE, &guid_subtype)); 
     AM_MEDIA_TYPE* amMediaType = null; 
     if_failed_return_result(type->GetRepresentation(FORMAT_MFVideoFormat, (void**)&amMediaType)); 
     assert(amMediaType->cbFormat == sizeof(MFVIDEOFORMAT)); 
     const MFVIDEOFORMAT* mi = (const MFVIDEOFORMAT*)amMediaType->pbFormat; 

Answer 1

Как explained by Mike M from Microsoft,

So yes, MJPEG and H.264 being decoded/filtered out is the result of a set of features we needed to implement, and this behavior was planned, designed, tested, and flighted out to our partners and Windows Insiders around the end of January of this year. We worked with partners to make sure their applications continued to function throughout this change, but we have done a poor job communicating this change out to you guys. We dropped the ball on that front, so I’d like to offer my apologies to you all.

В Windows 10 Anniversary Обновление MJPG видео с веб-камеры захватывается нового хелперов службы "Windows кадров Camera Server", который самообновляется как «Позволяет нескольким клиентам получать доступ к видеокадрам с устройств камеры». То же самое упоминается Майком М.

Мне одному не удалось увидеть, как несколько клиентов делят камеру, поскольку второй экземпляр TopoEdit дал мне типичную ошибку: Ошибка при запуске воспроизведения. Аппаратное MFT не удалось запустить потоковое из-за нехватки аппаратных ресурсов.

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

One of the main reasons that Windows is decoding MJPEG for your applications is because of performance. With the Anniversary Update to Windows 10, it is now possible for multiple applications to access the camera in ways that weren’t possible before. It was important for us to enable concurrent camera access, so Windows Hello, Microsoft Hololens and other products and features could reliably assume that the camera would be available at any given time, regardless of what other applications may be accessing it. One of the reasons this led to the MJPEG decoding is because we wanted to prevent multiple applications from decoding the same stream at the same time, which would be a duplicated effort and thus an unnecessary performance hit.

По-видимому, это «улучшение» застигло многих врасплох.

ОБНОВЛЕНИЕ. Было обнаружено, что поведение для использования новой функции Frame Server может быть отключено по всей системе, создав значение реестра, как определено ниже. Когда Media Foundation API увидит это значение, он выбирает исходный код для разговора с «оборудованием» (прокси-сервер KS), напрямую обходя Frame Server.

• Имя ключа:
  • HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows Media Foundation \ Platform (64-битных приложений; 32-разрядные приложения в 32-битной ОС)
  • HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ Windows Media Foundation \ Platform (32-разрядные приложения в 64-битной ОС)
• Значение Имя: "EnableFrameServerMode" REG_DWORD
• Значение: 0

Answer 2

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

1. (хак) взять старый mfcore.dll из оригинальной Windows 10, связь задержки с ним и нагрузкой силы ваша местная копия - это взлом, не пробуйте дома, не отправляйте его.
2. Используйте плохо документированный ksproxy.ax или его современную замену mfkproxy, чтобы реализовать свой собственный слой, чтобы поговорить с камерами.
3. Переключение камеры в WinUSB и использовать libusb/libuvc (код не то, что высокая производительность, а не что созреть на Windows) и реализовать свой собственный интерфейс камеры

Теперь к правильной конструкции «кадра сервера»:

У нас также есть сервер кадров в нашем системном дизайне zSpace, в котором загружаются декомпрессированные изображения, сжатые камеры (четыре из них имеют почти 1 Гпиксель в секунду), информацию об обнаружении блога и 3D-позициях результаты триангуляции для нескольких клиентов (приложений, включая удаленный), при в то же время. Вся вещь с использованием общей памяти и/или сокетов - всего несколько сотен строк прямого кода C. Я реализовал его, и он работает на Windows и Linux.

Недостаток «улучшения» Microsoft лежит в невежестве для потребностей клиента, и я считаю, что его легко исправить.

Для аргументации предположим, что потоки сжатых камер сжаты (может быть MJPG/H.26x/HEVC/что-то новое и лучшее).

Пусть говорят, что есть несколько возможных классов клиентов: (? Мы хотим транскодирования там)

1. Client, что потоки исходных сжатых данных в сети для удаленных хостов.
2. Клиент, который хранит необработанные сжатые данные в локальном или удаленном постоянном хранилище (жесткий диск, ssd). (нужен ли там транскодирование?)
3. Клиент, который выполняет анализ сырого сжатого потока данных (от тривиального до сложного), но не нуждается в пикселях?
4. Клиент, который фактически манипулирует сжатыми данными и передает его вверх по течению - помните, что можно обрезать, вращать, например. JPEG без полной декомпрессии.
5. Клиент, которому нужны несжатые данные в формате HSI.
6. Клиент, которому необходимы несжатые данные в формате RGB с некоторыми фильтрами (например, гамма, цветовой профиль), применяемыми во время декомпрессии.

Достаточно? Сегодня все они получают NV12 (что фактически составляет еще большую потерю данных в терминах половины пропускной способности U (Cb) и V (Cr) выборок).

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

Фактически, правильная реализация должна учитывать потребности клиентов (и эта информация уже присутствует и доступна всем клиентам в виде переговоров типа носителя и атрибутов, которые управляют поведением графика). Затем он должен применять декомпрессоры и другие фильтры только тогда, когда это необходимо, уделяя пристальное внимание локальности кэша процессора и подавая запрошенные данные соответствующим клиентам из соответствующей памяти через соответствующие механизмы. Это позволит все виды оптимизаций в потенциальных перестановках смеси вышеупомянутого клиента и за его пределами.

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

Интересно, как Microsoft строит сетевой поток Hollolens? Через NV12? Или через еще один взлом?

"Разработчики, разработчики, разработчики ..." :(

обновления