Bug 108036

Summary: VA-API implementation reports support for unsupported endpoints
Product: Mesa Reporter: Kurt Kartaltepe <notkurufu>
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium    
Version: 18.2   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Kurt Kartaltepe 2018-09-24 03:05:09 UTC 
Videos encoded via VA-API on amd hardware using the h264 High profile end up corrupt. This appears to be a known flaw and unsupported by mesa drivers. My reference for this is here: https://bugs.freedesktop.org/show_bug.cgi?id=104920#c8

Notably the mesa team claims that the issue is with applications using an unsupported profile and that applications should query VA-API for supported features. However it can be see with `vainfo` on AMD hardware that h264 High profile support IS advertised by the drivers. So the error is not in the applications which correctly query the information. But in the drivers returning false information.

An example of vainfo output on AMD hardware advertising h264 High profile support. I also have a source video and resultant reencoding at high profile which is corrupt which is the same issue in the earlier bug where it was claimed it was not supported.
$ vainfo --display drm
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Mesa Gallium driver 18.1.6 for AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.26.0, 4.18.5-200.fc28.x86_64, LLVM 6.0.1)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
Comment 1 Christian König 2018-09-24 10:05:15 UTC 
The problem is neither the driver nor the application, but rather the design of VA-API.

The hardware supports some high profile features (like CABAC), but unfortunately not all of them (like B-frames or MBAFF).

Now the profile selects what the decoder needs to be able to do to handle a certain video, but doesn't tells you anything about the encoder except for selecting the encoding of the headers.

We should support the encoding of the headers, so if an application selects high profile it actually gets better compression because of CABAC support.

But if the application also tries to use B-frames it will get an invalid stream.

Additional to that we currently have a firmware problem which corrupts all streams != baseline. Could be that you are running into that one. Boyuang is already investigating it and you could try to downgrade your firmware version to test that.
Comment 2 Kurt Kartaltepe 2018-09-24 15:44:36 UTC 
The VA-API implementation correctly reports b-frames are unavailable and in this test they were not used.

The implemention also provided a decodable stream on main profile. So if the the firmware issue you describe affects main profile streams than this system is unaffected. And this is a separate issue.
Comment 3 Kurt Kartaltepe 2018-09-24 16:09:35 UTC 
> The hardware supports some high profile features (like CABAC), but
> unfortunately not all of them (like B-frames or MBAFF).
> 
> Now the profile selects what the decoder needs to be able to do to handle a
> certain video, but doesn't tells you anything about the encoder except for
> selecting the encoding of the headers.
> 
> We should support the encoding of the headers, so if an application selects
> high profile it actually gets better compression because of CABAC support.
> 
> But if the application also tries to use B-frames it will get an invalid
> stream.

Yes, the issue is that valid settings produce a stream that is invalid. Personally I would be more than ok if the resultant stream on high was within constrained baseline specs as long as it returned a valid stream.

 Because hardware encoders are such black boxes I care very little for the settings i cannot control (such as exact compression techniques) and expect the ones i can to work.
Comment 4 GitLab Migration User 2019-09-25 18:09:50 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1329.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.