5 ms·

I do not care about WebM or H.264 since I dislike both, my comment will concern the license and the situation. WebM have a Apache style license, you can grab t

by zppx 16y ago

I do not care about WebM or H.264 since I dislike both, my comment will concern the license and the situation. WebM have a Apache style license, you can grab the source, fork it and develop your codec, and you're not even obligated to open a repository including your changes, they can remain closed. Google will not stop you from doing so and guarantees that he will not sue you asking for royalties, since a license like the Apache license gives the use of the patent for free. The case of Android and Chrome is simple, Google employes the majority of developers in both projects, however Google does not employes the majority of Linux kernel developers an as a result much of the Android code isn't in the kernel.org code. Similarly the directions of Webkit is decided by the two main committers: Google and Apple.

recoiledsnake 16y ago
I am talking about practicality or the chances of it happening. Anyone can do what they want, but if it's incompatible with the 800lb gorilla's offering, it's basically a moot point.
Locke1689 16y ago
Actually, recoiledsnake's scenario has already happened. The VP8 "spec" isn't a spec at all, it's just copy pasted C code. Unfortunately, they also chose to reuse the same code for the encoder and the decoder. This means bugs in either one can propagate into both. There was already one of these bugs found, fixed, and had a patch applied to the source tree. Google came in and reverted that patch because too much video had already been encoded with the bug in the encoder. This is exactly what happened with IE6, where bugs in the product become de facto requirements on the web. Maybe the H264 spec drones on and on but at least it's a spec. The VP8 "spec" is just a mandate from Google. A shitty one, at that. I'll take the small risk of patent litigation among only the biggest players for an open specification and standard any day. Of course, there's also the fact that H264 is way better than VP8 which it seems like no one cares about.
- true_religion 16y ago
  It was a 'bug fix' that caused a major regression. What would you have them do?
  - Locke1689 16y ago
    Write a spec, not a "bitstream guide," so that this problem doesn't happen in the first place? Or at least admit that your spec is not finalized and is, in reality, a piece of crap that needs wide peer review first.

by zppx 16y ago

recoiledsnake 16y ago

I am talking about practicality or the chances of it happening. Anyone can do what they want, but if it's incompatible with the 800lb gorilla's offering, it's basically a moot point.

Locke1689 16y ago

Actually, recoiledsnake's scenario has already happened. The VP8 "spec" isn't a spec at all, it's just copy pasted C code. Unfortunately, they also chose to reuse the same code for the encoder and the decoder. This means bugs in either one can propagate into both. There was already one of these bugs found, fixed, and had a patch applied to the source tree. Google came in and reverted that patch because too much video had already been encoded with the bug in the encoder. This is exactly what happened with IE6, where bugs in the product become de facto requirements on the web. Maybe the H264 spec drones on and on but at least it's a spec. The VP8 "spec" is just a mandate from Google. A shitty one, at that. I'll take the small risk of patent litigation among only the biggest players for an open specification and standard any day. Of course, there's also the fact that H264 is way better than VP8 which it seems like no one cares about.

true_religion 16y ago
It was a 'bug fix' that caused a major regression. What would you have them do?
- Locke1689 16y ago
  Write a spec, not a "bitstream guide," so that this problem doesn't happen in the first place? Or at least admit that your spec is not finalized and is, in reality, a piece of crap that needs wide peer review first.