[FFmpeg-devel] [PATCH v2 6/6] lavc/qsvdec: Add VP9 decoder support

[Rogozhkin, Dmitry V]

On Thu, 2019-02-21 at 14:01 +0800, Li, Zhong wrote:
> > > @@ -90,6 +90,17 @@ static av_cold int
> > > qsv_decode_init(AVCodecContext
> > > *avctx)
> > >      }
> > >  #endif
> > > 
> > > +#if CONFIG_VP9_QSV_DECODER
> > > +    if (avctx->codec_id == AV_CODEC_ID_VP9) {
> > > +        static const char *uid_vp9dec_hw =
> > > "a922394d8d87452f878c51f2fc9b4131";
> > 
> > Should not be actually needed (and I hope it will work:)). VP9 hw
> > plugin is
> > actually a tiny compatibility stub which redirects everything to
> > the mediasdk
> > library.  Considering that you just add VP9 decoding support you
> > don't need
> > to care about compatibility (I hope). Hence, you can try to just
> > initialize VP9
> > decoder directly from the mediasdk library as you are doing for AVC
> > decoder.
> 
> Good point. But my question is that will it broken for the case "the
> latest ffmpeg + an old version MSDK"?
> Thus means:
> 1. Start from the version for MSDK support VP9 decoding, hw plugin is
> not needed. 
> 2. Or we don't care the compatibility "the latest ffmpeg + an old
> version MSDK", user should update MSDK.
> 
> If it is case 1, I am quite happy to remove vp9 hw plugin code. If it
> is case2, I would say I can't agree. 
> How do you think? 

This patch adds vp9 decoder support to ffmpeg-qsv. This feature was not
actually available previously in ffmpeg-qsv, so there will be versions
of ffmpeg which don't support vp9 decoder in qsv path. And potentially
there could be some versions of mediasdk which won't provide vp9
decoder at all or in a way anticipated by ffmpeg (without plugin if you
will agree to make this change). I don't see a problem here. Instead I
see another problem: will you be able to verify that current patch (to
initialize vp9 decoder via plugin)  actually is capable to work with
the old mediasdk versions? And what will happen if it is not or some
feature won't work because of some bug in this old mediasdk version?
Such a bug either won't be fixed at all or if it will be fixed,
mediasdk update will be required which most probably will simply allow
to work with vp9 decoder without mediasdk plugin.

Thus, I suggest to not complicate things and avoid pursuing
hypothetical compatibility with some old version of mediasdk library.
Mind also, that avoiding plugin path we actually avoid additional
memory allocations, .so loading overhead, etc.

More widely, I would actually suggest to revise existing mediasdk
plugins loading path and change it from loading plugins at the first
place to:
1. Try to initialize component directly from the library
2. If #1 fails, try to initialize component from the plugin
This will allow to avoid a cost of plugins loading when you don't
actually need to load them and will preserve compatibility with the old
versions of mediasdk.