[FFmpeg-devel] [PATCH] avcodec/qsvenc: make QSV encoder encode VAAPI and D3D11 frames directly

Wu, Tong1 tong1.wu at intel.com
Wed Jun 15 05:54:56 EEST 2022


> Quoting Wu, Tong1 (2022-06-08 06:47:27)
> > >
> > > Quoting Tong Wu (2022-06-07 11:22:16)
> > > > QSV encoder is able to encode frames with VAAPI or D3D11 pixel
> > > > format directly. This patch adds support for qsv encoder to accept
> > > > VAAPI and
> > > > D3D11 pixel formats as input.
> > >
> > > This looks like an ad-hoc hack to me. Encoders should not do these
> > > kinds of tricks.
> > >
> > > --
> > > Anton Khirnov
> >
> > Thanks for the comments. The MFXSurface is based on VaSurface on Linux
> > and D3D texture on Windows. Since the QSV encoder can accept
> > AV_PIX_FMT_QSV as input, it seems kind of reasonable to accept VAAPI
> > and D3D as its input. And it just may not look like a 'real' trick,
> > let's say, for example, make QSV encoder accept VULKAN format
> > directly. By adding this patch, we just want QSV encoder have more
> > input format supports like what nvenc does.
> 
> The difference with nvenc is that the nvenc API actually supports d3d
> textures directly, our encoder wrapper merely passes them through.
> 
> Your patch, on the other hand, derives a new device inside the decoder.
> The intent behind the hwcontext interface is that such operations should be
> left to the library caller, and are actually quite easy to do. So I don't see why
> is this patch really needed.
> 
> > Plus, this patch can really help the users who have hybrid transcode needs.
> 
> Could you elaborate? How would this patch be useful in this specific case.
> Why can't the callers dervice the device themselves?
> 
> --
> Anton Khirnov

It looks easier and more convenient for the users because they don't derive them manually.
But yes, I'm convinced that it may be not the work that an encoder should do. Thanks for the comments. 

Regards,
Tong


More information about the ffmpeg-devel mailing list