And it isn't part of the HTML5 standard so you need a plugin to play it.
Only if your browser doesn't support it. H.264 isn't part of the "Html5" standard either, not the way you're implying. It also costs money, a heck of a lot of money if you plan on trying to make money with your creations.
As opposed to H.264 MP4 which is free to license and an actual standard.
There are different terms for different people along the supply chain. At the decoding level, it certainly isn't free to license.
Quote:
Originally Posted by noirdesir
MP4 is free to license for use in web browsers, for the time being.
No. It is free for certain filmmakers to publish their content on the Web. But it is certainly not free for web browsers to be able to playback the video.
Quote:
Originally Posted by MacRulez
Sure it's free for those who make browsers.
No it isn't.
Quote:
Originally Posted by MacRulez
But if you want to share your work which was encoded with h.264 on a subscription-based site or for a fee...
It's only free to license under very specific guidelines, EG if you intend the content to be free. This means it's NOT free if you intend on making a profit with it, and more than likely you'd have to pay if you wanted to make ads using it. This makes it pointless for a good chunk of professional content.
H.264 is technically superior to WebM, largely thanks to hardware acceleration as well as years of development and refining in the open market, but it is also an expensive format.
H.264 is free to use as a codec for a certain subset of content producers (eg. independent filmmakers) who do not intend to make any money off the videos they've produced.
It is NOT free for content producers who intend to make money off the videos they've produced. The filmmakers themselves (not the manufacturers of the filmmaking equipment) have to purchase a license to do that.
It is NOT free for broadcasters who want to take H.264-encoded video and electronically distribute that content commercially to consumers. The broadcasters themselves (not the manufacturers of the broadcast equipment) have to purchase a license to do that.
It is NOT free to use for hardware and software vendors who produce the machines and computer programs that read the H.264-encoded videos and display them. They have to purchase a license for every copy of the software they distribute, and for every unit of hardware they sell, which implements an H.264 decoder.
If they wish, a 3rd party software vendor (such as a maker of a web browser) can offload decoding of any video to the OS's built-in video decoding subsystem, and if the OS's built-in video decoding subsystem already has support for H.264, then the 3rd party software vendor doesn't have any obligation to purchase an additional license. The OS vendor would have already paid the license fee on the 3rd-party software vendor's behalf.
But for a software vendor that produces software which is intended to run on a great variety of different computer platforms, not all of which are guaranteed to have any particular video codec installed, it can often be considered damaging to reliability and usability to make make use of external dependencies to decode video. Their users would have an inconsistent experience using the same software on two different computers because of different codecs installed on each. This would unfairly reflect badly on the 3rd-party software vendor rather than the OS vendor, because the average user wouldn't care about the OS differences -- they want it to "just work". And it would fracture the consistent interoperability of the Web. Therefore, they may choose to roll their own video decoder right inside the software, rather than depending on any OS services that might (or might not) be able to do it for them. And if they roll their own codec instead of using the OS's built-in services, then they will need to purchase a license for every copy of their software.
Google has done this (so far) with H.264 within its Chrome browser: They embedded a copy of the H.264 codec inside each copy of the Chrome browser they distributed, and they paid a blanket license fee for permission to do that. They've announced plans to discontinue this practice, so future copies of Chrome will no longer have the H.264 decoder embedded, and they will no longer be capable of playing back H.264 videos. Microsoft countered with a plug-in which puts back (not totally feature-complete) H.264 support in Chrome on Windows. (Ironic, because the whole purpose behind adding the <video> tag to HTML5 in the first place was to reduce fracturing of the Web, and remove the need for plug-ins.) I'm not sure what will happen to Chrome on the Mac when Google follows through with its plan.
No codec is part of HTML5 standard so you need a plugin to play any of them
Google Chrome uses built-in video decoders compiled right into the browser (not plug-ins) to natively play content inside the <video> tag. Same with Firefox. Same with Opera. Normally, no plug-ins are involved. IE on Windows and Safari on OSX link directly into the underlying video decoding subsystem of the operating system and can theoretically support any video codec that the OS's underlying video subsystem supports, without the use of the mechanism that is traditionally known as a "browser plug-in". (I'm not sure what mechanism Safari on Windows uses...)
In fact, when the <video> tag was first proposed, one of the primary motivations was to bring video content under the browsers' direct control so that plug-ins wouldn't be needed any more. That original motivation has been blurred in the codec wars that ensued.
Microsoft has demonstrated a variety of plug-ins that could be used to subvert the browser's native handling of the <video> tag in Chrome and Firefox to pass the content on to Microsoft's own video decoders to support codecs that aren't natively contained within the respective browsers. This is the exception for these browsers, not the rule.
Comments
And it isn't part of the HTML5 standard so you need a plugin to play it.
Only if your browser doesn't support it. H.264 isn't part of the "Html5" standard either, not the way you're implying. It also costs money, a heck of a lot of money if you plan on trying to make money with your creations.
Google completely controls the code and all aspects of its development.
That's the definition of proprietary software. Even Lion knows that.
And WebM doesn't match this definition, have you read the license of WebM?
And it isn't part of the HTML5 standard so you need a plugin to play it.
No codec is part of HTML5 standard so you need a plugin to play any of them
As opposed to H.264 MP4 which is free to license and an actual standard.
There are different terms for different people along the supply chain. At the decoding level, it certainly isn't free to license.
MP4 is free to license for use in web browsers, for the time being.
No. It is free for certain filmmakers to publish their content on the Web. But it is certainly not free for web browsers to be able to playback the video.
Sure it's free for those who make browsers.
No it isn't.
But if you want to share your work which was encoded with h.264 on a subscription-based site or for a fee...
http://www.streaminglearningcenter.c...d-to-know.html
More info:
http://www.mpegla.com/main/programs/...Agreement.aspx
This is why the EULA for Final Cut Pro includes:
http://bemasc.net/wordpress/2010/02/...hat-with-h264/
It's only free to license under very specific guidelines, EG if you intend the content to be free. This means it's NOT free if you intend on making a profit with it, and more than likely you'd have to pay if you wanted to make ads using it. This makes it pointless for a good chunk of professional content.
H.264 is technically superior to WebM, largely thanks to hardware acceleration as well as years of development and refining in the open market, but it is also an expensive format.
H.264 is free to use as a codec for a certain subset of content producers (eg. independent filmmakers) who do not intend to make any money off the videos they've produced.
It is NOT free for content producers who intend to make money off the videos they've produced. The filmmakers themselves (not the manufacturers of the filmmaking equipment) have to purchase a license to do that.
It is NOT free for broadcasters who want to take H.264-encoded video and electronically distribute that content commercially to consumers. The broadcasters themselves (not the manufacturers of the broadcast equipment) have to purchase a license to do that.
It is NOT free to use for hardware and software vendors who produce the machines and computer programs that read the H.264-encoded videos and display them. They have to purchase a license for every copy of the software they distribute, and for every unit of hardware they sell, which implements an H.264 decoder.
If they wish, a 3rd party software vendor (such as a maker of a web browser) can offload decoding of any video to the OS's built-in video decoding subsystem, and if the OS's built-in video decoding subsystem already has support for H.264, then the 3rd party software vendor doesn't have any obligation to purchase an additional license. The OS vendor would have already paid the license fee on the 3rd-party software vendor's behalf.
But for a software vendor that produces software which is intended to run on a great variety of different computer platforms, not all of which are guaranteed to have any particular video codec installed, it can often be considered damaging to reliability and usability to make make use of external dependencies to decode video. Their users would have an inconsistent experience using the same software on two different computers because of different codecs installed on each. This would unfairly reflect badly on the 3rd-party software vendor rather than the OS vendor, because the average user wouldn't care about the OS differences -- they want it to "just work". And it would fracture the consistent interoperability of the Web. Therefore, they may choose to roll their own video decoder right inside the software, rather than depending on any OS services that might (or might not) be able to do it for them. And if they roll their own codec instead of using the OS's built-in services, then they will need to purchase a license for every copy of their software.
Google has done this (so far) with H.264 within its Chrome browser: They embedded a copy of the H.264 codec inside each copy of the Chrome browser they distributed, and they paid a blanket license fee for permission to do that. They've announced plans to discontinue this practice, so future copies of Chrome will no longer have the H.264 decoder embedded, and they will no longer be capable of playing back H.264 videos. Microsoft countered with a plug-in which puts back (not totally feature-complete) H.264 support in Chrome on Windows. (Ironic, because the whole purpose behind adding the <video> tag to HTML5 in the first place was to reduce fracturing of the Web, and remove the need for plug-ins.) I'm not sure what will happen to Chrome on the Mac when Google follows through with its plan.
No codec is part of HTML5 standard so you need a plugin to play any of them
Google Chrome uses built-in video decoders compiled right into the browser (not plug-ins) to natively play content inside the <video> tag. Same with Firefox. Same with Opera. Normally, no plug-ins are involved. IE on Windows and Safari on OSX link directly into the underlying video decoding subsystem of the operating system and can theoretically support any video codec that the OS's underlying video subsystem supports, without the use of the mechanism that is traditionally known as a "browser plug-in". (I'm not sure what mechanism Safari on Windows uses...)
In fact, when the <video> tag was first proposed, one of the primary motivations was to bring video content under the browsers' direct control so that plug-ins wouldn't be needed any more. That original motivation has been blurred in the codec wars that ensued.
Microsoft has demonstrated a variety of plug-ins that could be used to subvert the browser's native handling of the <video> tag in Chrome and Firefox to pass the content on to Microsoft's own video decoders to support codecs that aren't natively contained within the respective browsers. This is the exception for these browsers, not the rule.