[FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2 support

[Fu, Linjie]

> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Mark Thompson
> Sent: Sunday, March 8, 2020 00:15
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2
> support
> 
> On 05/03/2020 02:49, Fu, Linjie wrote:
> > 2. recon surface of Y210 or 444 (AYUV and Y410 in media-driver) depends
> on the surface hint [3] in
> > libva and corresponding code in media-driver to resize the recon surface
> which is not upstreamed
> > yet.
> 
> What is the reasoning for forcing the user to pass new extra attributes with
> this rather than handling it transparently so that it works like all other
> encoders?
> 
> In some places in Mesa surfaces are reallocated with different properties
> when they are used for a purpose they don't currently support, which avoids
> weird constraints being exported to the user (e.g. see
> <https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/v
> a/surface.c#n1000>).  Since reconstructed picture surfaces are pretty unlikely
> to be used for anything else (just being copied out for debugging maybe?), it
> seems like an answer like that would be simpler in this case too.  (Though
> perhaps I'm missing something weird about the Intel hardware which makes
> this case uglier.)
> 

Implemented the surface reallocation inside media driver in [1], merged the query
support in [2],  verified that it works for both AYUV(or XYUV)/Y410, yuyv422.

And for Y210, it seems to be better to implement render target support in
vaapi_encoder in this patch as well:
{ "YUV422_10", VA_RT_FORMAT_YUV422_10,    10, 3, 1, 0 },

Hence patch LGTM with or without above modifications, thx.

- Linjie

[1] < https://github.com/intel/media-driver/pull/915>
[2] < https://github.com/intel/media-driver/pull/855>