[FFmpeg-devel] [PATCH v6 00/10] make QSV works with the Intel's oneVPL

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Haihao Xiang
> Sent: Friday, October 15, 2021 3:39 PM
> To: ffmpeg-devel at ffmpeg.org
> Cc: Haihao Xiang <haihao.xiang at intel.com>
> Subject: [FFmpeg-devel] [PATCH v6 00/10] make QSV works with the
> Intel's oneVPL
> 
> The oneAPI Video Processing Library (oneVPL) is a single interface
> for
> encode, decode and video processing[1]. oneVPL is a successor to
> Intel(R) Media
> SDK, but removed obsolete features. Intel(R) Media SDK lifetime comes
> to an
> end now, new features for new Intel Gen platforms will be supported
> in oneVPL
> only[2].
> 
> It is recommended to use oneVPL for new work, even for currently
> available
> hardwares[3]. Hence, this patchset added a new option --enable-onevpl
> to bring
> the support for oneVPL in QSV. New features for oneVPL will be
> implemented in
> other patchset. --enble-libmfx option still works with Intel(R) Media
> SDK.
> 
> Note user can't enable onevpl and libmfx together.
> 
> oneVPL dispatcher source code:
> https://github.com/oneapi-src/oneVPL
> 
> oneVPL GPU runtime for new Intel Gen platforms:
> https://github.com/oneapi-src/oneVPL-intel-gpu
> 
> v6:
>   - Use ${libmfx_incdir} in configure
>   - Don't define mfx related function in an exported header
>   - Rebased this patchset against the latest master and fixed bugs
> 
> [1]
> https://spec.oneapi.io/versions/latest/elements/oneVPL/source/index.h
> tml
> [2] https://github.com/Intel-Media-SDK/MediaSDK/#media-sdk-support-
> matrix
> [3]
> https://software.intel.com/content/www/us/en/develop/articles/upgradi
> ng-from-msdk-to-onevpl.html
> 

Hi Haihao,

I really appreciate all the effort that Intel is taking to improve 
ffmppeg for QSV hw acceleration, but in this case I'm not convinced
that this should be merged into ffmpeg at this time.

Let's look at the messages from your individual commits:

> User plugin isn't supported for MFX_VERSION >= 2.0[1][2]. This is in
> preparation for oneVPL Support

> OPAQUE memory isn't supported for MFX_VERSION >= 2.0[1][2]. This is
> in preparation for oneVPL support

> Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This is in
> preparation for oneVPL support

> Multi-frame encode isn't supported for MFX_VERSION >= 2.0[1][2]. This
> is in preparation for oneVPL support

> MFX_RATECONTROL_LA_EXT isn't supported for MFX_VERSION >= 2.0[1][2].
> This is in preparation for oneVPL support

In its current state, oneVPL is all about removal of features that
have existed for a long time.

In its current state, it does not provide a single benefit over
libmfx 1.x

New CPU gens are still supported when using the latest libmfx 1.35

All-in-all, there is no single reason for anybody to compile 
ffmpeg with oneVPL instead of libmfx, but several reasons
against doing so.

When I look at your patchset that is in large parts dealing with
the removal of features that are "in preparation for oneVPL", 
I wonder why the ffmpeg code should go through all those 
changes, which are creating a lot of unnecessary noise.

While I don't like the way those recent changes are performed 
by Intel, I'm not opposed to oneVPL in general.
But from my point of view, this is not the right time to deal 
with it at the side of ffmpeg for the reasons above.

My suggestion is to postpone this until:

- the removed features are added to oneVPL
  and
- there exist some actual benefits in using oneVPL over libmfx 1.x

Kind regards,
softworkz