For atomic drivers, use a test-only commit to fully exercise the
path that we will be using when rendering.
For legacy drivers, mask the variable portion of Broadcom modifiers
before matching with IN_FORMATS.
libdrm is inconsistent between returning -1 with an errno set
and just returning -errno as the return value. Figuring out which
behavior a given libdrm function has require reading the source :/
As it turns out, there *are* in fact hardware vendors dumb enough
to ship V4L2 decoders that output buffers which are unsupported by
any plane on their display hardware. By checking modifiers, we can
still fall back to GLES on GL_IS_SLOW=1 builds in this case.
It doesn't work well in practice for a few major reasons:
- It can result in the decoder writing on DMA-BUFs being used by the display
- It can generate page flip events that collide with Qt/SDL
- It can stall the decoder if the DMA-BUF has a fence on it from the display driver
The platforms that would most benefit (embedded V4L2 decoders)
either don't use frame pooling or don't synchronize with
modified DMA-BUFs unless eglCreateImage() is called each time.
Every renderer except SDL had opted-in for testing due to various
quirks discovered over the years, so just do away with this option
and test all renderers.
It's possible that modesetting will also change the resolution
not just the refresh rate. This can happen in cases where the
CRTC is currently set to 4K 30 Hz and we choose 1080p 60 Hz as
a better mode match for displaying a 1080p 60 FPS stream.
This case basically works like a degenerate case of a DRM hwaccel
without DRM master where we just provide EGL export functionality
except that we don't even need a DRM FD in this case.
There are patches floating around the FFmpeg list for this:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=12604
Performing this each time DrmRenderer is initialized leads to long
delays when choosing a decoder on embedded platforms, particularly
those like TH1520/JH7110 which lack accelerated GL drivers.
Replace the generic starfive hack with proper logic to examine the
supported enum values to select a colorspace. This fixes incorrect
colors with vs-drm on the TH1520.
Planes seem to be listed in descending order of capabilities
with later planes sometimes lacking scaling capabilities, which
is the case with vs-drm on the TH1520.
pixel_format is a global option which changes avctx->pix_fmt to the
given format, and overrides the AV_PIX_FMT_DRM_PRIME requirement of a
decoder. So v4l2 out of tree patches has done some exception which is
not perfectly nice, therefore limit this option only if the given
decoder is v4l2 decoder. Otherwise rockchip mpp based ffmpeg decoders
can not work properly
