We Will Have An Answer To Youtube On Pandora -- Webm.

[Caine]

Personally I've always thought this is the way it should be done.
I don't understand the rush to embed multiple decoders into every single application that needs to play video.
Every OS has a perfectly good multimedia backend (Directshow/Gstreamer/Quicktime?), just use that.

Yes true, but the point is not how the codec is supported, but that it is supported by default. If it is a user installed plugin, then effectively, the majority if windows users will not be able to play WebM video.

If either Microsoft forces the codec to be installed or Google provided Youtube via WebM only, then we will be fine.
If WebM turns out to be patent free, then the HTML 5 spec should force support for WebM.

The alternative is that IE and Safari users are only guaranteed to be able to play H264, Opera and Mozilla users WebM and Chrome users both.
This forces all video content to be provided in two encodings.

 

[openthebox]

Jobs: iPad or any future Apple products will not support any codecs developed by Retarded monkeys.

 

[grasshoppir]

lol Google should have checked this forum before buying VP8, such noobs

 

[Zeno Arrow]

VP8 doesn't need to be the best codec ever designed, it needs to be competitive on the web, which it already is (by the looks of it).

Should also point out that the open-source x264 has taken years to get to the stage of making h.264 as efficient to encode/decode as it currently stands, put the same amount of work into an open-source VP8 encoder/decoder and see where it stands then, that would be a fairer comparison.

In the meantime, support VP8/WebM as long as it stays open and free from patent issues, think long term, not short term. Of course MPEG-LA are going try and take aim at VP8 with any legal bullsh*t they can muster but gotta fight the power innit!!

 

[multiplex]

VP8 doesn't need to be the best codec ever designed, it needs to be competitive on the web, which it already is (by the looks of it).

Should also point out that the open-source x264 has taken years to get to the stage of making h.264 as efficient to encode/decode as it currently stands, put the same amount of work into an open-source VP8 encoder/decoder and see where it stands then, that would be a fairer comparison.

Well, the better it is, the more competitive it will be. Even though it will improve, it has a way to go, and the only valid excuse for starting out handicapped in that race is to work around patents.

 

[Zeno Arrow]

VP8 doesn't need to be the best codec ever designed, it needs to be competitive on the web, which it already is (by the looks of it).

Should also point out that the open-source x264 has taken years to get to the stage of making h.264 as efficient to encode/decode as it currently stands, put the same amount of work into an open-source VP8 encoder/decoder and see where it stands then, that would be a fairer comparison.

Well, the better it is, the more competitive it will be. Even though it will improve, it has a way to go, and the only valid excuse for starting out handicapped in that race is to work around patents.

From what I've read VP8 is better now than Theora, so from one perspective it's a step up. I don't see the point in supporting h.264, it offers little in the long run, better to support open standards now to give them a chance to mature.

 

[Wheels]

VP8 doesn't have to be better, or even as good, as h.264. Not today, not tomorrow. I'm just satisfied that it's apparently better than Theora (the only other Free alternative). This really ups the baseline of open video to more modern levels, possibly beyond what Theora is even theoretically capable of according to one of the Ogg devs.
Honestly, I would take some of the x264 dev's comments with a grain of salt. Yes, he's obviously an expert in codecs and encoder development, but x264 is his baby. And he doesn't really seem to have much substantial in the way of demonstrating patent infringement, arguably the most important aspect of this whole thing. I have no doubt that the spec and source code are a mess, and I have no doubt that the video quality is inferior to his top-of-the-line encoder's performance. But as long as the quality's good enough for Youtube while having better compression than Theora it's got legs as an open web standard for video. I could just be optimistic about the patent situation, though. I kind of wish software patents would disappear.

 

[multiplex]

From what I've read VP8 is better now than Theora, so from one perspective it's a step up. I don't see the point in supporting h.264, it offers little in the long run, better to support open standards now to give them a chance to mature.

Of course it's better than Theora. However it seems unlikely that VP8 will ever be as good as H.264 is, no matter how much you improve the encoder, due to the specification being similar enough to be comparable, while missing some important features, like B-frames (this is probably due to patent concerns.)

To be fair, that's compared to the full H.264 spec. It should be comparable to H.264 baseline spec, which like the rebuttal at http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html says is what low-end devices today can decode. But competing with full H.264, which PCs today already support, will require new and incompatible extensions to the format.

Worse, there are bugs that can't be fixed because Google froze the spec before they could be found. That it's the best we've currently got is no excuse if it could easily have been better.

Not to say I don't want it to be good, but if what you care about is compression quality H.264 is and will continue to be miles better.

 

[Tom`]

VP8 doesn't need to be the best codec ever designed, it needs to be competitive on the web, which it already is (by the looks of it).

Should also point out that the open-source x264 has taken years to get to the stage of making h.264 as efficient to encode/decode as it currently stands, put the same amount of work into an open-source VP8 encoder/decoder and see where it stands then, that would be a fairer comparison.

Well, the better it is, the more competitive it will be. Even though it will improve, it has a way to go, and the only valid excuse for starting out handicapped in that race is to work around patents.

From what I've read VP8 is better now than Theora, so from one perspective it's a step up. I don't see the point in supporting h.264, it offers little in the long run, better to support open standards now to give them a chance to mature.

Except as far as I'm aware, h.264 is an open standard too - it has a free implementation (x264), which is an excellent encoder. It is, of course, patented - but it's quite likely that VP8 could have patent issues too, and so it may not be widely adopted in places where software patents are enforceable.

 

[Zeno Arrow]

Of course it's better than Theora. However it seems unlikely that VP8 will ever be as good as H.264 is, no matter how much you improve the encoder, due to the specification being similar enough to be comparable, while missing some important features, like B-frames (this is probably due to patent concerns.)

To be fair, that's compared to the full H.264 spec. It should be comparable to H.264 baseline spec, which like the rebuttal at http://lists.wikimed...May/047795.html says is what low-end devices today can decode. But competing with full H.264, which PCs today already support, will require new and incompatible extensions to the format.

Worse, there are bugs that can't be fixed because Google froze the spec before they could be found. That it's the best we've currently got is no excuse if it could easily have been better.

Not to say I don't want it to be good, but if what you care about is compression quality H.264 is and will continue to be miles better.

If you actually followed the story properly you'd see that Google hasn't frozen the spec at all, they expect WebM to evolve as they know that's part of the open-source development model. Don't believe me? Take a look for yourself (Codec Research section):
http://www.webmproject.org/code/roadmap/

Except as far as I'm aware, h.264 is an open standard too - it has a free implementation (x264), which is an excellent encoder. It is, of course, patented - but it's quite likely that VP8 could have patent issues too, and so it may not be widely adopted in places where software patents are enforceable.

Can you not see the contradiction in what you just wrote? h.264 is not an open standard. Just because the spec is known doesn't make it open. x264 is an open-source h.264 encoder/decoder, still doesn't change the license the format is held under.

 

[Tom`]

Except as far as I'm aware, h.264 is an open standard too - it has a free implementation (x264), which is an excellent encoder. It is, of course, patented - but it's quite likely that VP8 could have patent issues too, and so it may not be widely adopted in places where software patents are enforceable.

Can you not see the contradiction in what you just wrote? h.264 is not an open standard precisely because it's patented. Just because the spec is known doesn't make it open. x264 is an open-source h.264 encoder/decoder, still doesn't change the license the format is held under.

I see it, but I refuse to acknowledge any moral foundation at all for software patents.

The problem is that there's an enormous number of useful techniques that are patented. The patent system (at least here in the US, probably in Germany too, and at least some other countries) encourages corporations to take out the largest possible number of patents, even on things that are obvious or have existing implementations, because it gives them legal ammunition later. (Companies that exist purely for this purpose are known as "patent trolls.")

There are so many software patents out there that without a legal staff to trawl through the vast number of patents in the system, no one really has a chance to create "open" standards (and even with a legal staff, there are still plenty of opportunities for litigation - as Microsoft found out to their cost in one fairly high-profile case this year (last year?)). The best most projects can do is ignore the patent system entirely, because at least then you can claim in good faith that you were unaware that any infringement occurred.

 

[multiplex]

If you actually followed the story properly you'd see that Google hasn't frozen the spec at all, they expect WebM to evolve as they know that's part of the open-source development model. Don't believe me? Take a look for yourself (Codec Research section):
http://www.webmproject.org/code/roadmap/

The VP8 bitstream is final. Future improvements for future incompatible formats are all nice and well, and I understand that compromises had to be made to avoid patent threats. That doesn't mean there aren't errors that should have been fixed but now won't be in the final, frozen spec.

 

[Zeno Arrow]

If you actually followed the story properly you'd see that Google hasn't frozen the spec at all, they expect WebM to evolve as they know that's part of the open-source development model. Don't believe me? Take a look for yourself (Codec Research section):
http://www.webmproject.org/code/roadmap/

The VP8 bitstream is final. Future improvements for future incompatible formats are all nice and well, and I understand that compromises had to be made to avoid patent threats. That doesn't mean there aren't errors that should have been fixed but now won't be in the final, frozen spec.

Of course they had to freeze the spec for now to get something out of the door that others could build upon, but you seem to be suffering from selective reading, as in the very next part of the FAQ the following is stated:

Are VP8 or WebM subject to change?

The VP8 and WebM specifications as released on May 19th, 2010 are final. We believe that the code and tools can evolve and improve for many years without requiring changes to the core specifications. We’ll maintain a separate branch of the code, however, for bold new ideas that could alter the specifications. If there are significant improvements to warrant a new revision we might adopt them, but only after careful consideration and after discussing suggested changes with the WebM community.

So not only will WebM version 1 evolve, Google have anticipated version 2, 3, etc... i.e. there's room for the specification to change.

 

[multiplex]

If you actually followed the story properly you'd see that Google hasn't frozen the spec at all, ...

Of course they had to freeze the spec for now to get something out of the door that others could build upon, ...

Listen, I'm not even disagreeing with you, I'm just pointing out what I believe are inconsistencies in your writing. I'm all for open codecs, and I'm hoping to have a look through the Dirac code base this summer, but you're speaking doublespeak.
Do I hope VP8 will turn out good enough to be a serious contender against more patent encumbered formats? Absolutely. Did Google freeze the current spec with some outright bugs that could have been avoided? It would seem so. It's unlikely to be a showstopper, or even have a large impact. It's just a bit off-putting to me, and I don't think people should delude themselves about the real situation.

 

[Zeno Arrow]

If you actually followed the story properly you'd see that Google hasn't frozen the spec at all, ...

Of course they had to freeze the spec for now to get something out of the door that others could build upon, ...

Listen, I'm not even disagreeing with you, I'm just pointing out what I believe are inconsistencies in your writing. I'm all for open codecs, and I'm hoping to have a look through the Dirac code base this summer, but you're speaking doublespeak.
Do I hope VP8 will turn out good enough to be a serious contender against more patent encumbered formats? Absolutely. Did Google freeze the current spec with some outright bugs that could have been avoided? It would seem so. It's unlikely to be a showstopper, or even have a large impact. It's just a bit off-putting to me, and I don't think people should delude themselves about the real situation.

I apologise if I came across harshly before.

It might seem like the quoted statements contradict each other, but not exactly. What I was trying to say was that the spec has been decided upon for now so that everyone can work to a common format, but it isn't frozen for all time, which is what I took issue with. If you accept that the format can evolve then I have no beef with you, even if you don't think it's perfect right now.

What outright bugs with WebM do you know of?

 

[multiplex]

I apologise if I'm coming across harshly before.

It might seem like the quoted statements contradict each other, but not exactly. What I was trying to say was that the spec has been decided upon for now so that everyone can work to a common format, but it isn't frozen for all time, which is what I took issue with. If you accept that the format can evolve then I have no beef with you, even if you don't think it's perfect right now.

What outright bugs with WebM do you know of?

Sorry, I don't know a lot about this, I'm mostly going by Dark Shikari's post and the project site and specs. What is known to me so far is that there is a clamping bug in the motion vector estimation, and that there are some unfortunate dependencies in the loop filtering, both of which Dark Shikari mentions in updates.
I've been looking for more details though, and came across https://groups.google.com/a/webmproject.org/group/codec-devel/browse_thread/thread/ff90bd82d0369b96. It looks like they're a lot cooler with fixing things up than I had gotten the impression of, as long as their hardware partners can deal. That's cool. Though I'm sure having that critique posted to every corner of the internet provides some extra incentive on getting those fixed as well.