On 18/11/16 14:18, 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.
Yes, the mesa driver was subverting the API to make it work before (and it may not even have been deliberate). Retested, patch LGTM: this is definitely a positive change even with that regression. I'll add looking at the mesa driver to my todo list, it should certainly be fixed there rather than in lavc. Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
