> > 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...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel