タグ付けされた質問 「directx」

DirectX SDKのインストールに問題があるようです。インストール中はすべてが順調に進んでいるようですが、最後に次のメッセージが表示されます。 セットアップに失敗しました。再頒布可能パッケージのインストール中にエラーが発生しました。開いているプログラムをすべて閉じて、セットアップを再度実行してください。問題が解決しない場合は、DirectX開発者サポートに連絡してください。 エラーコード：S1023 さて、私は開いているすべてのプログラムを閉じて再度インストールしようとしましたが、同じエラーが発生します。エラーコードとはS1023？私はグーグルを試しましたが、それに対処する方法について多くの異なる応答を見つけました、そして私は何をすべきかわかりません。 のログファイルを調べてみましたC:\Windows\Logs。2つのログファイルがDirectX.logあり、DirectX_SDK.log。「エラー」や「失敗」の兆候は見られません。 実際、DirectX.logの最後の行は次のとおりです。 11/04/10 18:36:27：dsetup32：インストールは値0で終了しました=インストールは成功しました 誰か助けてくれませんか？Vista（x64）を実行しています。

178 directx  vista64 

モデルビューの射影行列をどのような目的で使用していますか？シェーダーにモデルビュー投影行列が必要なのはなぜですか？

102 opengl  directx  3d 

デスクトップ複製を使用してデスクトップをキャプチャし、Intel hardwareMFTを使用してそれをh264にエンコードするコードに取り組んでいます。エンコーダーは、入力としてNV12形式のみを受け入れます。DXGI_FORMAT_B8G8R8A8_UNORMからNV12へのコンバーター（https://github.com/NVIDIA/video-sdk-samples/blob/master/nvEncDXGIOutputDuplicationSample/Preproc.cpp）があり、DirectX VideoProcessorに基づいています。 問題は、特定のインテルグラフィックスハードウェアのVideoProcessorがDXGI_FORMAT_B8G8R8A8_UNORMからYUY2への変換のみをサポートし、NV12はサポートしないことです。GetVideoProcessorOutputFormatsを介してサポートされているフォーマットを列挙することで同じことを確認しました。VideoProcessor Bltはエラーなしで成功し、出力ビデオのフレームが少しピクセル化されているのを確認できましたが、よく見るとわかります。 おそらく、VideoProcessorは次のサポートされている出力形式（YUY2）にフェイルオーバーしただけで、入力が構成済みのNV12であると考えるエンコーダーに知らずにフィードしています。NV12とYUY2の間でバイトオーダーやサブサンプリングなどの違いがほとんどないため、フレームの障害や大きな破損はありません。また、NV12変換をサポートするハードウェアでピクセル化の問題はありません。 そこで、このコードに基づいたピクセルシェーダーを使用して色変換を行うことにしました（https://github.com/bavulapati/DXGICaptureDXColorSpaceConversionIntelEncode/blob/master/DXGICaptureDXColorSpaceConversionIntelEncode/DuplicationManager.cpp）。ピクセルシェーダーを機能させることができます。参照用にコード（https://codeshare.io/5PJjxP）もアップロードしました（可能な限り簡略化しています）。 これで、クロマとルマの2つのチャネル（ID3D11Texture2Dテクスチャ）が残りました。そして、2つの個別のチャネルを1つのID3D11Texture2Dテクスチャに効率的にパックして、同じものをエンコーダーに送ることができるかどうか、本当に混乱しています。YおよびUVチャネルをGPUの単一のID3D11Texture2Dに効率的にパックする方法はありますか？CPUベースのアプローチはコストが高く、可能な限り最高のフレームレートを提供できないため、私はCPUベースのアプローチにうんざりしています。実際、テクスチャをCPUにコピーすることすらしません。CPUとGPUの間でコピーをやり取りすることなく、GPUでそれを行う方法を考えています。 私はかなり長い間これを研究してきましたが、何の進歩もありませんでした。 /** * This method is incomplete. It's just a template of what I want to achieve. */ HRESULT CreateNV12TextureFromLumaAndChromaSurface(ID3D11Texture2D** pOutputTexture) { HRESULT hr = S_OK; try { //Copying from GPU to CPU. Bad :( m_pD3D11DeviceContext->CopyResource(m_CPUAccessibleLuminanceSurf, m_LuminanceSurf); D3D11_MAPPED_SUBRESOURCE resource; UINT subresource = …

9 directx  directx-11  yuv  ms-media-foundation  pixel-shader 

DesktopDuplication APIを使用してデスクトップをキャプチャし、サンプルをGPUでRGBAからNV12に変換して、MediaFoundationハードウェアH264 MFTにフィードしています。これは、Nvidiaグラフィックスとソフトウェアエンコーダーで正常に動作しますが、インテルグラフィックスハードウェアMFTのみが使用可能な場合は失敗します。ソフトウェアMFTにフォールバックすると、同じIntelグラフィックマシンでコードが正常に機能します。また、Nvidiaグラフィックスマシンのハードウェアでエンコードが実際に行われるようにしました。 Intelグラフィックスでは、MFTはMEError（"Unspecified error"）を返します。これは最初のサンプルが供給された直後にのみ発生し、後続のProcessInputの呼び出し（イベントジェネレーターがMETransformNeedInputをトリガーしたとき）は"呼び出し先は現在それ以上の入力を受け付けていません"を返します。MFTがこれらのエラーを返す前に、さらにいくつかのサンプルを消費することはまれです。この動作は混乱を招くので、イベントジェネレーターがIMFAsyncCallbackを介してMETransformNeedInputを非同期でトリガーする場合にのみサンプルをフィードし、サンプルがフィードされるとすぐにMETransformHaveOutputがトリガーされるかどうかを適切にチェックします。同じ非同期ロジックがNvidiaハードウェアMFTとMicrosoftソフトウェアエンコーダーで正常に動作するとき、これは本当に困惑します。 インテルフォーラム自体にも同様の未解決の質問があります。私のコードは、以下のようにエンコーダーにd3dデバイスマネージャーも設定しているという事実を除いて、インテルスレッドで言及されているものに似ています。 また、他に3つのスタックオーバーフロースレッドがあり、ソリューションが提供されていない同様の問題を報告しています（MFTransformエンコーダー-> ProcessInputがE_FAILを返します＆ Intel MFTエンコーダーのD11テクスチャからIMFSampleを作成する方法＆非同期MFTがMFTransformHaveOutputイベントを送信していません（インテルハードウェアMJPEGデコーダーMFT））。私はこれを改善することなく、可能なすべてのオプションを試しました。 色変換コードは、インテルメディアSDKサンプルから取得されます。ここに私の完全なコードもアップロードしました。 d3dマネージャーを設定する方法： void SetD3dManager() { HRESULT hr = S_OK; if (!deviceManager) { // Create device manager hr = MFCreateDXGIDeviceManager(&resetToken, &deviceManager); } if (SUCCEEDED(hr)) { if (!pD3dDevice) { pD3dDevice = GetDeviceDirect3D(0); } } if (pD3dDevice) { // NOTE: Getting ready for …

9 video-streaming  directx  h.264  ms-media-foundation  hardware-acceleration 

私は、Live555とWindows Media FoundationのWindows 10のハードウェアエンコーダーを使用して、RTPストリーム上でH264ビデオとしてデスクトップ（NV12形式のDirectXサーフェス）をストリーミングしようとしており、ffplay（ffmpeg 4.2）によってレンダリングされることを期待しています。しかし、以下のような緑色の画面しか表示されません、 私は呼ばMFWebCamToRTP mediafoundationサンプル＆ハードウェアMFTを用いた符号化のDirectX表面を代わりウェブカムのDirectXの面への入力ソースをLive555では者FramedSourceを実装し、変更するため。 以下は、DirectXサーフェスから入力サンプルをフィードするLive555のdoGetNextFrameコールバックの実装の抜粋です。 virtual void doGetNextFrame() { if (!_isInitialised) { if (!initialise()) { printf("Video device initialisation failed, stopping."); return; } else { _isInitialised = true; } } //if (!isCurrentlyAwaitingData()) return; DWORD processOutputStatus = 0; HRESULT mftProcessOutput = S_OK; MFT_OUTPUT_STREAM_INFO StreamInfo; IMFMediaBuffer *pBuffer = NULL; IMFSample …

9 ffmpeg  video-streaming  directx  h.264  ms-media-foundation 

問題文： IntelハードウェアMFTはGOP設定を順守していないため、リアルタイムアプリケーションでより多くの帯域幅が消費されます。同じコードがNvidiaハードウェアMFTで正常に機能します。 バックグラウンド： 私は、Windows10マシンでMediaFoundation H264ハードウェアエンコーダーを使用して、DesktopDuplication APIを通じてキャプチャされたNV12サンプルをビデオストリームにエンコードし、LAN上でリアルタイムにストリーミングおよびレンダリングしようとしています。 エンコーダーは出力サンプルを配信する前に最大25フレーム（GOPサイズ）をバッファリングしていたため、最初はエンコーダーでの過度のバッファリングに直面していました。いくつかの調査の結果、CODECAPI_AVLowLatencyModeを設定すると待ち時間が短縮され、品質と帯域幅が少し低下することがわかりました。 CODECAPI_AVLowLatencyModeプロパティを設定すると、パフォーマンスは少し向上しましたが、リアルタイムの要件には達しませんでした。エンコーダーは、少なくともサンプルを生成する前に最大15フレームをバッファリングするように見えます（出力に約2秒の遅延が導入されています）。また、この動作は、低いフレームレートが構成されている場合にのみ顕著になります。60FPSでは、出力はほぼリアルタイムで、視覚的に目立つ遅延はありません。 実際、フレームレートが30FPS未満に設定されている場合にのみ、バッファリングが人間の目で認識されます。また、遅延はFPS構成に反比例して増加します。25FPSでの遅延は数百ミリ秒であり、FPSが10（一定レート）に構成されている場合は最大3秒になります。おそらく、FPSを30（60FPSなど）より大きく設定すると、エンコーダバッファがすぐにオーバーフローして、目立たない遅延のサンプルが生成されると思います。 最近、CODECAPI_AVEncCommonRealTimeプロパティ（https://docs.microsoft.com/en-us/windows/win32/directshow/avenccommonrealtime-property）を試して、帯域幅の消費を避けるために入力フレームレートを下げるときにパフォーマンスが向上するかどうかを確認しましたただし、その呼び出しは「パラメーターが正しくありません」エラーで失敗し ます。 私の実験： 一定のフレームレートを維持し、エンコーダーにリアルタイム出力を生成させるために、同じサンプル（以前に保存されたサンプル）を30FPS / 60FPSの一定のレートでエンコーダーに供給しています。私はこれを最大10FPS（または必要な任意のFPS）でのみキャプチャし、同じサンプルを3回またはEMULATED_FRAME_RATE / ACTUAL_FRAME_RATE比に基づいたレートで正確に供給して30 / 60FPSを偽造することでこれを行っています（例：30 / 10、60 / 15 、60/20）一定の間隔でギャップを正確に埋めます。たとえば、10秒間変化がない場合、同じサンプルを30 * 10回（30FPS）エンコーダーに供給しました。このアプローチについては、いくつかのオープンソースGithubプロジェクトから、またchromiumの実験的なコードサンプルからも学びました。また、私は知らされていました（主にSO、 また、他のフォーラムでは、これがリアルタイム出力のためにエンコーダーをプッシュする唯一の方法であり、それを回避する方法はありません。 上記のアプローチはほぼリアルタイムの出力を生成しますが、以前に保存したサンプルのみをエンコーダーに供給している場合でも、予想よりも多くのデータを消費します。 出力ビットレートは、Intel MFTでは常に350KBpsから500KBpsの範囲にとどまり、NVidia MFT（30FPSおよび500KBビットレート構成）では80KBpsから400KBpsの間で変化します。画面のコンテンツが30FPSで変化するか0FPS（アイドル）で変化するかは関係ありません。この場合、NVidiaハードウェアエンコーダの方がいくらか優れているようです。 実際、画面のアイドル時間中に、エンコーダーは前述の速度よりも毎秒多くのデータを生成していました。より大きなGOPサイズを設定することで、 NVidiaデバイスのデータ消費を削減できました（現在のGOPサイズは16Kです）。ただし、画面のアイドル時のデータ消費量はIntelグラフィックス620ハードウェアでは約300KBps、NVidia GTX 1070（構成：500KBビットレートおよび30FPS）では50KBps〜80KBpsのままですが、これは許容できません。おそらく、インテルのハードウェアMFTはGOP設定をまったく順守していないか、改善が目立ちません。 また、非常に低いビットレートを設定することで、IntelとNvidiaのハードウェアでアイドル時間のデータ消費をそれぞれ〜130KBpsと〜40KBpsに下げることもできましたが、これも許容できないため、ビデオ品質も低下します。 入力サンプル間で変更が発生しなかった場合に、最大10KBps未満の出力を生成するようにエンコーダーを構成する方法はありますか？変更が発生しない場合、私は実際には〜0KBの出力を目指していますが、〜10KBpsはある程度許容可能です。 更新： 私は、以下に、いくつかのパラメータを微調整することにより、NVidiaのMFTのアイドルタイムデータの消費量をダウンさせることができるよ400キロバイトのビットレート設定で〜20kbpsの、そして以下の100キロバイトのビットレート設定で〜10KBps。これは説得力があります。ただし、同じコードで同じエンコーダ構成を使用すると、Intelマシンでは20〜40倍のデータが生成されます。インテル（インテルグラフィックス620）はGOP設定を順守していません。私はGOPを256からINT_MAXの間で変化させてみましたが、IntelハードウェアMFTの出力では何も変化していないようです。 アップデート2： エンコーダープロパティで遊んだ後（eAVEncCommonRateControlMode_CBRの代わりにeAVEncCommonRateControlMode_UnconstrainedVBRでCODECAPI_AVEncCommonRateControlModeを構成しただけです）、画面のアイドル時にインテルMFTが3KBpsデータを生成することがわかりましたが、最初の数秒間だけ（おそらく約3〜8秒） 、それから同じ話に戻ります。数秒後、エンコーダはサンプルと比較するキーフレームへの参照を失い、その時点以降は回復していないようです。GOPが16/128/256/512/1024でもINT_MAXでも、動作は同じです。 エンコーダ構成： リファレンス：http : //alax.info/blog/1586 const int EMULATED_FRAME_RATE = …

8 video-streaming  directx  h.264  ms-media-foundation  mft