> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Jean-Baptiste Kempf > Sent: Wednesday, October 20, 2021 8:01 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v6 00/10] make QSV works with the > Intel's oneVPL > > > > On Wed, 20 Oct 2021, at 01:00, Soft Works wrote: > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > >> Jean-Baptiste Kempf > >> Sent: Tuesday, October 19, 2021 11:19 PM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH v6 00/10] make QSV works with > the > >> Intel's oneVPL > >> > 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.
It's a marketing fact, not a technical fact, because not supporting the MSDK runtime anymore would mean to stop supporting all of their CPUs except the recent 2 or 3 generations. They also said that D3D9/DXVA2 would not be supported anymore which seems to have changed when I'm looking at the latest Windows oneVPL runtime dll. > And this patchset does not remove any feature, since you can still > compile with mfx 1.3 and keep all the features. Yes, but it adds a lot of clutter to the codebase. Based on the patch comments "..this is in preparation..", these changes would be reduced when waiting until these are available. > And while this true, this patchset gives the possibility to use > oneVPL and does not remove mfx… It just switches the dispatcher, but the runtimes being used are always the same (both dispatchers use the same two runtimes). > You don’t think Intel strategy is a good one? > Fair enough. But that is not what this patchset is about. While I don't like the strategy, it would be very stupid to oppose those changes for that reason. Without doubt, this change will need to be done at some point in time. I'm only saying that it's a bit too early. Anyway it's not my decision. I tried to clarify the situation for others to better understand and laid out my view. When the majority wants to merge this, I'll be good as well.. :-) Kind regards, softworkz _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
