[FFmpeg-devel] [PATCH] lavc/vc1dec: add multi-slice decoding support for hwaccel.

[Hendrik Leppkes]

On Tue, Nov 15, 2016 at 2:21 PM, James Almer <jamrial at 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.leppkes at gmail.com> wrote:
>>> On Tue, Nov 15, 2016 at 1:19 AM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>> 2016-11-14 23:47 GMT+01:00 James Almer <jamrial at 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