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

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, November 6, 2018 2:08 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/7] lavc/qsvenc: enable ICQ and
> ICQ_LA on Linux
> 
> 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#L684 

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.