dmabuf-capture doesn't work #1965
Comments
|
vainfo for desktop: vainfo for laptop: |
|
Issue one is that on AMD you can't use VAAPI to encode from the screen because the AMD drivers cannot implicitly convert from bgr0 to nv12, while Intel allows to do this implicitly while encoding. Issue two is probably that wlroots is sending dmabuf-capture a frame containing 2 dmabuf objects with 2 layers, but libavutil can only import single-object frames, "[AVHWFramesContext @ 0x55efabde80c0] VAAPI can only map frames made from a single DRM object.". This is a regression and incorrect, since all RGB drm format IDs are composed of single layer. Worse, it might cause other clients to crash because the number of layers is determined via the drm format sent, yet wlroots is referencing a second layer while sending objects. |
|
This is the output with bgr0: |
|
Its probably because of issue 2 like I said. |
|
Thanks for the explanation, @cyanreg |
|
Ping? |
What is the modifier? Many Intel modifiers use two planes.
Yes, they need to use
I don't think that's true, see above. |
|
0x100000000000004 which seems to be I915_FORMAT_MOD_Y_TILED_CCS. |
|
Alright, closing as a libavutil bug. Note that one can disable modifiers temporarily by setting
I think it's fine if clients need to strip the alpha channel manually. DMA-BUFs coming from clients may have an alpha channel, so clients should better be prepared for this anyway. Also some consumers might require an alpha channel (e.g. KMS planes sometimes accept ARGB but not XRGB). |
On my desktop (AMD RX 580):
On my laptop (Intel Core i5-5200U):
The text was updated successfully, but these errors were encountered: