

Google submits VP8 bitstream to IETF, but not as a standard - abraham
http://arstechnica.com/web/news/2011/01/google-submits-vp8-bitstream-to-ietf-but-not-as-a-standard.ars

======
eklitzke
So, is "standard" here being used to differentiate something approved by an
official standards body like ANSI/ISO vs. the IETF/RFC system? I can _kind of_
see how that would make sense, since RFCs are just memoranda published by the
IETF that happen to carry a lot of technical weight (v.s. the long, formal,
arduous, and bureaucratic standardization process bodies like the ISO are
known for). It's still weird to think though that by this definition TCP, IP,
etc. aren't really standards.

The other explanation that I can think of is that this is "not a standard"
since this is just a working draft, and not an approved/numbered RFC, but
clearly the draft here is the first step along that process.

~~~
robin_reala
Add to that all ‘Web Standards’ – the W3 aren’t an official standards body and
as such only make recommendations.

------
vu3rdd
I "heard" that the reason why this cannot be a standard is that the hardware
vendors are already making silicon out of the currently published bitstream
spec of VP8 and any discussion and a later change in the bitstream can upset
such plans. Hardware support is crucial for the success of any multimedia
format.

~~~
robin_reala
3 of the last 4 posts on the WebM blog ( <http://blog.webmproject.org/> ) have
been about upcoming hardware support. Sooner rather than later I’m sure.

Course, these seem to be mostly discrete parts. For real success WebM needs to
make it into SOCs.

------
alanh
I don't have a link on me, but I remember reading about big differences
between the spec and implementation.

~~~
othermaciej
The following blog posts from an x264 developer point out problems with the
spec, including discrepancies with the implementation and chunks of cut&pasted
C code:

<http://x264dev.multimedia.cx/archives/377>
<http://x264dev.multimedia.cx/archives/486>

Unfortunately, the VP8 Internet-Draft seems to be just a plaintext version of
the bitstream guide complained about above, including the disclaimer that the
implementation takes precedence and the snippets of C code. It would need a
lot of work to actually be published as any kind of standard, this perhaps
being a reason Google is going the individual submission RFC route.

~~~
ZeroGravitas
Interestingly the latest draft of the IETF's Opus codec spec actually contains
source code, zipped and then base64 encoded:

[http://www.ietf.org/mail-
archive/web/codec/current/msg02022....](http://www.ietf.org/mail-
archive/web/codec/current/msg02022.html)

