On Tue, Nov 15, 2016 at 2:21 PM, James Almer <jamr...@gmail.com> wrote: > On 11/15/2016 9:07 AM, Hendrik Leppkes wrote: >> On Tue, Nov 15, 2016 at 1:39 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >>> On Tue, Nov 15, 2016 at 1:19 AM, Carl Eugen Hoyos <ceffm...@gmail.com> >>> wrote: >>>> 2016-11-14 23:47 GMT+01:00 James Almer <jamr...@gmail.com>: >>>> >>>>> but vc1_sa10143 fails using DXVA2 and a recent driver. >>>> >>>> I suspect it actually passes with DXVA2: FFmpeg is not >>>> bit-exact for vc1. >>> >>> Looks like you are right, thats the hashes I get as well. >>> >>> In any case, I have a working WIP patch that fixes sa10091 and sa20021 >>> with DXVA2, which were broken before. >>> I'll clean it up tomorrow and send it for testing. >>> >>> Unfortunately I don't have a sample for field mode with slices, so >>> that remains un-implemented. If someone comes across such a thing, >>> that would be nice to have. >>> >> >> Here is my current work in progress: >> https://github.com/Nevcairiel/FFmpeg/commits/vc1slices >> >> It fixes sa10091 and sa20021 on NVIDIA with DXVA2 for me. Note that >> sa10143 breakage is from the software decoder not being bitexact, and >> not a hwaccel failure (it doesn't even use slices). >> >> Appreciate any testing on other hardware or on VAAPI/VDPAU. >> >> - Hendrik > > On the same setup i mentioned yesterday, with your patch i get the same > results as without it. > All pass except sa10143 (Where i get the hashes Carl mentioned are the > actually bitexact ones) and vc1_ilaced_twomv, where i get the following > > -0, 0, 0, 1, 3110400, 0x764f8856 > -0, 2, 2, 1, 3110400, 0x3b615b79 > -0, 3, 3, 1, 3110400, 0x4fbb6f84 > -0, 4, 4, 1, 3110400, 0xc1ca8532 > -0, 5, 5, 1, 3110400, 0xb6e7d363 > -0, 6, 6, 1, 3110400, 0x1beb5c34 > -0, 7, 7, 1, 3110400, 0xcb8cb061 > -0, 8, 8, 1, 3110400, 0x13ddbd61 > -0, 9, 9, 1, 3110400, 0xde8f052f > -0, 10, 10, 1, 3110400, 0x4d4072db > -0, 11, 11, 1, 3110400, 0x4e5d29e3 > -0, 12, 12, 1, 3110400, 0x75300531 > -0, 13, 13, 1, 3110400, 0x1114285a > +0, 0, 0, 1, 3110400, 0xc95e8861 > +0, 2, 2, 1, 3110400, 0xf58b5cbf > +0, 3, 3, 1, 3110400, 0x2f866f33 > +0, 4, 4, 1, 3110400, 0x05c18415 > +0, 5, 5, 1, 3110400, 0x4077ca93 > +0, 6, 6, 1, 3110400, 0x44d105fc > +0, 7, 7, 1, 3110400, 0xa0608374 > +0, 8, 8, 1, 3110400, 0x407689dc > +0, 9, 9, 1, 3110400, 0x4707d00a > +0, 10, 10, 1, 3110400, 0x74986831 > +0, 11, 11, 1, 3110400, 0xa5912619 > +0, 12, 12, 1, 3110400, 0x44aa5565 > +0, 13, 13, 1, 3110400, 0xb9752774 > > Maybe this one is the same situation as with sa10143? >
Yes, that one also uses field coding, which is not bitexact in our decoder, so a mismatch is expected. Thanks for confirming I didn't break anything on other setups - or more precise fixed the breakage again from last night :) - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
