[FFmpeg-devel] [PATCH v2 1/7] lavc/qsvenc: enable ICQ and ICQ_LA on Linux

[Li, Zhong]

> > On 05/11/18 12:15, Zhong Li wrote:
> > > ICQ/ICQ_LA are enabled with MSDK V1.28
> > >
> > > One example of ICQ_LA:
> > > ffmpeg -hwaccel qsv -c:v h264_qsv -i in.mp4 -c:v h264_qsv
> > > -global_quality 25 -look_ahead 1 out.mp4
> > >
> > > Signed-off-by: Zhong Li <zhong.li at intel.com>
> > > ---
> > > ICQ mode will fail with some cases:
> > https://github.com/Intel-Media-SDK/MediaSDK/issues/863. Don't merge
> > this patch before it resolved.
> > >
> > >  libavcodec/qsvenc.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h index
> > > 50cc426..055b4a6 100644
> > > --- a/libavcodec/qsvenc.h
> > > +++ b/libavcodec/qsvenc.h
> > > @@ -53,7 +53,7 @@
> > >  #define QSV_HAVE_MF     0
> > >  #else
> > >  #define QSV_HAVE_AVBR   0
> > > -#define QSV_HAVE_ICQ    0
> > > +#define QSV_HAVE_ICQ    QSV_VERSION_ATLEAST(1, 28)
> > >  #define QSV_HAVE_VCM    0
> > >  #define QSV_HAVE_QVBR   0
> > >  #define QSV_HAVE_MF     QSV_VERSION_ATLEAST(1, 25)
> > >
> >
> > LGTM once the issues with the driver are resolved.
> >
> > (I guess this is another case in favour of querying the actual
> > capabilities at runtime, though.)
> 
> Yup, API version is not library version, and ideally checking runtime version or
> check capabilities at runtime should be better than check API version.
> FFmpeg define a micro to check runtime version and here is an example:
> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc.c#L68
> 4
> 
> However, if one feature is implemented on different MSDK version on
> Windows and Linux, it is ugly to check different
> QSV_RUNTIME_VERSION_ATLEAST on different OS at runtime.
> Currently I am mainly checking API version at precompile stage.
> It is not perfect but higher efficient since currently MSDK API is a part of
> MSDK library and always keep some version release as I see.
> 
> And as you know, MSDK has no a powerful query interface like vaapi (Based
> on this, ffmpeg-vaapi can keep a better compatibility than ffmpeg-qsv as I
> see). MSDK query interface just tells you yes or not, and mixed with other
> parameters that cause even the answer (yes or no) is not precise. As the
> complaint on https://trac.ffmpeg.org/wiki/Hardware/QuickSync : “Using an
> invalid combination is likely to provoke the message: ‘Selected ratecontrol
> mode is not supported by the QSV runtime. Choose a different mode.’
> Usually this message is accurate, but it can also refer to other issues like the
> lack of a usable device.”
> I gave a patch https://patchwork.ffmpeg.org/patch/7785/ ）to make things
> better but still not perfect without a more powerful MSDK query interface.
> 
> A better way should be: define a better query interface which can expose a
> list of MSDK’s capacity just like vaapi, instead of just tell you yes or not.
> Then application can know the limitation accurately without mixed with
> other input parameters, and can switch to some supported path with a
> warning message instead of crashed.
> 
> Please be free to give comments.

Ping?

Currently the run-time checking is https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc.c#L365 , 
I verified this can tell you ICQ mode is not supported if libmfx library version is less than 1.28.
(I would like to have a discussion about the possibility to provide a more powerful query interface of libmfx just like vaapi's vaGetConfigAttributes or nvenc's vaGetConfigAttributes
But I guess we can't see that in short-time.)
And https://github.com/Intel-Media-SDK/MediaSDK/issues/863 has been fixed, so I prefer to merge this patch if nobody against.