> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> Mark Thompson
> Sent: Sunday, March 8, 2020 00:15
> To: ffmpeg-devel@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>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
