Hi,
Is there anything special I need to know about VP3's IDCT? I mean
besides the fact that there are separate IDCTs to handle sparse
coefficient matrices. Are the IDCT functions mathematically equivalent to
any textbook IDCT functions?
Thanks...
--
-Mike Melanson
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
I believe they are. At some point I replaced them with my own functions off the standard texts and I recall there wasn't any noticeable visual problem. However I can't remember if they were bit-for-bit accurate. With any DCT/IDCT implementation, the issue of any loss of precision etc. that might cause the encoder's reference decoding to drift from the decoder's has to be considered. I know we have run into problems like this when porting decode to different platforms. The only true document for now (until I get my spec together) is the code, so you will have to look at it or at least compare your output to the output of the present decoder. It's intended to be a pure 32-bit integer implementation if that helps. I do know (with my usual 99.44% assurance) that the two speedups (DC only & <=10 AC's) are supposed to be numerically identical to the full-on version. <p>> -----Original Message-----> From: Mike Melanson [mailto:melanson@pcisys.net] > Sent: Wednesday, March 05, 2003 11:10 AM > To: theora-dev@xiph.org > Subject: [theora-dev] VP3 IDCT > > > Hi, > Is there anything special I need to know about VP3's > IDCT? I mean > besides the fact that there are separate IDCTs to handle sparse > coefficient matrices. Are the IDCT functions mathematically > equivalent to > any textbook IDCT functions? > > Thanks... > -- > -Mike Melanson > > --- >8 ---- > List archives: http://www.xiph.org/archives/ > Ogg project homepage: http://www.xiph.org/ogg/ > To unsubscribe from this list, send a message to > 'theora-dev-request@xiph.org' > containing only the word 'unsubscribe' in the body. No > subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. >--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> From: Michael Niedermayer [mailto:michaelni@gmx.at]> btw, does theora/vp3 have a maximum allowed keyframe (or > co-located non-skiped > non-intra macroblock) limit like mpeg* ? IMHO it should have > one, otherwise > different decoders with different IDCTs will drift too much > like u mentioned >The DCT/IDCT in VP3 is 100% integer-based, so our philosophy is: you must duplicate it exactly. Drift is not allowed. Therefore maximum frames to a keyframe is unnecessary. There are reasons one might not want keyframes at all (except at the beginning of course). --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> From: Michael Niedermayer [mailto:michaelni@gmx.at]> btw, why does theora store the histograms, instead of just > the code lengths > 16bit *80*32 for the histogram -> 5120byte > 5bit*80*32 for the code lengthes -> 1699byte > and with some difference encoding for the code lengthes it > will be another > 2-3x smallerguilty as charged. This was quick work to get the concept of a global header with codec-specific data working. Assuming the histogram has no meaning to the decoder except to figure the code lengths (sounds right to me), I will consider changing this as suggested. Note the bitstream is NOT considered stable until Beta release. Encode at your own risk! -dbm --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> > The DCT/IDCT in VP3 is 100% integer-based, so our > philosophy is: you must > > duplicate it exactly. Drift is not allowed. Therefore maximum frames to a> that means that existing IDCT hardware cant be used :( > and neither existing software IDCTs :(perhaps -- it depends on the hardware. Most of my experience lately has been with firmware-programmable DSP engines that are more than flexible enough to deal with various definitions of DCT. I don't think you're likely to see Theora get hammered into a completely inflexible ASIC anytime soon, and if it is, it can be designed according to the spec for the same price as existing similar-complexity algorithms. Note that H.264 has a similar philosophy now with their 'DCT-like' integer transforms. Look, someone can go ahead and create a non-spec decoder that might look OK, but I think we should discourage it. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
ahh, I see. Unfortunately, I cannot recommend changing the spec to fit the
application. I feel pretty strongly about this, as does everyone who had to
deal with the problem in MPEG1, MPEG2, and (?) MPEG4. Going forward, I think
you'll find that the newer algorithms (Including upcoming MPEG-4 part 10 aka
JVT, H264, AVC) specify the forward and reverse transforms to bitwise accuracy.
Note that you might be able to get away with using ffmpeg's routines for
compression (FDCT), as long as you make sure that the reference decoder within
the compression engine (IDCT) is precisely equivalent to the spec. It's the
IDCT that causes drift (note there is no FDCT in the decoder, so it is
'non-normative', ie not really part of the spec in a formal sense) - dan
-----Original Message-----
From: Mike Melanson [mailto:melanson@pcisys.net]
Sent: Thu 3/6/2003 3:33 PM
To: theora-dev@xiph.org
Cc:
Subject: RE: [theora-dev] VP3 IDCT
On Thu, 6 Mar 2003, Dan Miller wrote:
> Look, someone can go ahead and create a non-spec decoder that might look
OK, but I think we should discourage it.
Right now, Michael and I are simply trying to establish how
easily
the VP3 algorithm can be adapted to fit into ffmpeg. The codebase, as
you
may know, already has a large body of code for inverting DCT very
quickly
with i386 SIMD sets, PPC AltiVec, Sun MediaLib, and even on Alpha and
PS2
(MIPS?) CPUs.
--
-Mike Melanson
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject
is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4934 bytes
Desc: winmail.dat
Url :
http://lists.xiph.org/pipermail/theora-dev/attachments/20030306/8f6e2d98/winmail-0001.bin