[FFmpeg-devel] [PATCH 1/2] vc1dec: support multiple slices in frame coded images with hwaccel

[Hendrik Leppkes]

On Sun, Nov 20, 2016 at 5:16 PM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 2016-11-18 19:42 GMT+01:00 Hendrik Leppkes <h.leppkes at gmail.com>:
>> On Fri, Nov 18, 2016 at 6:40 PM, Michael Niedermayer
>> <michael at niedermayer.cc> wrote:
>>> On Fri, Nov 18, 2016 at 03:18:27PM +0100, Hendrik Leppkes wrote:
>
>>>> - This does fix decoding of these samples on Intel GPUs using VAAPI,
>>>> however it appears to break on AMD using VAAPI. Important to note here
>>>> however is that this change is matching up with the vaapi spec, and
>>>> the AMD implementation is more or less hacky.
>>>> - VDPAU seems to overall be unimpressed and keeps working as before.
>>>>
>>>> I hope I summarized the non-DXVA2 cases properly, as I didn't test
>>>> those personally, but relied on data from Mark Thompson.
>>>> Despite the breakage of AMD VAAPI decoding, this change appears to be
>>>> correct in the sense that it matches the VAAPI and DXVA2 specs on how
>>>> to handle slices and fixes decoding on two different GPUs, using those
>>>> two APIs.
>>>
>>> can the amd case be detected and the implementation adapted so
>>> everything works ?
>>
>> Not really.
>
> There is no API to read the version of the mesa driver?
>

Perhaps in some obscure way, but this is in generic code which doesn't
even know what kind of hwaccel is being used, nevermind access to the
internals of this hwaccel.
Trying to hack this in would be *extremely* ugly and breach a bunch of
the encapsulations we have to shield generic decoders from any hwaccel
implementation specifics.

Really, mesa should just fix their code to adhere to the vaapi
specification for slices
In reality, I have never seen a real-world video using these features,
otherwise I would have known about this lack of support in DXVA2,
which I did not. So its just not worth hacking around driver issues in
a very ugly way.

- Hendrik