Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support video encoding and decoding APIs #2330

Closed
zmerp opened this issue Dec 29, 2021 · 2 comments
Closed

Support video encoding and decoding APIs #2330

zmerp opened this issue Dec 29, 2021 · 2 comments
Labels
area: api Issues related to API surface help required We need community help to make this happen. type: enhancement New feature or request

Comments

@zmerp
Copy link
Contributor

zmerp commented Dec 29, 2021

Vulkan Video extensions were announced earlier this year and GPU vendors are working on the support. At the time of writing, this/this is the state of the art.

More recently it was announced the Direct3D 12 Video API. Encoder support landed this month.

It would be valuable for wgpu to provide a backend agnostic API for video encoding/decoding, even within a separate crate.

@kvark kvark added area: api Issues related to API surface help required We need community help to make this happen. type: enhancement New feature or request labels Dec 29, 2021
@dsseng
Copy link
Contributor

dsseng commented Dec 30, 2021

Vulkan video is still in the development. Support pending for AMD/Intel, so first these can be used:
Linux - VA-API (can be made to work over VDPAU on NVIDIA)
macOS - AVFoundation (does MoltenVK already support Vulkan video extensions?)
Windows - DX12 Video API (probably DXVA on DX11?)

Probably waiting for at least a couple months will be better, since RADV/ANV/MoltenVK/Windows drivers need to mainline and stabilize extensions, then something could be made as an example on top of ash and then integrated into wgpu.
It would be a bit hard to implement video on backends other than Vulkan, since it would be necessary to import frames as DMA-BUFs (or similar objects named differently on a platform) from another library to maintain zero-copy GPU memory ops (similar to #1733, #2320 as well).

@cwfitzgerald
Copy link
Member

I don't think this is really in-scope for wgpu itself to handle in its current form. We do, however want to have the interop capabilities so users could implement this themselves and use the decoded result in wgpu.

Additionally these apis are very low level, so the right api would probably need a lot of experimentation, that should be done out-of-repo.

@cwfitzgerald cwfitzgerald closed this as not planned Won't fix, can't repro, duplicate, stale Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: api Issues related to API surface help required We need community help to make this happen. type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants