https://bugs.freedesktop.org/show_bug.cgi?id=108036
Bug ID: 108036 Summary: VA-API implementation reports support for unsupported endpoints Product: Mesa Version: 18.2 Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: notkurufu@cock.li QA Contact: dri-devel@lists.freedesktop.org
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
https://bugs.freedesktop.org/show_bug.cgi?id=108036
--- Comment #1 from Christian König ckoenig.leichtzumerken@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=108036
--- Comment #2 from Kurt Kartaltepe notkurufu@cock.li --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=108036
--- Comment #3 from Kurt Kartaltepe notkurufu@cock.li ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=108036
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED
--- Comment #4 from GitLab Migration User gitlab-migration@fdo.invalid --- -- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org