[FFmpeg-devel] [PATCH 1/2] Transpose IDCT 8x8 while reading.
Ronald S. Bultje
Wed Feb 16 19:35:32 CET 2011
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?
More information about the ffmpeg-devel