[FFmpeg-trac] #8542(avdevice:reopened): ffmpeg use kmsgrab on wayland not working

FFmpeg trac at avcodec.org
Thu May 7 21:42:11 EEST 2020

#8542: ffmpeg use kmsgrab on wayland not working
             Reporter:               |                    Owner:
  chenjie199234                      |
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:  avdevice
              Version:  git-master   |               Resolution:
             Keywords:  kmsgrab      |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  1            |

Comment (by Lynne):

 The Mesa PR is here:
 It might say its 2 months old but it is in fact 2 years old, and no matter
 how much I've asked for it to be merged on IRC its development is beyond
 Its a really big blocker to doing anything useful with Vulkan on linux. I
 too, really need this merged to get my project working.
 The Vulkan API with the modifiers EXT is fully capable of dealing with any
 DMABUF thrown at it. And the hwcontext can too, deal with any DMABUF
 thrown at it. Its pedantically correct according to the specs. It
 definitely does not produce multiplane images however, merely a single
 image composed of multiple objects (dmabuf fd mapped as VulkanMemory).
 In case of multiplane images (e.g. NV12 or yuv420p), it produces one image
 per plane, so still not multiplanar. Multiplanar images in Vulkan are
 generally crap and you shouldn't use them, even according to official
 Intel devs.
 Unfortunately, without modifiers, Vulkan assumes all images on Intel use
 either Y tiling or linear images. And the only thing producing Y tiled
 images on Intel is VAAPI. Hence why only VAAPI->DMABUF->Vulkan works.
 Compositors _cannot_ draw to Y tiled buffers, only to X tiled buffers.
 Even if you disable compressed surfaces, and you try to import a display
 DMABUF, you'll get garbage out, as the tiling will be wrong. VAAPI will
 quite happily work though.

 In the meantime, I'm writing this: [https://github.com/cyanreg/txproto].
 It uses the sway export dmabuf extension and the screencopy extension to
 capture the screen and filter/encode it, although it can use the kmsgrab
 libavdevice library too. If you don't want to modify wlroots to disable
 the modifiers (I can give a patch on IRC), you can use the screencapture
 protocol to upload the image to either Vulkan, OpenCL or VAAPI (or even
 CUDA) and encode it that way, along with sound (and unlike ffmpeg, it'll
 have frame-perfect audio-video sync).

Ticket URL: <https://trac.ffmpeg.org/ticket/8542#comment:8>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list