It seems that we do not need to use IMFYCbCrImage. We could use D3D11YCbCrImage instead of IMFYCbCrImage.

attachment 8987007 [details] [diff] [review] just calls VideoData::CreateAndCopyData() with mKnowsCompositor. With it, VideoData::CreateAndCopyData() creates D3D11YCbCrImage if it is possible. https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaData.cpp#326

Comment on attachment 8987007 [details] [diff] [review] patch - Remove IMFYCbCrImage usage in WMFVideoMFTManager::CreateBasicVideoFrame() Review of attachment 8987007 [details] [diff] [review]: ----------------------------------------------------------------- Sounds good to me in principle but I don't know that well the implications. Deferring the review to Matt.

The difference between these two is that IMFYCbCrImage just takes a reference to the IMFMediaBuffer in the constructor, instead of making a copy/upload. The upload is done when we request the TextureData. This moves the upload time from the decoder thread to the image bridge child thread, and (at least when I wrote it) gave us better throughput, since we can start decoding the next frame without waiting. It was noticeable when decoding 4k videos in software. We only get to use that image type for one path though, since most decoders don't give us a refcounted handle to the image data.

Intent of this bug was to recycle ID3D11Texture2D during doing h.264 software decoding. I am going to try another way.

Rebased.

With attachment 8988045 [details] [diff] [review], IMFYCbCrImage becomes to use D3D11YCbCrRecycleAllocator and DXGIYCbCrTextureAllocationHelper to allocate DXGIYCbCrTextureData.

Pushed by sikeda@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b0227fc53bf6 Recycle TextureClient at IMFYCbCrImage r=mattwoodrow