Dan, In reviewing the code, derf came across the DCSearchPoints array in QuadCodeDisplayFragments(), encode.c:696. It looks like it specifies a search order for nearby coded fragments for prediction if there isn't a nearest neighbor. However, the upper search bound is defined as *0*, so the search loop (line 917) is never executed and it always falls back to the last coded fragment. This table and supporting code is duplicated on the decode side in dct_decode.c around lines 1022 and 1191. Derf thought this code was similarly bypassed in VP3 as well. I enabled it and tested a couple of files, but it didn't make an appreciable difference in efficiency. Therefore it seems reasonable to just take it out as dead code. I wanted to ask what you knew about it first, and make sure we're not breaking lossless VP3 transcode. -r --- >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.
On Sat, 14 Jun 2003, Ralph Giles wrote:> Dan, > > In reviewing the code, derf came across the DCSearchPoints array in > QuadCodeDisplayFragments(), encode.c:696. It looks like it specifies a > search order for nearby coded fragments for prediction if there isn't a > nearest neighbor. However, the upper search bound is defined as *0*, so > the search loop (line 917) is never executed and it always falls back > to the last coded fragment. > > This table and supporting code is duplicated on the decode side in > dct_decode.c around lines 1022 and 1191. > > Derf thought this code was similarly bypassed in VP3 as well. I enabled > it and tested a couple of files, but it didn't make an appreciable > difference in efficiency. Therefore it seems reasonable to just take it > out as dead code. I wanted to ask what you knew about it first, and > make sure we're not breaking lossless VP3 transcode.I can confirm that the search point coding stuff is not used in VP3. I brought this up in February: http://www.xiph.org/archives/theora-dev/200302/0026.html -- -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.
hi Mike -- I'll take your word for it. You've gone deeper into the code than I have at this point. If you're up for helping with the spec, I certainly could use some. Speaking of dead code, there's junk in huffman.c that can be removed -- I posted about this before. ___ Dan Miller (++,) Founder, On2 Technologies <p>> -----Original Message-----> From: Mike Melanson [mailto:melanson@pcisys.net] > Sent: Saturday, June 14, 2003 11:47 AM > To: theora-dev@xiph.org > Subject: Re: [theora-dev] dead DCSearchPoints code > > > On Sat, 14 Jun 2003, Timothy B. Terriberry wrote: > > > > I can confirm that the search point coding stuff is not used in > > > VP3. I brought this up in February: > > > http://www.xiph.org/archives/theora-dev/200302/0026.html > > > > I don't know about you, but I got a > > > > > I haven't looked at this part of the code yet. I'll let > you know when > > > I do. > > > > out of that thread. If you have been decoding pre-existing VP3 files > > without that search loop, however, then that would help confirm that > > eliminating it does not introduce bitstream incompatibility. > > True, that was the official word from Dan on DC search > points. But > I can confirm that in the reference VP3 decoder, anything > dealing with DC > search points is completely ignored. If a VP3 encoder tried to encode > using the search points, the decoder would not decode the information > correctly. > > -- > -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.
Please go ahead & post it. It's very well written and reasonably comprehensive as far as you went (which as I've said is farther than I have gotten yet). At this point, VP3 is still almost identical to Theora. The main change has been putting the table data into the stream header. If it's OK with you, I would like to incorporate parts of your document (credited, of course) into the Theora specification I'm working on. My spec has sort of morphed into this project to recode the decoder in Python, which is great I guess but not exactly what people are expecting. Your document has the kinds of plain english descriptions I suspect people will really want to see. Perhaps in collaboration, we can get the best of both worlds. Great work! - dan ___ Dan Miller (++,) Founder, On2 Technologies <p>> -----Original Message-----> From: Mike Melanson [mailto:melanson@pcisys.net] > Sent: Tuesday, June 17, 2003 6:56 AM > To: theora-dev@xiph.org > Subject: Re: [theora-dev] dead DCSearchPoints code > > > On Tue, 17 Jun 2003, Ralph Giles wrote: > > > On Saturday, June 14, 2003, at 07:57 pm, Mike Melanson wrote: > > > > > I'm up to it-- I have quite a bit of it written already. Do you > > > think I should post my present document on my codec site > for comment, > > > but > > > mark many of the sections as unfinished? It would > certainly beat my > > > vp3-notes.txt file. > > > > That would be really great, I'd love to see what you have so far. > > If Dan has no objections, I will post what I have tonight (he > asked to see it before I posted). > > > You could also try installing in the wiki > (wiki.xiph.org/TheoraSpec) > > That way we'll have a safer copy (backed up by revision > control) and > > everyone can work on it together. > > Hmm, don't understand Wiki and not motivated to learn it right > now. Besides, the document strictly covers VP3. When I have > that correct, > I will [figure out and] document the Theora changes. > > -- > -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.
Mike -- It would be much cleaner if you could release the text under the BSD-style Xiph license that Theora is released with. Having the spec include a GNU license could be confusing, potentially giving the impression that Theora itself is bound by GNU, which it's not. GNU is considerably more restrictive than our license - dan <p>> From: Mike Melanson [mailto:melanson@pcisys.net]> On Tue, 17 Jun 2003, Dan Miller wrote: > > > If it's OK with you, I would like to incorporate parts of > your document (credited, of course) into the Theora > specification...> I suspect it will be okay to incorporate stuff from my document. > All of my codec documents use the GNU Free Documentation License. More > information is here: > > http://www.gnu.org/licenses/fdl.html > > I mostly did this because I just wanted *some* kind of > copyright notice on > my documents. > > -- > -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: Mike Melanson [mailto:melanson@pcisys.net]...> BTW, do you have anything to state about that discrepancy/bug I > found awhile back related to macroblock decoding? I plan to > write it up as > a bug in the original implementation. >Just today, I finally got through the joy that is superblocking. I am now onto the even greater joy of DC prediction (yuk!), with excellent help from your document (note a slight mistake -- left column (group 1) can only use U & UR predictors, not UL) BTW I think I will scrap the group numbering as it's really an implementation detail, and rather confusing. Once you get through the smoke, it's actually not *too* complex. The implementation details make it seem worse than it is (I think -- haven't really got it working yet). 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. 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... Thanks much for the contribution! Sure you don't wanna do IRC? Great timewaster, but we sometimes actually talk about this stuff ;*} ___ Dan Miller (++,) Founder, On2 Technologies --- >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: Mike Melanson [mailto:melanson@pcisys.net] > > > BTW I think I will scrap the group numbering...> True, it could probably be described without the group > numbering. > 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... -dan> > 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: > http://www.xiph.org/archives/theora-dev/200305/0002.html > 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@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.