Microsoft offers H.264 plug-in for Chrome, queries Google on WebM

After creating one for Firefox, Microsoft has announced that it has released a …

Dean Hachamovitch, corporate vice president for Internet Explorer, today announced the launch of a plug-in for Google's Chrome Web browser that reinstates support for the H.264 video codec when used with HTML5's <video> tag. The plug-in will enable Chrome users on Windows 7 to view H.264 video, even though Google announced the decision to remove native support for the codec last month.

The reason Microsoft gives for creating these plug-ins is that since the underlying operating system includes native support for the codec in question, users should be empowered to view videos that use the codec—and that's regardless of their browser preference. The intent is to be pragmatic: most users are indifferent to the ideological or other reasons that surround video codecs and software patents; they just want to watch some video. If the operating system can ensure that the browser vendor's choices don't stand in the way of watching that video, Microsoft believes the operating system should fill the gap: the Firefox and Chrome plug-ins are the company's way of doing just that.

The company is also working to ensure that WebM HTML video will play back in Internet Explorer. Google is developing plug-ins of its own to provide WebM support to Windows and Internet Explorer 9, and Microsoft has worked with Google to help ensure the plug-ins work properly.

Serious concerns

What Microsoft isn't doing is developing or bundling a WebM plug-in itself. While announcing the plug-in, the company also outlined a number of questions and concerns it has regarding WebM: who bears the liability for any intellectual property risk associated with the codec, how will Google allow genuinely open engagement, and what the plan is to achieve the kind of consistent, widespread support that H.264 offers.

The first of these concerns is perhaps the most substantial: though Google insists that WebM is "open"—the company says that it owns all the necessary patents that cover the VP8 video codec, and that these patents are available on a royalty-free basis—assertions of "openness" count for little if a company makes a claim of patent infringement. Google offers no indemnification for costs incurred in such a lawsuit, meaning that anyone using, implementing, or distributing VP8 could be at risk (this is in contrast to Microsoft, which does offer users of its products indemnification against patent lawsuits).

WebM's supporters often point out that there have been no WebM lawsuits yet, as if this meant the codec was free of risk. Such claims ignore the practical realities of patent lawsuits. The JPEG image compression format was standardized in 1992. It was not until a decade later that a company first claimed that the format infringed on patented technology: between 2002 and 2005, when its patent was eventually invalidated, Forgent Networks sued more than 30 companies for patent infringement, and received more than $100 million for licensing the patent to another 30 companies. A second round of lawsuits was initiated in 2007 by Global Patent Holdings; its patent too was invalidated, in 2008.

Though the patents driving these lawsuits were both ultimately deemed to be invalid due to existing prior art, they were costly and time-consuming to defend against. And, importantly, they took a long time to emerge. That nobody has sued Google yet does not mean that VP8 does not infringe any patents; it simply means that nobody has sued Google yet. Nor, if the history of JPEG and GIF is anything to go by, are they likely to sue Google any time soon. History shows that the preferred technique is to wait until a technology is in wide use, and then sue many people for infringement, whether they are developers, distributors, or end-users. We wouldn't expect to see a lawsuit at this early stage; it would scare people off the format altogether, thereby reducing the likelihood of lucrative licensing deals and/or settlements.

Microsoft says that until the situation around intellectual property and liability is clear then it will remain agnostic towards the choice of codec. Internet Explorer 9 supports H.264 because Windows supports H.264; it will similarly support WebM with a suitable Windows plug-in. H.264 does open up the company to some risk, but it believes that this is a necessary risk (given the importance of H.264 support for things like TV and optical disc playback) and a small risk (given that many of the companies with relevant intellectual property have disclosed their patents already).

The company's own history in this area—many patent holders emerged from the woodwork when SMPTE worked to standardize WMV as VC-1—has led it to be cautious when it comes to WebM, but Microsoft recognizes that there is value in a codec that is well-protected against legal issues: H.264 appears to be that codec at the moment, but WebM could achieve that status with some help from Google.

The implication in the post is that if Google were to, say, indemnify developers and users of WebM, then Microsoft would be willing to take advantage of that indemnification by developing and/or distributing WebM support itself. Such a move would certainly enhance WebM's reach, but the ball is in Google's court.

The other concerns appear less important: it seems that Microsoft would prefer for WebM to be governed by a genuine standards body (rather than merely submitting a nonauthoritative document to IETF), and would like a better plan for how to give WebM the kind of ubiquity that H.264 enjoys. These are reasonable concerns, and certainly areas of improvement for Google, but are secondary to the patent liability question: only patent liability has the potential to inflict enormous costs on anyone using WebM. As long as Google fails to address them seriously, browser plug-ins and competition from H.264 are likely to remain a feature of HTML5 video.

223 Reader Comments

None of what you've said has any bearing on whether Linux distros distribute the x264 codec: they do, I've given two examples. Redefining "distribute" to mean "only on the LiveCD", and back-track on your false statement doesn't change that.

Bitstream decoding can also be done through dxva. You probably got confused reading some press releases about the addition of bitstream support with lack of the words dxva in it.

Of course it's pretty fucking dishonest to not count HW which doesn't support something which is more of a nice to have instead of critical to performance in the first place.

WTF are you talking about? DXVA was first introduced as a standardized API with Windows 2000.

The first version of the H.264/MPEG-4 or AVC (Advanced Video Coding) standard was completed in May 2003. DXVA does not implement H.264 AVC decoding.

DXVA is not fixed in functionality like you think it is. Seriously, you know fuckall about anything and are completely unwilling to find anything out.

Quote:

tzt wrote:

because you didn't understand what you're repeating from elsewhere: "and one of the conditions of implementation of H.264 AVC is that non-profit entities, such as Linux distributions or Mozilla, are not allowed to implement it."

OK, I see the problem with my pharsing. I didn't actually mean that non-porfit entities are not allowed to implement it, I meant that Linux distributions or Mozilla, who are non-profit entities, are not allowed to implement it. I grant you that my wording was awry, and gave the wrong impression of compared to what I meant to say, so for that I apologise.

I'm not sure what what one has to do with the other. At all.

Quote:

tzt wrote:

hal2k1 wrote:

MPEG LA will allow anyone to implement their codec once they have paid for a license ... but that permission to implement the codec goes only to the party who paid for the license. So, Mozilla or a Linux distribution could pay MPEG LA for a license and implement a h.264 codec, but they could not subsequently give that code and all rights on to anyone else as a downstream recipient. The MPEG LA licesnse is not transferrable, and it certainly doesn't multiply like loaves and fishes, so copyleft rights cannot apply to it. Because all of Mozilla's code, and all of the code of a Linux distribution only belongs to Mozilla or to the Linux distribution only as long as they can keep it copyleft, it means that neither Mozilla nor a Linux distribution can distribute anything if it included a H.264 codec.

It is the licensing terms conflict between the way that Mozilla and Linux has obtained their own codebase and what they must do to retain the right to improve and distribute that codebase, versus the restrictions implicit in licensed IP such as a MPEG LA codec, that mean that neither Linux distributions nor Mozilla are allowed to distribute a h.264 codec.

Again, this is also a lie. The source (ie the codebase) transfers fine, which is kind of the point of open source and the GPL license. There is no restriction at all by anyone for this. Of course they can't distribute large quantities of branded binary compiled implementations w/o IP violation but that's rather another issue other than the codebase.

You have a severe misunderstanding here (perhaps x264 developers do also). MPEG LA asked $5 million dollars per year for Mozilla to obtain a license to implement H.264 AVC.

The $5 million per year that it would cost Mozilla to include a H264 codec in their browser is not the main problem, however, it is the way that Mozilla's code is licensed. MPEG-LA would not allow their codecs to be distributed under the MPL license as it would basically grant anyone (downstream) the right to do anything they wanted with it. So Mozilla cannot distribute a browser that contained a H264 license under the MPL. The MPL is Mozilla's own license.

No it wouldn't. They can still do anything they want with the code per GPL. If MPL per se is a problem they can use the GPL.

Quote:

There is an exact similar problem in the GPL. To distribute code under the GPL requires that you award all downstream recipients all rights to any patent IP within the code, or you cannot distribute the code under the GPL.

The IP rights are not Mozilla's to assert anyway.

Quote:

http://www.gnu.org/licenses/gpl-2.0.html"Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all."

This is not compatible with MPEG LA's license. Therefore, Linux distributions cannot include a H.264 codec (even if the Linux distribution themselves paid for a license).

That deals with licensors who contribute source via gpl. It's called the "implicit patent license".

The subject is explicitly dealt with in 3.0.

Quote:

tzt wrote:

Why should I treat someone who obviously doesn't give a shit about the thread or anyone posting in it with anything except what they deserve?

Because you are utterly wrong, and have been so since forever. You owe many people a huge apology.

WTF are you talking about? DXVA was first introduced as a standardized API with Windows 2000.

The first version of the H.264/MPEG-4 or AVC (Advanced Video Coding) standard was completed in May 2003. DXVA does not implement H.264 AVC decoding.

Yes it does.

I don't think you understand how low-level and versatile DXVA is; I'd suggest you read the various operations that the API can handle. Though the accelerator can handle pretty much the entire decode, it doesn't have to. The supported codecs are MPEG-1, H.261, H.262, MPEG-2/H.263, MPEG-4, MPEG4-10/H.264, WMV 8, and WMV9/VC-1.

You keep presenting DXVA as if it were a simple "pass the raw bitstream and the accelerator does everything else" API. It is not.

DXVA may allow one to access a codec supported by the GPU, but clearly there was no support for MPEG4-10/H.264 when DXVA was introduced.

You yourself admitted there was support in your own post.

Quote:

There is a separation between the codec decoding function and other generic video acceleration functions that you seem utterly reluctant to admit. For example, H.264 I believe requires IDCT (Inverse Discrete Cosine transformation) ... but IDCT is not unique to H.264. It is a generic mathematical function, and some GPUs support it.

All these codecs use idct, and so all dxva gpus support it. This is the class of stuff that takes up the vast majority of the time-consuming calculations.

Supporting idct's is not a separate matter from supporting h.264 as you believe it is because your understanding is based on keywords from press releases.

Quote:

Specific support for the H.264 codec did not first appear in GPUs until about 2007, and not until 2009 did it become common. The majority of hardware in use on the desktop, to this very day, does not have specific suport for H.264 (even though some more of it may have support for some generic pieces of video hardware acceleration such as IDCT, some of which can be pressed into service to accelerate parts of the video chain when decoding H.264).

As already explained to you more than once, bitstream support for h.264 is not really all that significant anyway.

BTW, to avoid leaving the impression that something hal2k1 wrote I didn't explicitly reply to has any actual merit, I just somehow remembered that ridiculous argument MS-Apple somehow "controls" h.264 which didn't get a response. I've also seen this paraded around the prior threads by presumably like-minded slashdot idiots so it's worth addressing.

These people can't even get their basic hatred of corps right. MS was the fiercest competitors to h.264 with their vc-1 codec to the point of offering the latter for free which was foiled by mpeg-la. To say that MS is a reluctant supporter would be an understatement. Of course this disrupts the "anything MS touches is evil because they have cooties" narrative. Just as important, both companies pay more into the association than they get out. If anyone's going to make accusations about the money, the mpeg-la mostly funnels money from medium-sized electronics companies (blu-ray players, pmp's, etc) and broadcasters to the electronics giants like Matsushita and LG and Toshiba.

Again, these idiots make the rest of us who criticize corps who know what's going on look bad by association.

Strawman. Nowhere did I say that Microsoft or Apple "controls" H.264 AVC or MPEG LA. Not even close.

I said only that they are members of the MPEG LA licensors group for H.264 AVC. This is significant only because there is an agreement between the members of this group not to sue one another over the patents held by the whole group. Therefore, Microsoft and Apple can offer their customers "indemnification" concerning those patents, at no cost to Microsoft and Apple. Mind you, they can not get any protection form patents outside the group, such as those won by On2 and now held by Google, so they do not offer their customers and indemnification against those patents.

Both companies offer "indemnification" because they both pay the MPEG-LA (more than they get out of it as has been pointed out). This is seperate from being part of the patent pool. But I'm sure you're be here to point out how by "no cost" you actually mean "same cost as everyone else".

None of what you've said has any bearing on whether Linux distros distribute the x264 codec: they do, I've given two examples. Redefining "distribute" to mean "only on the LiveCD", and back-track on your false statement doesn't change that.

Regardless of "your definition vs my definition" arguments which could go on all day, it is still true to say that Linux distributions do not distribute the x264 codec by default to all their users. Linux distributions start with whatever is on the LiveCD, and only that. That is all that is distributed to every user.

Now the bulk of the users will also want the x264 codec, and are perfectly entitiled to get it according to the laws of their country, so such users are afforded the opportunity to ask for the codec and they will then be given it. The responsibility for getting the codec is up to the end users (for most end users it is perfectly fine for them to get it).

In this way, Linux distributions can work around the limitation that they are not permitted to distribute the x264 codec to all end users.

Linux userland programs, such as browsers, simply cannot assume that the x264 codec will be installed, because by default it won't be.

Your pedantic petulance doesn't change the fact that this limitation on distribution of the x264 codec does apply, and that it is not distributed by default. My point stands.

The MPEG LA patent pool is, after all, largely a collection of US patents.

This is another example of how fucking stupid your arguments are. It takes all of 1 min to google and find out what's in the pool (which includes a shitload of IP from other countries) and you can't even do that right.

Quote:

Your pedantic petulance doesn't change the fact that this limitation on distribution of the x264 codec does apply, and that it is not distributed by default. My point stands.

Speaking of pedantic petulance, he's not the one making arbitrary distinctions of what's "core" (which I guess doesn't include media codecs makes you right by semantics) and what's not.]

As already explained to you more than once, bitstream support for h.264 is not really all that significant anyway.

Au contraire, bitstream support for h.264 is the ONLY thing that is important to any H.264 supporters claim that "decoding h264 is supported in GPU hardware and WebM is not".

You can't have it both ways. Either (a) "bitstream support for h.264 is not really all that significant" and therefore H.264 and WebM both enjoy approximately equal hardware support for acceleration of video, or (b) bitstream support for h.264 is really significant, but really only became supported in entry-level machines in 2009, and is still not present in the majority of web client machines today.

Which is it?

BTW, here is a free tip: try not to be rude, it utterly detracts from your credibility.

The MPEG LA patent pool is, after all, largely a collection of US patents.

This is another example of how fucking stupid your arguments are. It takes all of 1 min to google and find out what's in the pool (which includes a shitload of IP from other countries) and you can't even do that right.

It doesn't matter where the IP originates, what matters is where it is patented. The US is virtually the only place that is stuipd enough to allow patents on mathematics.

Quote:

Quote:

Your pedantic petulance doesn't change the fact that this limitation on distribution of the x264 codec does apply, and that it is not distributed by default. My point stands.

Speaking of pedantic petulance, he's not the one making arbitrary distinctions of what's "core" (which I guess doesn't include media codecs makes you right by semantics) and what's not.]

It isn't arbitrary ... if it is not on the LiveCD (the installation CD), then it is not distributed by default to all users. This is a simple fact. Duh.

Quote:

Oh and btw, you don't install x264 for decoding. LOL.

True. x264 is an encoder library, ffmpeg I believe is the library for decoding ... the same argument applies to both. The OP to which I was responding was talking in terms of x264, but that was not the essence of the argument. Pedant.

Minor correction: ffmpeg includes libavcodec, which is the actually library containing the codecs.http://www.ffmpeg.org/Wouldn't want to upset any pedantic readers.

As already explained to you more than once, bitstream support for h.264 is not really all that significant anyway.

Au contraire, bitstream support for h.264 is the ONLY thing that is important to any H.264 supporters claim that "decoding h264 is supported in GPU hardware and WebM is not".

Because HW support for one doesn't imply support for another since the formats differ more than in bitsteam?

Also, as mentioned before but you were too slow to pick up because it was not spoonfed, the SW support is also important.

Quote:

You can't have it both ways. Either (a) "bitstream support for h.264 is not really all that significant" and therefore H.264 and WebM both enjoy approximately equal hardware support for acceleration of video, or (b) bitstream support for h.264 is really significant, but really only became supported in entry-level machines in 2009, and is still not present in the majority of web client machines today.

Which is it?

BTW, here is a free tip: try not to be rude, it utterly detracts from your credibility.

Unfortunately for the really stupid, the world is more complex than a simple dichotomy between idct and "bitstream". For example, vp8's entropy coding is probably not supported but of course since that's not in a press release you wouldn't know about it.

The MPEG LA patent pool is, after all, largely a collection of US patents.

This is another example of how fucking stupid your arguments are. It takes all of 1 min to google and find out what's in the pool (which includes a shitload of IP from other countries) and you can't even do that right.

It doesn't matter where the IP originates, what matters is where it is patented. The US is virtually the only place that is stuipd enough to allow patents on mathematics.

If you'd take that one minute to actually do the google search, you'd find out that you're only digging this hole for yourself even deeper.

Quote:

Quote:

Quote:

Your pedantic petulance doesn't change the fact that this limitation on distribution of the x264 codec does apply, and that it is not distributed by default. My point stands.

Speaking of pedantic petulance, he's not the one making arbitrary distinctions of what's "core" (which I guess doesn't include media codecs makes you right by semantics) and what's not.]

It isn't arbitrary ... if it is not on the LiveCD (the installation CD), then it is not distributed by default to all users. This is a simple fact. Duh.

True. x264 is an encoder library, ffmpeg I believe is the library for decoding ... the same argument applies to both. The OP to which I was responding was talking in terms of x264, but that was not the essence of the argument. Pedant.

hahahah:

Quote:

Linux userland programs, such as browsers, simply cannot assume that the x264 codec will be installed, because by default it won't be.

None of what you've said has any bearing on whether Linux distros distribute the x264 codec: they do, I've given two examples. Redefining "distribute" to mean "only on the LiveCD", and back-track on your false statement doesn't change that.

Regardless of "your definition vs my definition" arguments which could go on all day, it is still true to say that Linux distributions do not distribute the x264 codec by default to all their users. Linux distributions start with whatever is on the LiveCD, and only that. That is all that is distributed to every user.

Now the bulk of the users will also want the x264 codec, and are perfectly entitiled to get it according to the laws of their country, so such users are afforded the opportunity to ask for the codec and they will then be given it. The responsibility for getting the codec is up to the end users (for most end users it is perfectly fine for them to get it).

In this way, Linux distributions can work around the limitation that they are not permitted to distribute the x264 codec to all end users.

Linux userland programs, such as browsers, simply cannot assume that the x264 codec will be installed, because by default it won't be.

Your pedantic petulance doesn't change the fact that this limitation on distribution of the x264 codec does apply, and that it is not distributed by default. My point stands.

I'm not arguing anything other than your assertion that Linux distributions can't distribute H.264 related code. It's not pedantry, you made an out-and-out false statement, I thought it should be corrected. It shouldn't be a big deal to admit the error. Btw, to demonstrate the problem: your new definition excludes X.org, Firefox, all of KDE and GNOME, etc, as being distributed by ArchLinux.

I am done with your silly unfocused argument, the falsity of which I assure you is obvious to everyone else. You're too busy twisting words; desperately trying to look like you didn't make an error.

So, either codec-specific bitstream format operations are vitally important to hardware acceleration of video, or they are not. Either WebM enjoys about the same level of support as H264 in hardware acceleration of video, or it does not.

So, either codec-specific bitstream format operations are vitally important to hardware acceleration of video, or they are not. Either WebM enjoys about the same level of support as H264 in hardware acceleration of video, or it does not.

Which is it?

Instead of just telling you where you're wrong let's get to the why. For some reason you believe that the two scenarios are symmetrical. It's not because even though there was not specific "bitstream" support for h.264 because it's simply not necessary, the HW acc was still specifically designed to support h.264 and vc-1 decoding and anything that works for vp8 is entirely incident upon On2 making it quite similar to h.264 (but not identical which has both legal implications and technical ones for this very topic). HW support is not keywords out of wiki that you copy/pasted. Some features are not support as mentioned above. Keywords support does not necessarily imply HW support, for instance block sizes X,Y may be used in a codec A, but Y,Z used in codec B. HW support for h.264 implies in-loop deblock. Does vp8 do it exactly the same way or similar enough to reuse the HW? I'm can't recall that it does off top of my head that it does, but spending time to find out for sure is not necessary to show how fucking unbelievably stupid your wishful thinking about this subject is.

IOW, let me make this as simple as possible: the HW companies looked at supporting h.264 and designed their product to support a meaningful subset of all that decoding it entails. Does that set of functions overlap exactly with what can be used for vp8? Some of it perhaps, but it's entirely dependent on often subtle algorithm details none of which you can find in a press release.

The problem also isn't limited to features per se. h.264 details bitrate levels (blocks/s etc), and this provides HW with meaningful targets. Unless vp8 copies the exact same specs, a discrepancy when encoding will be problematic esp on smaller devices.

So, either codec-specific bitstream format operations are vitally important to hardware acceleration of video, or they are not. Either WebM enjoys about the same level of support as H264 in hardware acceleration of video, or it does not.

Which is it?

Instead of just telling you where you're wrong let's get to the why. For some reason you believe that the two scenarios are symmetrical. It's not because even though there was not specific "bitstream" support for h.264 because it's simply not necessary, the HW acc was still specifically designed to support h.264 and vc-1 decoding and anything that works for vp8 is entirely incident upon On2 making it quite similar to h.264 (but not identical which has both legal implications and technical ones for this very topic). HW support is not keywords out of wiki that you copy/pasted. Some features are not support as mentioned above. Keywords support does not necessarily imply HW support, for instance block sizes X,Y may be used in a codec A, but Y,Z used in codec B. HW support for h.264 implies in-loop deblock. Does vp8 do it exactly the same way or similar enough to reuse the HW? I'm can't recall that it does off top of my head that it does, but spending time to find out for sure is not necessary to show how fucking unbelievably stupid your wishful thinking about this subject is.

IOW, let me make this as simple as possible: the HW companies looked at supporting h.264 and designed their product to support a meaningful subset of all that decoding it entails. Does that set of functions overlap exactly with what can be used for vp8? Some of it perhaps, but it's entirely dependent on often subtle algorithm details none of which you can find in a press release.

The problem also isn't limited to features per se. h.264 details bitrate levels (blocks/s etc), and this provides HW with meaningful targets. Unless vp8 copies the exact same specs, a discrepancy when encoding will be problematic esp on smaller devices.

Get real. Almost all of those operations are not codec-specific. Do you really expect people to believe that "alpha blending, inverse quantization, color space conversion & frame-rate conversion operations, deinterlacing operations, image scaling and multivariate interpolation, deblocking, deringing, sharpen / unsharpen, requantization, luminance alterations, blurring / denoising and anti-aliasing" have anything at all to do with any particular codec's bitstream format at all?

I mean, image scaling? Color space conversions (YUV to RGB for example), antialiasing, deinterlacing, etc? Codec-specific? You really, really expect people to believe that? Especially when you consider that the Windows API for these functions first appeared with DXVA circa 2000, and H264 was first drafted circa 2004.

"So, either codec-specific bitstream format operations are vitally important to hardware acceleration of video, or they are not. Either WebM enjoys about the same level of support as H264 in hardware acceleration of video, or it does not.

There are versions of ffmpeg and libavcodec that are distributed without h264.

Here is a not-on-the-LiveCD version of libavcodec for Ubuntu which does, it is meant to replace the copy of libavcodec which comes with Unbuntu and thereby provide full multimedia capability for people who live in places not concerned about US patents.

So, either codec-specific bitstream format operations are vitally important to hardware acceleration of video, or they are not. Either WebM enjoys about the same level of support as H264 in hardware acceleration of video, or it does not.

Which is it?

Instead of just telling you where you're wrong let's get to the why. For some reason you believe that the two scenarios are symmetrical. It's not because even though there was not specific "bitstream" support for h.264 because it's simply not necessary, the HW acc was still specifically designed to support h.264 and vc-1 decoding and anything that works for vp8 is entirely incident upon On2 making it quite similar to h.264 (but not identical which has both legal implications and technical ones for this very topic). HW support is not keywords out of wiki that you copy/pasted. Some features are not support as mentioned above. Keywords support does not necessarily imply HW support, for instance block sizes X,Y may be used in a codec A, but Y,Z used in codec B. HW support for h.264 implies in-loop deblock. Does vp8 do it exactly the same way or similar enough to reuse the HW? I'm can't recall that it does off top of my head that it does, but spending time to find out for sure is not necessary to show how fucking unbelievably stupid your wishful thinking about this subject is.

IOW, let me make this as simple as possible: the HW companies looked at supporting h.264 and designed their product to support a meaningful subset of all that decoding it entails. Does that set of functions overlap exactly with what can be used for vp8? Some of it perhaps, but it's entirely dependent on often subtle algorithm details none of which you can find in a press release.

The problem also isn't limited to features per se. h.264 details bitrate levels (blocks/s etc), and this provides HW with meaningful targets. Unless vp8 copies the exact same specs, a discrepancy when encoding will be problematic esp on smaller devices.

Get real. Almost all of those operations are not codec-specific. Do you really expect people to believe that "alpha blending, inverse quantization, color space conversion & frame-rate conversion operations, deinterlacing operations, image scaling and multivariate interpolation, deblocking, deringing, sharpen / unsharpen, requantization, luminance alterations, blurring / denoising and anti-aliasing" have anything at all to do with any particular codec's bitstream format at all?

Uh, those are just video operations that would be useful in a renderer, ie. not decoding. To be perfectly clear since you're going to argue about this because you're cluless: image scaling/color space conversions/antialiasing are not part of the codec.

Quote:

I mean, image scaling? Color space conversions (YUV to RGB for example), antialiasing, deinterlacing, etc? Codec-specific? You really, really expect people to believe that? Especially when you consider that the Windows API for these functions first appeared with DXVA circa 2000, and H264 was first drafted circa 2004.

DXVA is not static. DrPizza actually linked you to the relevant docs but it didn't help since they weren't press releases.

Big words for someone who doesn't even know what decoding is. Notice DXVA does not stand for Decoding Acceleration.

Quote:

BTW, I repeat the question which you avoided:

"So, either codec-specific bitstream format operations are vitally important to hardware acceleration of video, or they are not. Either WebM enjoys about the same level of support as H264 in hardware acceleration of video, or it does not.

Which is it?"

I gave you the answer. It doesn't enjoy the same level of support because PR keyword overlap isn't the same thing as HW support. Don't blame others if you can't and don't want to understand it.

There are versions of ffmpeg and libavcodec that are distributed without h264.

Here is a not-on-the-LiveCD version of libavcodec for Ubuntu which does, it is meant to replace the copy of libavcodec which comes with Unbuntu and thereby provide full multimedia capability for people who live in places not concerned about US patents.

Again, we discussed source vs binary above. It's not surprising they can't distribute a compiled codec with their OS but that hardly has anything to do with the gpl and open source (as clearly evidenced by the fact those lib ARE gpl, and even if in bizarro world they're not other open licenses are available). Since repeated multiple times for the slow: it's too bad the beer's not free.

-Look buddy, you clearly don't know what the hell you're talking about when it comes to video or software licensing. Do you have any relevant arguments on topic that you do know something about? Otherwise this is just an exhibition on the lengths some internet moron will go to to show how badly they can misunderstand a subject. If you're looking for some kind of metal there, can we just assume you'll get one with this kind of performance and move on to something more interesting?

There are versions of ffmpeg and libavcodec that are distributed without h264.

Here is a not-on-the-LiveCD version of libavcodec for Ubuntu which does, it is meant to replace the copy of libavcodec which comes with Unbuntu and thereby provide full multimedia capability for people who live in places not concerned about US patents.

Again, we discussed source vs binary above. It's not surprising they can't distribute a compiled codec with their OS but that hardly has anything to do with the gpl and open source (as clearly evidenced by the fact those lib ARE gpl, and even if in bizarro world they're not other open licenses are available). Since repeated multiple times for the slow: it's too bad the beer's not free.

-Look buddy, you clearly don't know what the hell you're talking about when it comes to video or software licensing. Do you have any relevant arguments on topic that you do know something about? Otherwise this is just an exhibition on the lengths some internet moron will go to to show how badly they can misunderstand a subject. If you're looking for some kind of metal there, can we just assume you'll get one with this kind of performance and move on to something more interesting?

Look bozo, you saying something does not make it so. You are clearly utterly wrong on this topic, every which way you can be.

A perfect example is your trying to insist that hardware acceleration support for h.264 is near-universal, and trying to prove it by mentioning DXVA and saying it has been around for ages. You were right insofar as DXVA being around for ages, but as for that showing that there is wide support for hardware acceleration for h.264 - wrong, wrong, wrong. Utterly wrong. As wrong as wrong can be.

Now you are backpedalling a thousand miles an hour, and trying to pretend it was I who didn't understand what DXVA was.

Let's review your brief history on this topic. First you had no idea DXVA even existed. Then when it was pointed out multiple times, you still couldn't bother to find out what it does. Then when that was spoonfed to you, you're still confused that its functionality covers not only decoding but rather a broad spectrum of video related algorithms.

On top of this, you still retain this indignant attitude like anyone owes you an once of respect for this incredibly shameful behavior.

Ironically, this is one part of the reason why webm will likely fail. A wide variety of folk in tech tend to take impressions of technology by the people who associate with it just like everything else in life, and these threads on Ars seem to be reflect of the general demographics. The approximate equivalent here is the peopleofwalmart or rather their wannabe counterparts in our version of trailer parks leaving their image forever tied to vp8.

That's probably not the kind of brand recognition Google should shoot for.

Let's review your brief history on this topic. First you had no idea DXVA even existed.

Not correct ... I ignored it because it was pre-2004 and it had nothing to do with H.264 (specific) decoding. I pointed this out to you.

Quote:

Then when it was pointed out multiple times, you still couldn't bother to find out what it does. Then when that was spoonfed to you, you're still confused that its functionality covers not only decoding but rather a broad spectrum of video related algorithms.

It doesn't cover decoding of specific formats. I pointed this out to you the very first time you mentioned it.

Quote:

On top of this, you still retain this indignant attitude like anyone owes you an once of respect for this incredibly shameful behavior.

Ironically, this is one part of the reason why webm will likely fail. A wide variety of folk in tech tend to take impressions of technology by the people who associate with it just like everything else in life, and these threads on Ars seem to be reflect of the general demographics. The approximate equivalent here is the peopleofwalmart or rather their wannabe counterparts in our version of trailer parks leaving their image forever tied to vp8.

That's probably not the kind of brand recognition Google should shoot for.

That's rich. You trying to take the holier-than-thou moral high ground? You, who has done nothing but fling insult after insult when your illogic is pointed out?

I'm sure this outrageous, laughable rhetoric must be straight out of "logical debating fallacies 101".

Let's review your brief history on this topic. First you had no idea DXVA even existed.

Not correct ... I ignored it because it was pre-2004 and it had nothing to do with H.264 (specific) decoding. I pointed this out to you.

DXVA applies both to pre 2004 (which is not terribly interesting) AND to post 2004 and h.264 (which is what we're talking about). Again, you've shown that to ignore things which you don't understand for fear of it reflecting poorly. It doesn't work like that.

Quote:

Quote:

Then when it was pointed out multiple times, you still couldn't bother to find out what it does. Then when that was spoonfed to you, you're still confused that its functionality covers not only decoding but rather a broad spectrum of video related algorithms.

It doesn't cover decoding of specific formats. I pointed this out to you the very first time you mentioned it.

DXVA functionality was exactly designed and used for h.264 even before specific support for its bitstream. The latter does not preclude nor is essential to the former. This was explained to you multiple times and you continue believe that willpower alone will make it go away.

Quote:

Quote:

On top of this, you still retain this indignant attitude like anyone owes you an once of respect for this incredibly shameful behavior.

Ironically, this is one part of the reason why webm will likely fail. A wide variety of folk in tech tend to take impressions of technology by the people who associate with it just like everything else in life, and these threads on Ars seem to be reflect of the general demographics. The approximate equivalent here is the peopleofwalmart or rather their wannabe counterparts in our version of trailer parks leaving their image forever tied to vp8.

That's probably not the kind of brand recognition Google should shoot for.

That's rich. You trying to take the holier-than-thou moral high ground? You, who has done nothing but fling insult after insult when your illogic is pointed out?

I'm sure this outrageous, laughable rhetoric must be straight out of "logical debating fallacies 101".

If you're going to make shameless accusations, please be specific. I've claimed and shown abundant evidence that both you and your arguments are willfully ignorant and maliciously stupid. If you don't like that, the solution is simple: refrain from acting in such a manner and people won't call you out for it.

DXVA functionality was exactly designed and used for h.264 even before specific support for its bitstream. The latter does not preclude nor is essential to the former. This was explained to you multiple times and you continue believe that willpower alone will make it go away.

WTF? Are you naturally that stupid, or do you have to work at it?

H264 didn't exist when DXVA was designed. Yes DXVA functions work with H264, but they also work with every other codec. Including WebM. You have a huge problem following simple concepts such as "cause and effect". Clearly DXVA cannot have been designed for H264 because H264 did not yet exist when DXVA was designed.

Even dogs and monkeys can understand causality ... nah, that can't be it. You can't be that much of a simpleton, because it is clear that you can spell for example. Scratch the "stupid" remark ... you are clearly willfully and shamelessly dishonest.

DXVA functionality was exactly designed and used for h.264 even before specific support for its bitstream. The latter does not preclude nor is essential to the former. This was explained to you multiple times and you continue believe that willpower alone will make it go away.

WTF? Are you naturally that stupid, or do you have to work at it?

H264 didn't exist when DXVA was designed. Yes DXVA functions work with H264, but they also work with every other codec.

That's because DXVA is designed to be extensible as HW supported is added and h.264 support is added in when the standard materialized. This was already told to you by more than one person above and you were and are still too fucking dumb to grasp this simple idea.

Quote:

Including WebM.

Yes, it will work explicitly for WebM if and when support is added. If not, any and all support is coincident upon similarity to existing codecs, which btw is not the same thing as keyword support.

Quote:

You have a huge problem following simple concepts such as "cause and effect". Clearly DXVA cannot have been designed for H264 because H264 did not yet exist when DXVA was designed.

Even dogs and monkeys can understand causality ... nah, that can't be it. You can't be that much of a simpleton, because it is clear that you can spell for example. Scratch the "stupid" remark ... you are clearly willfully and shamelessly dishonest.

Look, you're clearly butthurt because you've been made out to be a complete moron with every single claim you manage to muster up. Why would you claim I'm willfully and shamelessly dishonest when every single thing I've written above is true? That doesn't make any sense. Words have meaning, so please try to learn what they are before putting them together in a sentence. Copycatting what I write about you because of your own unable to express your frustrations for being so damn stupid does not work because I am clearly not you.