And yet if were the IE team to say the same thing Microsoft would be being constantly trashed claiming that they're ignoring standards. Oh how double standards are fun.
Think of Netscape, they were the king of the browser market. They did a clean restart, and it took them so long to create anything useful that Netscape never recovered.
Well that and the fact that the version of Netscape that was out at the time they started that rewrite was buggy and crappy.
Imagine being the guy they hire to manage an ARM port at Microsoft. Could there be a worse job at Microsoft?
Why? The WinMo and WinCE teams seem to be quite fine jobs to have at Microsoft. Oh, are you one of those people who hasn't realized that Microsoft has had working products on ARM since the late 90s?
But that's not possible!!!! Netscape only failed because Microsoft was a big, bad, mean bully!! It had nothing to do with the fact that Netscape was buggy and the company was shooting itself doing a huge rewrite of the browser while IE was improving and steadily releasing new versions!!! How dare you bring up the real history instead of the Slashtard romanticized version!!!!!
If they removed H.264 streams from Youtube that could be said, but right now it's more a gentle push.
I doubt they'd be that stupid. It'd kill the battery life of iPhones and Android phones when playing Youtube videos since they could no longer use the lower power ASIC for decoding.
Not that I know the specifics, but I would imagine that in the mean time there could be some wrappers created that would at least offer some hardware acceleration benefit to the format.
You would imagine wrong. H.264 is decoded by specialized ASICs in phones, video cards, stbs. There is no way you can "wrap" anything to get WebM decoded by these.
Let me put it in plain terms here: We've all been through this before--many times. It's nothing new, and won't stop with h.264 or any other codec. When a new technology comes out, you'll eventually need to upgrade.
Sure, but one has to question whether this "upgrade" is really worth anything. And the only one who benefits from this forced upgrade is Google and a bunch of hardware manufacturers.
But that is in the past, by focusing on it now, you are making it look like (in fact making the argument) that H.264 is more open,
In many ways it still is. H.264 is an ISO standard in which more than one company has say in how the spec is managed. VP8 is still highly controlled by Google.
through focus on and old irrelevant fact, but ignoring another definition of the word open where WebM is much more open than H.264 will ever be.
It's not all that irrelevant since if one is to call H.264 "closed" by the very same standard one has to call C++ "closed" as well.
* According to one aspect H.264 was once more open, but this aspect applies to the past.
No, H.264 is still an open ISO standard. This has not changed.
* According to another aspect WebM is much more open, and this applies today.
It's more "open" with respects to patents, but the development is still highly centralized within Google so in many cases it is still far more "closed".
I am not saying you are wrong, you are in fact right, but you are distorting the debate through pedantic and irrelevant details.
I'm not distorting anything. I'm pointing out the fact that if you call H.264 a "closed" standard than you have to call pretty much any other standard that is being held up as "open" as closed as well.
That's great, but it means nothing for all the people who own phones, video cards, standalone players, etc that only have H.264 support. Are consumers supposed to just ditch all this previous, and in some cases expensive, hardware just to get support because Google wants to foist another codec into the jungle of codecs that the world already faces?
Thank you. Someone finally understands what I'm saying. The problem is that so many other standards that work in the exact same way that H.264 did are referred to as "open" yet H.264 is demonized as being "closed" despite there being little to no difference in the way both standards were developed.
It is just another example of doublespeak. You are redefining words but focusing on an irrelevant part of the definition.
I'm not redefining anything. You've just quote mined my post to attack it. Up until Google open source VP8 it was a proprietary, closed sourced standard. H.264 was an "open" ISO standard in the same vein as how C++ is an "open" ISO standard.
While you could technically be right, you are still distorting the truth, and that, to me, is bad part of lying.
What part of the truth am I distorting? H.264 was developed during the ISO process by the input of lots of companies and industry people and had an openly published spec. VP8 had no public spec, was completely closed source and had all development driven by one company. As I said, until 7 months ago the former, H.264, was far more "open" than VP8 ever was until May of last year.
I don't think it stands up to any of the FOSS definitions of "open".
And the same could be said about the C++ and ODF standards yet those are called "open" standards by the same people talking about how H.264 is "closed".
VP8 - maybe it wasn't open 7 months ago, but it is now.
Is it really? Can any individual really have any meaningful say in the direction of how the VP8 codec is developed unless you work at Google? Sure they've given the source out but you'll have no more say in how the spec develops than you would for the H.264 standard.
Far more so than VP8's development was until last May
Secondly, H.264 is no more "closed" than the supposed "open" standards such as ISO C++ with statements like:
Can you contribute code to H.264?
To turn it around, can YOU contribute to the C++ ISO standard? Highly unlikely just like it's highly unlikely that most people could contribute to the H.264 ISO standard. So by this logic C++ is also a "closed" standard, no?
Yes, really. Before Google opened the code in May of last year, On2 was developing VP8 as a closed-source proprietary codec since 2008. H.264 on the other hand was developed by the ISO standards board and a whole host of companies in it's development. Like all ISO standards one could get access to the full spec. Such a thing was impossible for the first 2.5 years of VP8's life.
Really H.264 may have been public but I would not call it open.
Can you use the spec in your own software and publish it with out a large amount of jumping through hoops?
Sure, x264 developers have been doing so for the better part of 6 years.
It's no less open than most of the other standards which are called "open".
So no I do not feel that H.254 meets the definition of open as far as development goes.
And neither was VP8 until 7 months ago when it was a completely closed-source codec.
So then ODF or C++ are not "open" either, right? One has to pay to get a copy of the spec for those technologies. Secondly, you can freely implement H.264 and release it in source form. MPEGLA has applied an exemption to source code for quite some time which is why, for example, the XviD or x264 people face no problems.
Secondly, even if you are distrbuting binary encoders/decoders you don't pay anything until you hit about 50,000 units shipped.
I can't for example buy and implement it in my app which is released under gpl
And yet there are plenty of apps released as GPL using the GPLed x264 encoder.
And just the thought that I should have to pay each time I publish a video, just because it is encoded with h.264 is insane**.
If you are streaming videos for free you have never paid royalties, and even if you are doing so for pay you have a pretty big threshold to hit before you even start paying royalties.
**This may have been postponed a few years for most people, but still.
Actually back in August the MPEGLA said they will NEVER charge royalties for freely streamed H.264 videos.
Microsoft only supports (say) H.265 on WP7, and neither allows you to upgrade the video support, then you will never get a video to play universally.
Wrong. IE9 natively supports only H.264 but will support playing back videos using other codecs by using the OS multimedia framework and installed codecs. This will allow it to play VP8, Theora, etc.
How is H.264 closed? The spec is available for any one to buy and implement. If H.264 is "closed" than so can be said for the vast majority of ISO standards.
Slashdot Mirror
And yet if were the IE team to say the same thing Microsoft would be being constantly trashed claiming that they're ignoring standards. Oh how double standards are fun.
Think of Netscape, they were the king of the browser market. They did a clean restart, and it took them so long to create anything useful that Netscape never recovered.
Well that and the fact that the version of Netscape that was out at the time they started that rewrite was buggy and crappy.
Oh which the majority of that is from Google's money. Thus making it the same "big-corporation-sponsored open source" he seems to be railing against.
But it's not stealing. It's copyright infringment!!! Well, at least as long as it's not a GPLed piece of software because then it's stealing!!!
A specific set of skills is far less important than the general skills one accumulates over a lifetime of experience.
Except in the case where your customer wants that very same specific skill that said current employee lacked by the new hire knew?
Imagine being the guy they hire to manage an ARM port at Microsoft. Could there be a worse job at Microsoft?
Why? The WinMo and WinCE teams seem to be quite fine jobs to have at Microsoft. Oh, are you one of those people who hasn't realized that Microsoft has had working products on ARM since the late 90s?
Netscape also lost because it sucked.
But that's not possible!!!! Netscape only failed because Microsoft was a big, bad, mean bully!! It had nothing to do with the fact that Netscape was buggy and the company was shooting itself doing a huge rewrite of the browser while IE was improving and steadily releasing new versions!!! How dare you bring up the real history instead of the Slashtard romanticized version!!!!!
If they removed H.264 streams from Youtube that could be said, but right now it's more a gentle push.
I doubt they'd be that stupid. It'd kill the battery life of iPhones and Android phones when playing Youtube videos since they could no longer use the lower power ASIC for decoding.
Not that I know the specifics, but I would imagine that in the mean time there could be some wrappers created that would at least offer some hardware acceleration benefit to the format.
You would imagine wrong. H.264 is decoded by specialized ASICs in phones, video cards, stbs. There is no way you can "wrap" anything to get WebM decoded by these.
Let me put it in plain terms here: We've all been through this before--many times. It's nothing new, and won't stop with h.264 or any other codec. When a new technology comes out, you'll eventually need to upgrade.
Sure, but one has to question whether this "upgrade" is really worth anything. And the only one who benefits from this forced upgrade is Google and a bunch of hardware manufacturers.
Intel says they would support it if it became widely used.
But that is in the past, by focusing on it now, you are making it look like (in fact making the argument) that H.264 is more open,
In many ways it still is. H.264 is an ISO standard in which more than one company has say in how the spec is managed. VP8 is still highly controlled by Google.
through focus on and old irrelevant fact, but ignoring another definition of the word open where WebM is much more open than H.264 will ever be.
It's not all that irrelevant since if one is to call H.264 "closed" by the very same standard one has to call C++ "closed" as well.
* According to one aspect H.264 was once more open, but this aspect applies to the past.
No, H.264 is still an open ISO standard. This has not changed.
* According to another aspect WebM is much more open, and this applies today.
It's more "open" with respects to patents, but the development is still highly centralized within Google so in many cases it is still far more "closed".
I am not saying you are wrong, you are in fact right, but you are distorting the debate through pedantic and irrelevant details.
I'm not distorting anything. I'm pointing out the fact that if you call H.264 a "closed" standard than you have to call pretty much any other standard that is being held up as "open" as closed as well.
That's great, but it means nothing for all the people who own phones, video cards, standalone players, etc that only have H.264 support. Are consumers supposed to just ditch all this previous, and in some cases expensive, hardware just to get support because Google wants to foist another codec into the jungle of codecs that the world already faces?
framework support only works for that OS.
Sure, in the world in which cross-platform multimedia frameworks don't exist. Fortunately we don't live in such a world.
Thank you. Someone finally understands what I'm saying. The problem is that so many other standards that work in the exact same way that H.264 did are referred to as "open" yet H.264 is demonized as being "closed" despite there being little to no difference in the way both standards were developed.
The problem is that is isn't royalty free (with free meaning both price and freedom).
Unless you are charging for the videos, and even then you have to hit a pretty high volume, it IS royalty free indefinitely.
It is just another example of doublespeak. You are redefining words but focusing on an irrelevant part of the definition.
I'm not redefining anything. You've just quote mined my post to attack it. Up until Google open source VP8 it was a proprietary, closed sourced standard. H.264 was an "open" ISO standard in the same vein as how C++ is an "open" ISO standard.
While you could technically be right, you are still distorting the truth, and that, to me, is bad part of lying.
What part of the truth am I distorting? H.264 was developed during the ISO process by the input of lots of companies and industry people and had an openly published spec. VP8 had no public spec, was completely closed source and had all development driven by one company. As I said, until 7 months ago the former, H.264, was far more "open" than VP8 ever was until May of last year.
I don't think it stands up to any of the FOSS definitions of "open".
And the same could be said about the C++ and ODF standards yet those are called "open" standards by the same people talking about how H.264 is "closed".
VP8 - maybe it wasn't open 7 months ago, but it is now.
Is it really? Can any individual really have any meaningful say in the direction of how the VP8 codec is developed unless you work at Google? Sure they've given the source out but you'll have no more say in how the spec develops than you would for the H.264 standard.
If VP8 became the dominant codec used on the internet, the hardware acceleration will follow very quickly.
So basically everyone will be forced to upgrade their phones and computers because Google wants to force ANOTHER codec on the web?
And that's why I said:
Far more so than VP8's development was until last May
Secondly, H.264 is no more "closed" than the supposed "open" standards such as ISO C++ with statements like:
Can you contribute code to H.264?
To turn it around, can YOU contribute to the C++ ISO standard? Highly unlikely just like it's highly unlikely that most people could contribute to the H.264 ISO standard. So by this logic C++ is also a "closed" standard, no?
The point is that H.264 is no less "closed" than other standards which are called "open".
Yes, because Chrome doesn't go to the OS's multimedia framework to play codecs it doesn't support natively. IE9, on the other hand, will.
Really?
Yes, really. Before Google opened the code in May of last year, On2 was developing VP8 as a closed-source proprietary codec since 2008. H.264 on the other hand was developed by the ISO standards board and a whole host of companies in it's development. Like all ISO standards one could get access to the full spec. Such a thing was impossible for the first 2.5 years of VP8's life.
Really H.264 may have been public but I would not call it open.
Can you use the spec in your own software and publish it with out a large amount of jumping through hoops?
Sure, x264 developers have been doing so for the better part of 6 years.
It's no less open than most of the other standards which are called "open".
So no I do not feel that H.254 meets the definition of open as far as development goes.
And neither was VP8 until 7 months ago when it was a completely closed-source codec.
It's not free for anyone to buy and implement.
So then ODF or C++ are not "open" either, right? One has to pay to get a copy of the spec for those technologies. Secondly, you can freely implement H.264 and release it in source form. MPEGLA has applied an exemption to source code for quite some time which is why, for example, the XviD or x264 people face no problems.
Secondly, even if you are distrbuting binary encoders/decoders you don't pay anything until you hit about 50,000 units shipped.
I can't for example buy and implement it in my app which is released under gpl
And yet there are plenty of apps released as GPL using the GPLed x264 encoder.
And just the thought that I should have to pay each time I publish a video, just because it is encoded with h.264 is insane**.
If you are streaming videos for free you have never paid royalties, and even if you are doing so for pay you have a pretty big threshold to hit before you even start paying royalties.
**This may have been postponed a few years for most people, but still.
Actually back in August the MPEGLA said they will NEVER charge royalties for freely streamed H.264 videos.
Microsoft only supports (say) H.265 on WP7, and neither allows you to upgrade the video support, then you will never get a video to play universally.
Wrong. IE9 natively supports only H.264 but will support playing back videos using other codecs by using the OS multimedia framework and installed codecs. This will allow it to play VP8, Theora, etc.
H.264 is closed. VP8 is open.
How is H.264 closed? The spec is available for any one to buy and implement. If H.264 is "closed" than so can be said for the vast majority of ISO standards.