More corrections and suggestions for the official VP8 documentation:
Stylistic matter: search for every occurrence of the phrase "of course" (there are 19) and strike entirely. Similarly, the phrase "taken up" should me replaced with something liked "described".
Overall, I'd like to see a solid bitstream reference. Its confusing to see a concise table of literals that will appear in the bitstream following by a paragraph describing more flags and literals that will appear. That paragraph should be in a tabular form.
7.3: Back on the matter of the bool decoder, it's debatable whether the spec should include copy & pasted C functions implemented. However, the copy & pasted functions don't match the reference decoder which has some small tweaks. For example, in the value maintenance code, range and value are shifted by a constant 1. In the reference decoder, the shifted value comes from a table.
9.4: MAX_REF_LF_DELTAS and MAX_MODE_LF_DELTAS are used but not defined anywhere in the spec (both are 4).
9.7: I don't understand this sentence: "Whether golden frame is refreshed ( 0 complete. This flag does not occur for no, 1 for yes)."
9.8: On the matter of refreshing the last frame buffer, this sentence left me confused: "VP8 uses one bit, L(1) , to indicate if the last frame reference buffer is refreshed using the constructed current frame. On key frame this bit is overridden, and the last frame buffer is always refreshed."
So, is it supposed to be present on keyframes? Present, but will always be set to 1? Present, but should be disregarded by the decoder? Reference decoder seems to indicate that the bit is missing on keyframes.
11.2: bmode_tree data structure is missing a comma after the number 16.
13.2: I'm having trouble with this sentence: "This makes use of the fact that in any block last non zero coefficient before the end of the block is not 0 , therefore no dct_eob follows a DCT_0 coefficient in any block."
Another stylistic matter: In describing how the intraframe prediction, here's a more visual approach I've used to describe the same thing:
> More corrections and suggestions for the official VP8 documentation:
> Stylistic matter: search for every occurrence of the phrase "of course"
> (there are 19) and strike entirely. Similarly, the phrase "taken up"
> should me replaced with something liked "described".
> Overall, I'd like to see a solid bitstream reference. Its confusing to
> see a concise table of literals that will appear in the bitstream
> following by a paragraph describing more flags and literals that will
> appear. That paragraph should be in a tabular form.
> 7.3: Back on the matter of the bool decoder, it's debatable whether the
> spec should include copy & pasted C functions implemented. However, the
> copy & pasted functions don't match the reference decoder which has some
> small tweaks. For example, in the value maintenance code, range and
> value are shifted by a constant 1. In the reference decoder, the shifted
> value comes from a table.
> 9.4: MAX_REF_LF_DELTAS and MAX_MODE_LF_DELTAS are used but not defined
> anywhere in the spec (both are 4).
> 9.7: I don't understand this sentence: "Whether golden frame is
> refreshed ( 0 complete. This flag does not occur for no, 1 for yes)."
> 9.8: On the matter of refreshing the last frame buffer, this sentence
> left me confused: "VP8 uses one bit, L(1) , to indicate if the last
> frame reference buffer is refreshed using the constructed
> current frame. On key frame this bit is overridden, and the last frame
> buffer is always refreshed."
> So, is it supposed to be present on keyframes? Present, but will always
> be set to 1? Present, but should be disregarded by the decoder?
> Reference decoder seems to indicate that the bit is missing on keyframes.
> 11.2: bmode_tree data structure is missing a comma after the number 16.
> 13.2: I'm having trouble with this sentence: "This makes use of the fact
> that in any block last non zero coefficient before the end of the block
> is not 0 , therefore no dct_eob follows a DCT_0 coefficient in any block."
> Another stylistic matter: In describing how the intraframe prediction,
> here's a more visual approach I've used to describe the same thing:
On Tue, Jun 1, 2010 at 9:33 AM, Paul Wilkins <paulwilk...@google.com> wrote: > Thanks Mike,
> I am trying to keep a record of comments and will get someone to do a > run through make a batch of changes in the near future.
I'm tracking these, too. We were talking today about starting a project in the git forest just for the bitstream spec -- which is pretty easy to do since it's sourced in text and already in a git repo. Just have to make sure it's clear how to work with the source, mostly because of the MathML, and partly because of the Markdown and PrinceXML transforms.
I think it is a good idea to have a text version that changes can be easily tracked and reviewed. We may use a review process similar to the one for source code patches to incorporate corrections and additions.
On Tue, Jun 1, 2010 at 4:49 PM, Lou Quillio <louquil...@google.com> wrote: > On Tue, Jun 1, 2010 at 9:33 AM, Paul Wilkins <paulwilk...@google.com> > wrote: > > Thanks Mike,
> > I am trying to keep a record of comments and will get someone to do a > > run through make a batch of changes in the near future.
> I'm tracking these, too. We were talking today about starting a > project in the git forest just for the bitstream spec -- which is > pretty easy to do since it's sourced in text and already in a git > repo. Just have to make sure it's clear how to work with the source, > mostly because of the MathML, and partly because of the Markdown and > PrinceXML transforms.
> I think it is a good idea to have a text version that changes can be easily
> tracked and reviewed. We may use a review process similar to the one for
> source code patches to incorporate corrections and additions.
> Yaowu
> On Tue, Jun 1, 2010 at 4:49 PM, Lou Quillio <louquil...@google.com> wrote:
> > On Tue, Jun 1, 2010 at 9:33 AM, Paul Wilkins <paulwilk...@google.com>
> > wrote:
> > > Thanks Mike,
> > > I am trying to keep a record of comments and will get someone to do a
> > > run through make a batch of changes in the near future.
> > I'm tracking these, too. We were talking today about starting a
> > project in the git forest just for the bitstream spec -- which is
> > pretty easy to do since it's sourced in text and already in a git
> > repo. Just have to make sure it's clear how to work with the source,
> > mostly because of the MathML, and partly because of the Markdown and
> > PrinceXML transforms.
On Tue, Jun 1, 2010 at 7:49 PM, Lou Quillio <louquil...@google.com> wrote: > We were talking today about starting a > project in the git forest just for the bitstream spec -- which is > pretty easy to do since it's sourced in text and already in a git > repo.
As stated in the README, this has been a practical-minded document heretofore, with a very small audience, and has had no ambitions of becoming a "specification." It may not necessarily have those ambitions now.
Nevertheless, the world turned a bit in the last month. All submissions welcome.
