VP8 Data Format and Decoding Guide
RFC 6386

[Ballot comment]
I'm surprised there are no security considerations in all that text.
Given that codec implementation flaws have been fairly common, it would
be good to give guidance on this, e.g. perhaps a small amount of
generic guidance (buffer overruns etc.) but also some detail if there
are specific things in this codec that implementers are likely to get
wrong.

[Ballot comment]
It is always a shame when a document shows up (even as an independendent publication request) and fails to pass idnits.

---

Thank you for the inclusion of the clear patent-related text in the document.

[Ballot comment]
Informational documentation is good, especially when it is accurate and complete. I am unable to judge the accuracy of this document (however, I did notice some small errors, such as "/*!\file decoder_impl.h" instead of "/*!\file vpx_codec_internal.h" in Section 20.19). As Wes Eddy noted regarding completeness, some files seem to be missing. Although I'm not quite sure which files are supposed to be included, according to my count the following files might be missing:

coef_update_probs.c
dboolhuff.c
dboolhuff.h
decodeframe.c (in one place called decodframe.c)
decodemv.c
dmode.c
filter_c.c
onyxd_if.c
quant_common.c
reconinter.c
reconintra.c
tree_reader.h
vpx_decoder_compat.h
yv12config.h

[Ballot comment]
The document seems to be incomplete.  I'm unsure where to find the yv12config.h referenced in section 2 or the vpx_config.h referenced later -- are these supposed to be included in the document, or do they live somewhere else that the reader is supposed to know how to find?  You should make sure this is as self-contained as possible, as references to files that may  not be available N years from now doesn't seem like a good idea.  Note, there may be other files like this missing; I only spot-checked a number of them as I was walking through it.  Otherwise, I thought this was nicely written.

The draft draft-bankoski-vp8-Bitstream-02
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

This draft was submitted in November 2010.
It was reviewed by Cullen Jennings, who has considerable
experience with video codecs.

Cullen made quite a few suggestions for improvements, which
the authors have made.

Much of the content describes the codec and how it works by
giving a commentary on short sections of its reference implementation
in C. The reference implementation is given as an appendix.
I've asked the authors to include their LICENSE, PATENTS and AUTHORS
files, they will publish a new version that includes these.

Also, I've prodded the authors to make an IETF IPR declaration
so as to make that quite clear - the authors assure me that it
will be sent in soon (if it hasn't been already).

I won't publish it until I see the IPR declaration on the IETF
site, and I have the version including the three files mentioned
above. However, I'd like to get its 587452 review under way now.


Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org