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

[Jean-Baptiste Kempf]

On Wed, 20 Oct 2021, at 01:00, Soft Works wrote:
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>> Jean-Baptiste Kempf
>> Sent: Tuesday, October 19, 2021 11:19 PM
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH v6 00/10] make QSV works with the
>> Intel's oneVPL
>> 
>> Hello,
>> 
>> On Fri, 15 Oct 2021, at 22:23, Soft Works wrote:
>> > 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.
>> >
>> > [...]
>> > 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
>> 
>> Indeed.
>> But libmfx is not supported anymore by upstream, who's moving to
>> oneVPL, aka mfx 2.0.
>> 
>> You can think this is a bad move from Intel to remove feature, but,
>> de facto, they don't support libmfx anymore, the new features will
>> come only on oneVPL and the new hardware will only be supported in
>> oneVPL.
>
> That's not exactly true. There might no new features be added
> but it will still be supported because oneVPL doesn't replace it,
> at least not the runtime.

When an upstream library deprecates a feature, including when we do it for libav* , downstreams need to adapt. You can say that is bad and complain, but you adapt.

Intel says that oneVPL is mfx 2.0 and won’t support the old versions, so that is a fact.

And this patchset does not remove any feature, since you can still compile with mfx 1.3 and keep all the features. The person compiling makes the decision.

> That means that there's no pressing reason to use the oneVPL 
> dispatcher instead.

Yes, and so? The patchset does not remove any feature since you can still compile with mfx support.

> From my point of view, it's of very low interest to use a
> feature - no matter how great it might be - that is limited
> to a single CPU gen.

Again, then compile with mfx and without the onevpl switch. Everything will be the same.

> Factually there doesn't exist a single benefit or reason
> to adopt oneVPL at this time.

And while this true, this patchset gives the possibility to use oneVPL and does not remove mfx…

You don’t think Intel strategy is a good one?
Fair enough. But that is not what this patchset is about.

jb