WebCam MJPGキャプチャストリームはWindows 10で利用できません

Question

Windows 10ビルド10.1607.14393.10（別名Anniversaryエディション）では、もうMJPGキャプチャストリームを取得できません。 MJPGとYUY2の両方の解像度に使用されていましたが、IBaseFilterソースが何かに接続される前にDirectShow（カーネルストリーミング）とMedia Foundation MJPGでYUY2のみをNV12に変換しています。カメラが異なる複数のシステムで試しました。どのようなアイデアが間違っているかもしれない？

 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); 
... 

MMFで

：ウェブカメラからのWindows 10周年記念アップデートMJPGビデオで

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のカメラフレームサーバ" によって捕獲され、その「複数のクライアントがカメラデバイスからビデオフレームにアクセスできるようにする」と自己紹介しています。同じことがMike Mに言及されています。

TopoEditの2番目のインスタンスとしてカメラを共有している複数のクライアントを1人も見ることができませんでした。ハードウェアリソースの不足のため、ハードウェア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.

明らかに、この「改善」は多くを捉えました。

更新。以下で定義されるレジストリ値を作成することにより、新しいフレームサーバ機能を使用する動作をシステム全体で無効にすることができることが検出されました。 Media Foundation APIがこの値を認識すると、元のコードパスを選択して、Frame Serverを直接バイパスする「ハードウェア」（KSプロキシ）と通信します。

• キー名：
  • HKEY_LOCAL_MACHINE \ソフトウェア\マイクロソフト\ Windowsのメディア財団\プラットフォーム（64ビットアプリケーション、32ビットOSで32ビットアプリケーション）
  • HKEY_LOCAL_MACHINE \ソフトウェア\ WOW6432NODE \マイクロソフト\ Windowsのメディア財団\プラットフォーム（64ビットOSで32ビットアプリケーション）
• 値の名前： "EnableFrameServerMode" REG_DWORD
• 値：0
これがあるので

Answer 2

答えは私が最初にそのいくつかの回避策を述べてみましょうハッキングから高価な開発に至るまで存在

1. （ハック）は、元のWindows 10、それと力負荷の遅延リンクから古いmfcore.dllを取りますあなたのローカルコピー - これはハックですそれを出荷しない自宅でそれを試してみません。
2. ksproxy.axが不十分であるか、最新のmfkproxyで置き換えてカメラと通信する独自​​のレイヤーを実装します。
3. スイッチのWinUSBにカメラや「フレームサーバ」の適切な設計に今、あなた自身のカメラインタフェース

を（Windows上で成熟コードそれほど高くないパフォーマンスではなく）/ libuvcをlibusbを使用して実装します。

私たちのzSpaceシステム設計では、サーバが圧縮解除された画像、圧縮されたカメラフィード（約1Gpixel /秒で4つ）、ブロブ検出情報、3Dポーズの三角測量結果を複数のクライアント（リモートを含むアプリケーション）同じ時間。共有メモリおよび/またはソケットを使用することは、まさに数百行のストレートCコードです。私はそれを実装し、WindowsとLinuxで動作します。

マイクロソフトの「改善」の欠点は、クライアントのニーズに無知であり、修正するのは簡単だと思います。

引数のために、カメラストリームが圧縮された形式（MJPG/H.26x/HEVC /もっと新しいものかもしれません）と仮定しましょう。

は、クライアントのいくつかの可能なクラスがあるとしましょう：リモートホストのためのネットワークに、生の圧縮データをストリーム

1. クライアントが（私たちはそこにトランスコーディングをしたいですか？）。
2. 生の圧縮データをローカルまたはリモートの永続ストレージ（ハードドライブ、ssd）に保存するクライアント。 （トランスコーディングが必要ですか？）
3. 生の圧縮データストリーム解析（簡単なものから複雑なものまで）はありますが、ピクセルは必要ありません。
4. 圧縮されたデータを実際に操作して上流に渡すクライアントです。完全な解凍を行わないJPEG。
5. HSI形式の圧縮されていないデータが必要なクライアント。
6. 圧縮解除中に適用されるいくつかのフィルタ（たとえば、ガンマ、カラープロファイル）を使用して、RGB形式の非圧縮データを必要とするクライアント。

十分ですか？今日、それらはすべてNV12（U（Cb）およびV（Cr）サンプルの半分の帯域幅に関して実際にはさらに大きなデータ損失を構成します）。

マイクロソフトではフレームサーバーを実装しているため、データを一方向または別の方法で、さらには複数の方法で圧縮解除する必要があります。圧縮されていないデータはメモリに格納されなければならず、クライアントがその恩恵を受ける場合に備えて（条件付きで）そこに保管することができます。ほとんどコーディング技能とスプリッターと誰許容初期メディアグラフデザインは、クライアント（シンク）添付を有するピンにデータをプッシュ条件スプリッタを実装することができます。

実際には、実装にはクライアントのニーズを考慮する必要があります（この情報は既に存在し、グラフの振る舞いを制御するメディアタイプのネゴシエーションと属性の方法ですべてのクライアントからすぐに利用できます）。そして、それは、CPUのキャッシュの局所性に細心の注意を払って、適切なメカニズムを通して適切なメモリから適切なクライアントに要求されたデータを果たす必要なときにだけ圧縮解除し、他のフィルタを適用する必要があります。前述のクライアントとそれ以降の組み合わせの潜在的な順列において、あらゆる種類の最適化が可能になります。

マイクロソフトでは、この単純な（些細なことではないにしても）一連の要件を満たすフレームサーバーの設計と実装を支援する必要がある場合、膨大な種類のアプリケーションやサービスを壊す代わりに、質問するだけです。

マイクロソフトがHollolensの入力をネットワークストリームにどのように計画しているのだろうか？ NV12経由で？あるいはもう一つのハックを介して？

"開発者、開発者、開発者..." :(