[FFmpeg-devel] [PATCH 1/2] Transpose IDCT 8x8 while reading.

[Ronald S. Bultje]

Hi,

On Wed, Feb 16, 2011 at 1:30 PM, Kostya <kostya.shishkov at gmail.com> wrote:
> On Wed, Feb 16, 2011 at 01:24:21PM -0500, Ronald S. Bultje wrote:
>> On Wed, Feb 16, 2011 at 1:20 PM, Kostya <kostya.shishkov at gmail.com> wrote:
>> > On Wed, Feb 16, 2011 at 05:55:28PM +0000, M?ns Rullg?rd wrote:
>> >> Kostya <kostya.shishkov at gmail.com> writes:
>> >> > On Wed, Feb 16, 2011 at 12:39:20PM -0500, Ronald S. Bultje wrote:
>> >> > [...]
>> >> >
>> >> > Why can't you use DSPContext as H.263-based decoders do?
>> >> > Seriously, there you can define permutation type, permute scantable according
>> >> > to it without this fixed permutation (which is likely to break Altivec stuff).
>> >>
>> >> Can we please not bloat DSPContext with more single-codec things?
>> >
>> > It's not bloating with, it's using existing functionality.
>> >
>> > I meant using this:
>> > ff_init_scantable(c->dsp.idct_permutation, &c->scantable, orig_scan);
>> >
>> > which relies on permutation type set in DSPContext (obviously).
>> >
>> > Otherwise it's easy to forget something using different scan order - Altivec
>> > in this case.
>>
>> I noticed this function, but it looked weird. I can try using it.
>
> Please do, otherwise use your account at M?ns' PPC machine to test Altivec as
> well (it should not be that hard to change it).

I'll change (should be as simple as removing the topmost
transpose8()). ff_init_scantables() does a lot more and is probably
not particularly useful here.

> And this #define transpose()/#undef transpose looks a bit ugly IMO.

How would you like me to do it instead? Just write out the code?

Ronald