Support formats other than NV12 for Texture Streaming

[space928]

Is your feature request related to a problem? Please describe.
Currently the ICoreWebView2ExperimentalTextureStream interface only supports NV12 texture streams which are great for video capture devices which use this format natively but is a pain for anything else. With NV12 the bit depth and colour resolution are extremely limited which is problematic when viewing sharp features from technical rendering engines. It also results in an unnecessary colour space conversion from RGBA to YUV. For our use case we want to be able to stream rendered frames from an external rendering engine into WebView2.

Describe the solution you'd like and alternatives you've considered
Ideally we would be able to choose whichever DXGI format we wanted when calling ICoreWebView2ExperimentalTextureStream::CreateTexture and GetAvailableTexture; these would function as they currently do but would provide a texture in the desired format. The new function signatures could look like:

// Create a new texture for streaming with the specified format
public HRESULT CreateTexture(UINT32 widthInTexels, UINT32 heightInTexels, DXGI_FORMAT format, ICoreWebView2ExperimentalTexture ** texture);
// Get an available texture for streaming with the specified format (returning HRESULT_FROM_WIN32(ERROR_NO_MORE_ITEMS) if no textures are available in the specified format)
public HRESULT GetAvailableTexture(DXGI_FORMAT format, ICoreWebView2ExperimentalTexture ** texture);
// Get an available texture for streaming in any format (the caller is responsible for checking the format of the returned texture using d3dTexture->GetDesc())
public HRESULT GetAvailableTexture(ICoreWebView2ExperimentalTexture ** texture);

If supporting all DXGI formats is unfeasible or if the dependency on dxgiformat.h needs to be avoided, a subset of the DXGI_FORMAT enum could be implemented in WebView2Experimental.h, ideally with a direct correspondance to the DXGI_FORMAT enum.
For our use case the DXGI_FORMAT_R8G8B8A8_UNORM (or an equivalent BGRA format) is what we need.

AB#45223747

[novac42]

Thanks for reaching out. I've added it to our backlog for evaluation.

[space928]

Hi,
I was just curious if there were any updates on this. Is it likely to be implemented? Is there anything else I can do to help?

[novac42]

@space928 sorry for the wait but it's right now in lower priority in our backlog due to bandwidth. Could you please shed some light on what kind of app you are building, and if there's any pending timeline relying on this feature?

[space928]

I understand the wait and appreciate that the issue is getting some attention.

We're trying to integrate our in-house 3d renderer with WebView2 as the front-end. For a proof of concept NV12 works, but technical rendering the artifacts from NV12 become apparent. We would also like to be able to render from texture-streamed GBuffers in WebGL, for which NV12 is really unusable. We're currently still prototyping, but this is a feature we need to bring our product to market.

I'm hoping that it's a fairly simple feature to implement, as far as I can tell WebView2 doesn't actually care what format the texture is, and the requirement for NV12 is just an artificial limitation.

[victorhuangwq]

@space928 I have looked into it, and it's actually a limitation of Chromium. The NV12 format is the only supported format for video frames in Chromium.