[theora-dev] dead DCSearchPoints code
dan at on2.com
Wed Jun 18 12:21:42 PDT 2003
> From: Mike Melanson [mailto:melanson at pcisys.net]
> > BTW I think I will scrap the group numbering
> True, it could probably be described without the group
> However, it will be critical to carefully explain how to make the DC
> prediction bit-exact (think about the HIGHBITDUPPED() macro).
> I know from
> experience how quickly the data will be messed up if the process isn't
> followed precisely as in the original code.
Absolutely. That's why I'm doing the Python thing -- whether anyone looks at it or not, it's the only way I can assure myself I really understand what's going on and have described it correctly.
The HIGHBITDUPPED thing looks like a hack to use shift instead of divide -- basically if the value is negative, you add
2^shift-1 before shifting. This forces the shift to round towards zero, rather than always rounding down (which would increase the absolute value of a negative number). For example, without the correction 7>>1 = 3, and -7>>1 = -4. But if we add 1 to -7 we get -6, and -6>>1 = -3.
I'll get to the part of the code with the bug eventually. I'm recalling a bit more -- this programmer said that for some reason they decided late in the game to tie chroma motion vectors to Y vectors -- is it possible that while the decoder has logic to unpack these unused bits, the encoder never generates them? The explanation would be that for a while they had old bitstreams lying around they didn't want to break...
I can always try to get some help from On2, but they're on to VP6 and tend not to remember what was going on 4 years ago. And of course they're always on deadline and basically have no allowance to give me any time on VP3 anymore.
I still have faith everything will make sense eventually...
> > Also, sanity check -- DCSearchPointCount is always zero, so
> the code that looks through the DC search points never gets
> called, right? It falls through to Last[WhichFrame], ie last
> block coded, or zero if no blocks coded...? Nice if true,
> less craziness to document.
> From my analysis, DCSearchPoints is mooted in the VP3 source.
> > As for that possible bug, I have a vague memory of one of
> the original VP3 programmers explaining something once about
> how the color modes are tied to the Y modes, so I suspect
> it's not really a bug... but this could be a bad dream...
> in any case, if it were a bug, I think things would be way
> screwed up & we would have noticed. More likely it's just
> another of the cruelly subtle coding that makes VP3 analysis
> such a challenging hobby...
> For anyone following along, here is the original message:
> I still contend that it does not make sense. While C-plane macroblock
> coding data is unpacked, this information is never used in
> the decoding
> process. The Y-plane macroblock data is applied to the C-planes. Thus,
> while the information is present in the bitstream (using
> precious bits),
> it does not affect the decoding process.
> > Thanks much for the contribution! Sure you don't wanna do
> IRC? Great timewaster, but we sometimes actually talk about
> this stuff ;*}
> Generous offer, but no thanks. I'm much too busy with
> the general
> multimedia hacking. Besides, as with Wiki, I don't know how
> IRC works and
> I'm too unmotivated to learn...:)
> -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 at 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 at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Theora-dev