GNOME Bugzilla – Bug 780881
gstreamer-vaapi against intel-vaapi-driver 1.8.0: Multiple regressions
Last modified: 2018-05-04 11:59:15 UTC
The new intel-vaapi-release-1.8.0 is bringing multiple regressions. This bug is to discuss what we can do from middleware perspective in order to not break the backward compatibility for gstreamer-vaapi customers. Here is the release mail of intel-vaapi-release: https://github.com/01org/intel-vaapi-driver/releases As mentioned in the release mail this driver release is not supporting (not failing gracefully to): The new AVC encoder doesn't support MVC/SVC encoding The new AVC encoder doesn't support ROI encoding The new AVC encoder doesn't support multiple slice encoding The new driver come up with lot of quality improvements for AVC encode in SKL/BXT and KBL platfrom by introducing new media kernels. But unfortunately is not backward compatible since it is not supporting the MVC encode and multi-slice-encode which we support in gstreamer-vaapi. We should provide some work-around or blacklisting specifically for this driver release.
(In reply to sreerenj from comment #0) > The new intel-vaapi-release-1.8.0 is bringing multiple regressions. This bug > is to discuss what we can do from middleware perspective in order to not > break the backward compatibility for gstreamer-vaapi customers. > > Here is the release mail of intel-vaapi-release: > https://github.com/01org/intel-vaapi-driver/releases > > As mentioned in the release mail this driver release is not supporting (not > failing gracefully to): > > The new AVC encoder doesn't support MVC/SVC encoding > The new AVC encoder doesn't support ROI encoding > The new AVC encoder doesn't support multiple slice encoding > > The new driver come up with lot of quality improvements for AVC encode in > SKL/BXT and KBL platfrom by introducing new media kernels. But unfortunately > is not backward compatible since it is not supporting the MVC encode and > multi-slice-encode which we support in gstreamer-vaapi. Are these features broken in all the Intel platforms or only in SKL&KBL??? > > We should provide some work-around or blacklisting specifically for this > driver release. In the case of ROI, I guess it is simple: the driver should report num_roi_regions as zero. For the other features, it seems difficult. I don't like the idea of identifying the intel-driver version and disable options in run-time. It will make the code more complex and hard to follow.
(In reply to Víctor Manuel Jáquez Leal from comment #1) > (In reply to sreerenj from comment #0) > > The new intel-vaapi-release-1.8.0 is bringing multiple regressions. This bug > > is to discuss what we can do from middleware perspective in order to not > > break the backward compatibility for gstreamer-vaapi customers. > > > > Here is the release mail of intel-vaapi-release: > > https://github.com/01org/intel-vaapi-driver/releases > > > > As mentioned in the release mail this driver release is not supporting (not > > failing gracefully to): > > > > The new AVC encoder doesn't support MVC/SVC encoding > > The new AVC encoder doesn't support ROI encoding > > The new AVC encoder doesn't support multiple slice encoding > > > > The new driver come up with lot of quality improvements for AVC encode in > > SKL/BXT and KBL platfrom by introducing new media kernels. But unfortunately > > is not backward compatible since it is not supporting the MVC encode and > > multi-slice-encode which we support in gstreamer-vaapi. > > Are these features broken in all the Intel platforms or only in SKL&KBL??? > Only in SKL/BXT and KBL > > > > We should provide some work-around or blacklisting specifically for this > > driver release. > > In the case of ROI, I guess it is simple: the driver should report > num_roi_regions as zero. ROI, anyway we haven't pushed the patches yet. But the driver seems to advertise the support in query even though there is no support :) For ROI, may be we can make a hard limit for the required VA version. Wait for a new intel-vaapi-driver release which fixes these issues, and put the required VA version dependency to the corresponding version. > > For the other features, it seems difficult. Yup, unfortunately QueryProfile advertise the supports but it fail if you try MVC encode :) For multi-slice, there is no Query existing . May be just disable(or hardcode) number of slices to 1 for all newer generations skl+ :) > > I don't like the idea of identifying the intel-driver version and disable > options in run-time. It will make the code more complex and hard to follow. I know, but we have to do something, right? The driver might release a quick 1.8.1 with at least support for failing gracefully, but still whoever using 1.8.0 in future is going to get the crash. Or may be we cam simply ignore those customers . Honestly I don't know. :)
I guess this is all solved with libva 2.0 tag if I understand correctly... isn't it?
It seems all the major distros has upgraded to libva 2.0, so there is no need to add a hack for this specific intel driver.