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

Linjie Fu linjie.justin.fu at gmail.com
Fri Jul 24 09:46:43 EEST 2020


On Mon, Jul 20, 2020 at 10:32 PM Linjie Fu <linjie.justin.fu at gmail.com> wrote:
>
> On Fri, May 15, 2020 at 3:21 PM Fu, Linjie <linjie.fu at intel.com> wrote:
> >
> > > 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.
> >
> > [1] < https://github.com/intel/media-driver/pull/915>
> > [2] < https://github.com/intel/media-driver/pull/855>
>
> Since it's well supported for now, prefer to apply this soon
> together with the patch for 422 10-bit encoding :
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/1595254554-12809-1-git-send-email-linjie.fu@intel.com/

Applied, thx.

- Linjie


More information about the ffmpeg-devel mailing list