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: >> On Fri, Nov 18, 2016 at 3:11 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >> > Based on a patch by Jun Zhao <mypopy...@gmail.com> >> > --- >> > libavcodec/vc1dec.c | 41 +++++++++++++++++++++++++++++++++++++++-- >> > 1 file changed, 39 insertions(+), 2 deletions(-) >> > >> >> As a quick run down on the whole set: >> >> - This does fix decoding of frame-coded samples (ie. fate-vc1_sa10091 >> and fate-vc1_sa20021) on NVIDIA using DXVA2, no regressions using >> DXVA2 are known >> - 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. Lets just let them fix the implementation in mesa, Mark tells me its generally considered hacky and not very stable/reliable in the first place. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
