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

Kostya kostya.shishkov
Wed Feb 16 19:45:19 CET 2011


On Wed, Feb 16, 2011 at 01:35:32PM -0500, Ronald S. Bultje wrote:
> 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.

hmm, indeed, whole Scantable thing may be a bit too much 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?

yes
 
> Ronald



More information about the ffmpeg-devel mailing list