RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
Page: V4L2 drmprime support
Pages
ALSA Surround Sound and Upmixing Applications using mpv Compiling distro releases for macOS Display synchronization Downscaling with Hermite GPU Next vs GPU Hardware decoding on Linux Home IR remotes Interpolation Language bindings Option replacement list Scripting language bindings Stuff to do Upscaling User Scripts V4L2 drmprime support Video output shader stage diagram Video4Linux2 Input Which VO should I use Zsh completion customization _ [semi obsolete] Cocoa Constraints
1 V4L2 drmprime support
Philip Langdale edited this page 2023-09-15 16:54:36 -07:00
Table of Contents

v4l2 drmprime support in mpv

mpv includes support for consuming drmprime dmabufs produced by v4l2 (either v4l2m2m or v4l2-request) to do zero-copy GPU rendering. However, this support relies on there being a source capable of producing these dmabufs. Unfortunately, upstream ffmpeg doesn't have this capability. It only supports v4l2m2m with decoded video frames being copied to system memory first, and doesn't support the v4l2-request API at all. If you try and use hardware decoders via v4l2 with upstream ffmpeg, you will not get zero-copy dmabuf support, and likely won't get working output at all.

ffmpeg forks with drmprime dmabuf support

At the current time, drmprime dmabuf support is only available in ffmpeg forks. It appears (we are not experts on this ecosystem) that there are two primary forks, one for Raspberry Pi devices (the main v4l2m2m based devices) and one for v4l2-request.

You may also find clearer recommendations on the ffmpeg fork to use from your embedded device's community and documentation. As mpv only cares about being provided dmabufs, we have minimal dependencies on the specifics of how the fork produces them.

Will we ever see v4l2 drmprime support merged into upstream ffmpeg

It seems unlikely. There isn't really anyone active in upstream ffmpeg that cares about this functionality, and it doesn't appear that anyone involved with the forks is interested in sending patches back - so we're likely to remain in this situation for the indefinite future.