[FFmpeg-devel] [PATCH 2/3] kmsgrab: Do not require the modifier to stay constant.

[Mark Thompson]

On 03/11/2020 23:17, Bas Nieuwenhuizen wrote:
> As we get a new set of objects each frame anyway, we
> do not gain anything by keeping the modifier constant.
> 
> This helps with capturing when switching your setup a
> bit, e.g. from ingame to desktop or from X11 to wayland.
> ---
>   libavdevice/kmsgrab.c | 7 -------
>   1 file changed, 7 deletions(-)
> 
> diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
> index 2a03ba4122..8b698b7f30 100644
> --- a/libavdevice/kmsgrab.c
> +++ b/libavdevice/kmsgrab.c
> @@ -176,13 +176,6 @@ static int kmsgrab_get_fb2(AVFormatContext *avctx,
>           err = AVERROR(EIO);
>           goto fail;
>       }
> -    if (fb->modifier != ctx->drm_format_modifier) {
> -        av_log(avctx, AV_LOG_ERROR, "Plane %"PRIu32" framebuffer "
> -               "format modifier changed: now %"PRIx64".\n",
> -               ctx->plane_id, fb->modifier);
> -        err = AVERROR(EIO);
> -        goto fail;
> -    }
>       if (fb->width != ctx->width || fb->height != ctx->height) {
>           av_log(avctx, AV_LOG_ERROR, "Plane %"PRIu32" framebuffer "
>                  "dimensions changed: now %"PRIu32"x%"PRIu32".\n",
> 

I included this case because it's really a format change and may not be compatible with something happening later.

For example: on Intel you might be capturing a Y-tiled framebuffer and feeding it directly (no copy step) to an encoder via VAAPI.  If it then switches to linear most things will continue to work (import is still fine), but the encoder will barf in an opaque way because it doesn't support non-Y-tiled inputs.

Is that actually helpful?  I'm not sure.

Can you explain a bit more about what is changing in the switching cases you are thinking of, so that the tradeoffs are maybe a bit clearer?

Thanks,

- Mark