[FFmpeg-devel] [PATCH 2/2] dxva2_h264: add a workaround for old intel GPUs

[Hendrik Leppkes]

On Tue, Mar 4, 2014 at 7:45 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Tue, Mar 04, 2014 at 08:28:39AM +0100, Rainer Hochecker wrote:
>> +    else if (ctx->workaround & FF_DXVA2_WORKAROUND_INTEL_CLEARVIDEO)
>> +        pp->Reserved16Bits            = 0x34c;
>
> How is that related?

This is from the Intel paper that documents their "special" decoder
requirements.
Here: http://download-software.intel.com/sites/default/files/article/157713/h264-avc-x4500-acceration-esardell.pdf

This value and the different requirement for the ref frame index are
mentioned on page 17.

It may not be strictly required (anymore?), but when adding a special
work-around for Intel, might as well set the value that the Intel
whitepaper asks for.

>
>> @@ -238,7 +240,11 @@ static void fill_slice_long(AVCodecContext *avctx, DXVA_Slice_H264_Long *slice,
>>              if (list < h->list_count && i < h->ref_count[list]) {
>>                  const Picture *r = &h->ref_list[list][i];
>>                  unsigned plane;
>> -                unsigned index = get_refpic_index(pp, ff_dxva2_get_surface_index(ctx, r));
>> +                unsigned index;
>> +                if (ctx->workaround & FF_DXVA2_WORKAROUND_INTEL_CLEARVIDEO)
>> +                    index = ff_dxva2_get_surface_index(ctx, r);
>> +                else
>> +                    index = get_refpic_index(pp, ff_dxva2_get_surface_index(ctx, r));
>
> I'd say this looks nicer as
> unsigned index = ff_dxva2_get_surface_index(ctx, r);
> if (!(ctx->workaround & FF_DXVA2_WORKAROUND_INTEL_CLEARVIDEO)
>     index = get_refpic_index(pp, index);
>
> I also wonder if it wouldn't make more sense to merge into the previous
> patch (though that also depends on the answer to my question about the
> first part).
> Also, would it be possible to auto-detect whether this should be used or
> not?
> Lastly, which devices does this fix? Is everything but the "ClearVideo"
> ones broken currently, or is it only some special devices that even
> care about this?

The first patch fixes decoding on all modern Intel GPUs, specifically
all Ivy Bridge and Haswell GPUs, as well as Sandy Bridge GPUs - if the
application uses the standard Microsoft decoder device, and not the
Intel defined special decoder device. (Ivy and Haswell dropped support
for the special device, so they are always broken)
The second patch then adds the workaround back to be able to use the
old Intel special device again.

Auto-detection is problematic. You could query the GUID from the
decoder device and then change behaviour accordingly, but since the
decoder device can actually change mid-playback (ie. player moved from
one screen to another), and there is no way to let the HWAccel know
about this change easily, you would end up having to query it
periodically, in practice on every frame. It may not have a big
overhead, but it sure seems ugly. I preferred to let the application
set the workaround instead, since it of course knows when it re-inits
the decoder with a different GUID.

- Hendrik