[FFmpeg-devel] [ping] [PATCH] mmx implementation of vc-1 inverse transformations

[Ronald S. Bultje]

Hi,

On Wed, Oct 6, 2010 at 11:41 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Oct 06, 2010 at 10:58:03AM -0400, Ronald S. Bultje wrote:
>> On Wed, Oct 6, 2010 at 10:32 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Wed, Oct 06, 2010 at 10:08:26AM -0400, Ronald S. Bultje wrote:
>> >> 2010/9/30 Yuriy Kaminskiy <yumkam at mail.ru>:
>> >> > Index: libavcodec/vc1dec.c
>> >> > @@ -2086,7 +2086,7 @@ static int vc1_decode_p_block(VC1Context
>> >> > ? ? ? ? ?for(j = 0; j < 2; j++) {
>> >> > ? ? ? ? ? ? ?last = subblkpat & (1 << (1 - j));
>> >> > ? ? ? ? ? ? ?i = 0;
>> >> > - ? ? ? ? ? ?off = j * 32;
>> >> > + ? ? ? ? ? ?off = s->dsp.vc1_inv_trans_8x4_transposed ? j * 4 : j * 32;
>> >> > ? ? ? ? ? ? ?while (!last) {
>> >> > ? ? ? ? ? ? ? ? ?vc1_decode_ac_coeff(v, &last, &skip, &value, v->codingset2);
>> >> > ? ? ? ? ? ? ? ? ?i += skip;
>> >>
>> >> I would prefer if we wouldn't add random fields in DSPContext, this
>> >> will quickly go crazy. Better check (like h264 does) whether the
>> >> function is the C function (which then needs to be exported in a
>> >> header) and do this behaviour based on that.
>> >
>> > no strong oppinion here but checking against the C function is a hack
>>
>> We need something so that we don't have to add random fields to
>> DSPContext, it's big enough as-is and should be generic-only.
>
> The problem is that the C function might not be the only one behaving like
> the C function

Right, so a bool as above in VC1DSPContext is fine with me. Just not
in DSPContext itself. (That requires the functions to be moved to
VC1DSPContext also, yes.) Let's clean this stuff up rather than
throwing more random bloat into it. ;-).

Ronald