[FFmpeg-devel] A very basic DCT question

[Michael Niedermayer]

On Fri, Sep 19, 2008 at 12:38:37PM -0700, Baptiste Coudurier wrote:
> Hi,
> 
> Michael Niedermayer wrote:
> > 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? :)
> 
> Humm, and what if the scaled by 8 values do not fit in DCTELEM ? 

They do for 8bit input


> Would
> it be better to avoid the scaling ? Im thinking about > 8bits supporting
> codecs like h264, jpeg2k and dnxhd.

h264 does not use the normal 8x8 dct
jpeg2k is wavelets not dct and i do not know about dnxhd.
now i know there are codecs that use the dct and allow >8bits (normal jpeg
allows it in theory but i dont remember ever seeing such a jpeg)

but first we dont support any such >8bit stuff, and when (/if) we ever do,
they wont work with most of our 8bit dct implemetations anyway no matter
if their output is scaled by 8 or not.
Thats simply because our idcts and dcts have been designed to use the
available bits and if they had >8bit input they would overflow at many
points, not just at their output. (remember the mmx dct had a >>3 in there
which implicates that it had the coefficients multiplied by 8 internally
even before the output was "scaled" by 8)

So IMHO there is nothing to do here. When and if we ever support >8bit
then we need new (i)dcts that can handle it, these may in several cases
be compiled twice from the current (i)dcts with appropriately changed
coefficients.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/66aac81b/attachment.pgp>