[FFmpeg-devel] A very basic DCT question

Michael Niedermayer michaelni
Fri Sep 19 21:18:03 CEST 2008

On Fri, Sep 19, 2008 at 11:46:41AM -0700, Roman Shaposhnik wrote:
> On Fri, 2008-09-19 at 18:56 +0200, Michael Niedermayer wrote:
> > On Fri, Sep 19, 2008 at 09:01:34AM -0700, Roman Shaposhnik wrote:
> > > Guys,
> > > 
> > > I'm going to ask the most basic (perhaps even stupid) question
> > > of all -- is there a way to hook DCT routines that do NOT
> > > scale their output by a factor of 8x to dsputil properly?
> > 
> > yes, but why? 
> well, my loud mouth got me into trouble again ;-) Remember the
> discussion around MediaLib? this exercise is part of trying
> to see how good of fit it can be for open source and I'm
> trying to gather the data first (it actually distracts me
> a bit from the DV stuff I promised to deliver, so I hope
> to get it done ASAP).
> > most likely its a matter of adjusting some constants
> > in the dct to make it return differently scaled output, this seems
> > to make more sense ..
> constants where? Suppose you have DCT_foo (which is closed
> sourced and part of the vendor library) that follows an
> exact definition of what DCT is supposed to do with its
> input. It gives you the output that, as far as FFmpeg
> is concerned, appears to be scaled by a factor of 1/8x.
> So the question is: can its output be consumed as 
> is by the rest of FFmpeg's machinery?
> Just to be clear -- I'm not proposing any kind of extensions
> or anything like that. If the answer is "no, you have to
> scale it back by a factor of 8x" -- that's fine too.
> For now, I have three libraries like that: IPP, medialib,
> and the one from AMD.

Why dont you write a dct that is better and faster and outputs things
scaled correctly the way lavc expects? :)

Anyway to awnser your question, our AAN dct needs its output scaled
by a matrix, thus if that matrix is "replaced" by one with appropriate
values (like all 8) and the surrounding dct checks are fixed up it
should work.
If you grep for "aanscales" that will give you a pretty accurate list
of what would need changing.

Also if the mlib dct is as accurrate as their idct, iam really not sure
if the time would not be better spend writting a better sparc dct ...

> > > I haven't touched that part of FFmpeg for at least 5 years,
> > > but last time I did, I had an impression that it was
> > > possible to tell  DSPContext what scale factor was there.
> > > 
> > 
> > > And since we are on this subject: can someone, please,
> > > provide a sufficient background for me to understand
> > > where did this 8x scale factor come from to begin with?
> > > Most of the DCT implementations I see around don't
> > > have anything like that.
> > 
> > higher precission. Throwing 3 bits away because most others do it
> > did not seem like a good idea. Its not as if these would need any
> > extra instructions, actually they needed less for at least one dct.
> Understood. But why 3bits? Is it just an artifact of a particular
> implementation or a more general property of a doing DCT faster/easier?

What i remember is that (IIRC) our MMX dct had these >>3 instructions
before the output and i removed them ...
I do not know in how far these were a artifact of our particular
implementation or if most SIMD dcts would end up with similar shifts

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080919/bd4b62de/attachment.pgp>

More information about the ffmpeg-devel mailing list