On Sun, Nov 20, 2016 at 5:16 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > 2016-11-18 19:42 GMT+01:00 Hendrik Leppkes <h.lepp...@gmail.com>: >> On Fri, Nov 18, 2016 at 6:40 PM, Michael Niedermayer >> <mich...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
