WebM

[rpg.314]

At this point I'm more worried about the state of the spec and the current sample implementations. While it's nice that it's free and everything, as a base to start doing some meaningful work for the greater good it appears (I haven't had a close look, I'm just going by the analysis linked above) to be a bit of a disaster.

I am curious about the situation with IMG and Intel. I have seen random stuff suggesting that IMG will be supporting VP8 but they are not on the list of partners.

Is anyone around here in a position to clarify?

Intel's absence, otoh, is a total shocker. Why would they sit it out? They don't have any patents in the h.264 pie.

 

[aaronspink]

How long before Google stops using x264 to make YouTube encodings in favour of this? I think Google's using x264.

Likely never. The vast majority of the market doesn't support anything but H.264 and likely never will. Quite honestly there really shouldn't even be a debate over H.264 at this point, its supported in basically every device out there that has been sold in the last 3-5 years and is already in wide use. Its highly unlikely to gain actual vendor support due to the poison pill in the license beyond simply reusing whatever exposed H.264 functionality it can utilize. ie, I'm not convinced that any of the "hardware" support google is trumpeting actually amounts to anything but "we currently expose this operation that could be used to accelerate the same operation with VP8".

 

[aaronspink]

I don't think those guys are into patent digging.

Most anyone doing any actual work is generally actively advised NOT to be into patent digging. The prevailing general legal theory is it is best that the first time you hear of a patent is when the lawsuit is filed. Stupid legal setup, but it is the way it is. I'd be surprised if google itself had done any sort of patent filter for the codec as it would significantly increase their exposure. If they had done an exhaustive search they would have offered indemnification.

 

[aaronspink]

Intel's absence, otoh, is a total shocker. Why would they sit it out? They don't have any patents in the h.264 pie.

Have you read the license? You would have to shoot your lawyers before you could use it if you have done or do anything video related. I highly doubt AMD/Nvidia are going to add actual support for the codec either, instead they will just say utilize already exposed functions if they accelerate the functionality. In comparison to some of the H.264 hardware decoders which can run to a large extent without software interaction for significant periods of decode, it is likely that VP8 hardware support will be minimal at best until at least the first lawsuits are settled.

 

[rpg.314]

Quite honestly there really shouldn't even be a debate over H.264 at this point, its supported in basically every device out there that has been sold in the last 3-5 years and is already in wide use.

True. To make noticeable impact, vp8 will need to be implemented into cameras in the first place.

Its highly unlikely to gain actual vendor support due to the poison pill in the license beyond simply reusing whatever exposed H.264 functionality it can utilize. ie, I'm not convinced that any of the "hardware" support google is trumpeting actually amounts to anything but "we currently expose this operation that could be used to accelerate the same operation with VP8".

Why would the poison pill affect hw vendors who want to sell decode/encode IP/chips?

 

[rpg.314]

I'd be surprised if google itself had done any sort of patent filter for the codec as it would significantly increase their exposure. If they had done an exhaustive search they would have offered indemnification.

MPEG LA must have done a pretty thorough examination. They don't offer indemnification either.

Besides, if Google hasn't looked into other patents then it is $125M spent on faith and good hopes.

 

[rpg.314]

Likely never.

That needn't be the case. Google's got a lot of servers and they support a ton of codecs for upload (3rd party info, haven't checked myself). They'll just transcode the stuff.

 

[aaronspink]

MPEG LA must have done a pretty thorough examination. They don't offer indemnification either.

No but it has both a large number of patents/companies already covered within the patent pool and has been on the market for many years in widespread use by many companies with deep pockets on a global scale. The probability at this point of there being a submarine patent for H.264 should be fairly low.

Besides, if Google hasn't looked into other patents then it is $125M spent on faith and good hopes.

You act like $133M is a lot of money. It isn't when it is done in stock. Its basically free for google. And it's chump change as well.

 

[aaronspink]

Why would the poison pill affect hw vendors who want to sell decode/encode IP/chips?

The same reason why patents would affect companies that want to do a software implementation. The M&A patents would likely cover any implementation of various parts hardware/software. So there is liability. In addition, if the situation should come up where they need to use a patent that covers some aspect of VP8 in a lawsuit, they would now have full exposure to both copyrights and patents related to VP8. So in effect, licensing VP8 would potentially expose them to MORE liability than they would have without it while providing little to no additional advantages (majority of video the devices will be playing will still be H.264 since all non-web will still be using H.264 and likely a significant portion of the web will be as well). They will support generic operations like they have for a long time but likely not the demux/decode/etc of the codec.

 

[aaronspink]

That needn't be the case. Google's got a lot of servers and they support a ton of codecs for upload (3rd party info, haven't checked myself). They'll just transcode the stuff.

If you are going to transcode, you would want to make your primary storage format the most efficient available. H.264 wins hands down here. AFAIK, google doesn't do transcode for streaming currently. They have a batch system setup that encodes the uploaded video to every format they support which is distributed and stored on their servers. Going to streaming transcode and storing in VP8 would significantly lower quality.

 

[rpg.314]

No but it has both a large number of patents/companies already covered within the patent pool and has been on the market for many years in widespread use by many companies with deep pockets on a global scale. The probability at this point of there being a submarine patent for H.264 should be fairly low.

So we need to wait for a few years before everyone will be convinced that only Google has patents. Fair enough.

You act like $133M is a lot of money. It isn't when it is done in stock. Its basically free for google. And it's chump change as well.

Hmmm... OK.

 

[rpg.314]

The same reason why patents would affect companies that want to do a software implementation. The M&A patents would likely cover any implementation of various parts hardware/software. So there is liability. In addition, if the situation should come up where they need to use a patent that covers some aspect of VP8 in a lawsuit, they would now have full exposure to both copyrights and patents related to VP8. So in effect, licensing VP8 would potentially expose them to MORE liability than they would have without it while providing little to no additional advantages (majority of video the devices will be playing will still be H.264 since all non-web will still be using H.264 and likely a significant portion of the web will be as well). They will support generic operations like they have for a long time but likely not the demux/decode/etc of the codec.

WRT Google's patents, why would Intel be on the hook if they don't sue Google or it's downstream customers?

WRT other's patents, how does the Google patent pill affect their liability arising from other's patents?

 

[rpg.314]

If you are going to transcode, you would want to make your primary storage format the most efficient available. H.264 wins hands down here.

VP8 should match h.264's baseline profile. Not sure which one yt uses.

 

[rpg.314]

Besides, Adobe will be rolling it out to a billion users, so it can't be too bad.

 

[BRiT]

Useful technical stuff: http://x264dev.multimedia.cx/?p=377

If justified, the comments there don't look very promising for VP8.

Indeed. That breakdown doesn't make it seem like VP8 is the best option. I wish they'd have gone into where/what patents the x264 uses or breaches.

Here's a quality comparison between the two:

 

[aaronspink]

VP8 should match h.264's baseline profile. Not sure which one yt uses.

Youtube uses high profile.

 

[nutball]

WRT Google's patents, why would Intel be on the hook if they don't sue Google or it's downstream customers?

WRT other's patents, how does the Google patent pill affect their liability arising from other's patents?

Well turn it around, what would Intel gain from revealing their hand right now? A far-from-compelling technical solution in a less-than-certain patent landscape. What does Intel have to gain from marching into that minefield?

Look at the list of people signed up from the webm site, there's a few interesting names missing. Apple. Microsoft. Nokia. Sony Ericsson. Samsung. HTC. If VP8 were unequivocally the future of the web, particularly the mobile web, why aren't those guys signed up?

 

[Simon F]

At this point I'm more worried about the state of the spec and the current sample implementations. While it's nice that it's free and everything, as a base to start doing some meaningful work for the greater good it appears (I haven't had a close look, I'm just going by the analysis linked above) to be a bit of a disaster.

I had a look at the spec yesterday and it did look a little, well, sparse. I did see that it used arithmetic encoding. I thought that was patented? <shrug>

 

[MfA]

The pioneering patents have all lapsed, Q coder variants are patented (H.264 uses one) but they don't use one.

 

[rpg.314]

Who else uses vp8? I mean is there anyone out there already using this codec?