Update: This story has been updated to show that the MPEG-LA's license change applies to free video broadcasts, not applications that encode and decode video. Mozilla vice president of engineering Mike Shaver has questioned the importance of the forever free H.264 license introduced this morning by the MPEG-LA, the organization …
A clearly partisan decision
Arguably the right stance to take (I mean, I don't think so, but I can see the point of view), but a definitely announcement by Mozilla that they're not impartial despite having no direct strategic interest in either codec. The lunacy of "someone's planning a better codec in the future so of the ones that exist now we're supporting only the one that nobody currently uses" is hard to avoid however. I remember they used to get something like 90% of their income from Google by receiving a tiny fee each time a user uses the browser's search box — is it possible they're trying to bind themselves closer to Google now that Chrome is on the scene?
"""The lunacy of "someone's planning a better codec in the future so of the ones that exist now we're supporting only the one that nobody currently uses" is hard to avoid however"""
That's mostly not what the Mozilla guy was saying. He was suggesting that since the MPEG folks had already promised free royalties on h264 through 2014, that extending their promise for a small portion of the h.264-using market past that was pretty much pointless, since they'll be pushing h.265 before 2014, which will require paying licenses.
Since this new promise is likely irrelevant, I suspect that Mozilla isn't going with h.264 for the same reasons they were avoiding it in the past - It's an ugly monopoly tool, which doesn't belong anywhere near open source software.
Quote: "Since this new promise is likely irrelevant, I suspect that Mozilla isn't going with h.264 for the same reasons they were avoiding it in the past - It's an ugly monopoly tool, which doesn't belong anywhere near open source software."
... Unlike Google search or Adobe Flash or any of the other ugly monopoly tools. Oh, oops.
The Mozilla folks are full of double standard shit.
Get a clue
The difference between Flash and Google search is they aren't a web standard, they aren't being put forward as being part of HTML 5, they aren't going to be used by every webmaster in a few years time because they're part of a standard only for MPEG-LA to come along and say "You know that standard your using for free? Yeah you know, the one we gave away for long enough so that everyone forgot about us? Yeah! that's the one. Well now you pay us for using it or we sue your arse"
Thankfully the stance Opera, Mozilla and Chrome are taking, might actually(hopefully?) kill off this madness of getting a patented non-royalty free technology adopted as part of an open standard.
Which is beside the point
What Mozilla are saying on the one hand is that they won't support closed, patented tech in their OSS browser yet on the other hand they are delighted to support closed, patented tech like Flash and Google's search. They are effing hypocrites. Either don't support it at all and drop Google from being built into the browser or STFU and spare us all the high horse.
No what Mozilla are sayin is that they won't BUILD code
that clearly violates both the FOSS and monopoly licenses.
Flash is a plug-in that abides by their plug in protocols, Google search likewise. The plugin is separable from the FOSS license. Building support for H.264 directly into the browser is not. If the H.264 group want to build a plug-in so Firefox supports their codec, they are welcome to do so.
Sadly, it will be
As much as I'd like WebM to become the be-all and end-all, there are some significant hurdles. The biggest of which is the number of devices (*not* just iPhones, but they make up a significant amount) with hardware chips for decoding h264 content. There's no patch that'll magically make them accept WebM, everyone will have to go out and buy new devices.
Obviously, that'll happen eventually. But within four years it might still be a problem.
down voted the wrong post so I upvoted to try to balance it.
Not a partisan decision...
HTML5 isn't even real yet. Standard are still being finalized. Just because of the influx of "HTML5 Apps", that use tiny bit of the just one part of one of the many HTML5 standards, doesn't mean that this thing is done. Let alone HTML5 video.
For all we know, HTML5 video might turn into next years Silverlight.... another stillborn technology. Definitely too early to worry about video CODECs. Plus, CODECs are the most pluggable of any browser software.
I don't know if either WebM or H.264 is going to become the dominant in-browser video tech. Maybe we will still be using player browser plugins in four years. Maybe another CODEC entirely.
Plus, Apple is clearly trying to take video out of the browser entirely, and move it to special player apps, connected to the iTunes universe. They want to sell video content via iTunes. Does Mobile Safari support any sort of video at all? Given that Apple wants to replace most home PCs with iPads, that tells you a lot about the relevance of HTML5 video.
H.264 already is the dominant in-browser video codec. WebM is nothing at the moment. It really is difficult to see it becoming anything at all while Google sits on it's hands and refuses to indemnify anyone against patent liability if they choose to use it. If Google is so damned sure that WebM has no patent risks, why don't they say they'll carry the liability for others using it? (Obvious) answer on a postcard please.
Does Mobile Safari support any sort of video at all?
Yes - H264
Re: Sadly, it will be
The vast majority of such devices are phones and iPads. And even most of those have the processing power necessary to run WebM in software entirely at the resolutions they can produce.
Meanwhile, laptops and desktop computers do not need hardware acceleration for video at all any more, what with multiple core CPUs as they are currently being quite capable of handling that all by themselves even if it's not the most efficient way to go.
Within 2 years, a lot of those mobile phones will have been replaced. If we push WebM hard now, a lot of those phones will probably ship with hardware WebM acceleration, either instead of or in addition to h264 support. In 4 years, the majority of the phones will have WebM acceleration aboard and we can start dropping h264 support entirely. Only those with ancient phones and phones from manufacturers that refused to adapt will be inconvenienced by such.
does it help?
Is there any guarantee that the patents held by the MPEG-LA won't also apply to any future video standard?
Remember these aren't patents on H264 - they are patents on various techniques for compressing video,.
>Though WebM uses a royalty-free license, the MPEG-LA has said it's "looking into" a patent pool that would challenge its royalty-free-ness. And apparently, this jibes with the thinking of Apple CEO Steve Jobs<
Which is why I hope WebM wins.
It looks like it already has
Otherwise they wouldn't have taken this decision, they'd have gone after WebM over patents.
"though Microsoft has said it will allow IE9 netizens to use WebM if they install it on their own machines."
Oh, thank you, that is so gracious of you. You will allow me to use legal software that is installed on MY machine...
So why the sarcasm?
Microsoft is doing the right thing.
If I'm running Windows 7 (as I do from home) I've already paid for h264 anyway, so why won't a browser let me use it? It's right there in the DirectShow framework to be invoked. Not just one implementation either but several since I have Microsoft, DIVX and ffmpeg codecs all sitting there ready and happy to decode h264.
I am glad that Microsoft have wisely chosen to open up their video tag to other codecs. It wouldn't by itself persuade me to use their browser, but it's a step in the right direction.
Well, by itself, it convinces me to use it over Safari. Mind you, I can play H.264 in FIreox just fine with the right plugin, so I'm off the the codec races...
You make a video and put it on the web and make a fortune and MPEG-LA can sue you for the money - unless you can prove you've got a valid production license.
Have you? Can you remember paying out $2500 for one - no then you haven't so your 'Two Grandmas One Denture Sterilising Device' is going to cost you big time.
H264 is not about providing an easy to use Codec - its about making money for its owners.
Licence is paid by manufactureers etc
AIUI, the licence is paid by manufacturers of cameras, software etc so you're fine using the kit you've bought.
If you use WebM or Ogg Theora you just pray they don't violate patents because if they did, Google is not going to indemnify your ass if MPEG-LA come around suing people. In other words, same boat.
Besides which, most people have h264 licenses through one means or another, or don't need one to begin with. Even if it were an issue for some, blocking everyone from using a legally owned, industry standard codec is rather silly. If Mozilla felt so strongly about proprietary extensions, they should disable plugins altogether from the browser rather than let it actively assist people to install Flash, Silverlight etc.
Licensing is more complicated than you think
The licenses paid for by the camera manufacturers are licenses for non-commercial use only; pretty much any camera sold says so if you read the actual licensing agreement it comes with. If you make any money using images you took using that camera, you're violating the license you were given.
The license is paid for by the Manufacturers?
Not for commercial use - that's extra $2500 dollars extra. For each camera, and any softtware that might convert something else so $5k to make your own video, change something in it and stick it in a commercial website.
No the license is paid for by every poor bastard that uses it one way or another. Free? - only if your really stupid.
Um... Everyone seems to conveniently forget a little thing called Blu-ray. It's this funny technology that allows people to watch movies in lots of different places. h.264 isn't going anywhere until Blu-ray is replaced with another technology. And at the rate it took to replace DVDs, it'll be at least another 10 years before h.264 will even begin to die. More likely, we'll have to wait until a new type of TV is developed before it will even be useful to discuss. And no, (non)streaming downloads are not going to replace Blu-ray, though they should eventually marginalize physical technologies.
For all the noise from Google and Mozilla, I have yet to hear of any hardware manufacturer that's actually interested in making chips that can decode WebM. OTOH, chips to decode h.264 already exist and are going to continue to exist for many years.
Even if WebM manages to "win" for some market, such as Internet or mobile, the devices are still going to be supporting h.264 for all the other cases, such as movies made in iTunes.
Existing and future hardware H264 and WebM
Some HW chips out there (most?) are firmware reprogrammable, which means that WebM can be added using a simple firmware upgrade. (If the handset or other device supplier wants to do it)
I know of at least one major manufacturer of chips for mobiles and other devices that already has WebM running on a chip that previously didn't support it. It just needs code. The chip also supports H264 and various other codecs. Other manufacturers will follow suit VERY quickly because it a relatively low cost way of getting an extra tick box on the marketing blurb. (6 man months should do it, if that)
As to Bluray using H264 - so what. People don't care what format is on the disk as long as it plays. Although H264 wont go away in this case, it might end up being the only place its used. To be honest, I transcode all my DVD and stream then anyway....and I dont really care what the format is on the DVD. It's going to go that way.
Not to mention...
... the use of h.264 in DVB-T2 (and possibly other broadcast standards - I'm no expert). So it's going to be in most new TVs for the foreseeable.
"Everyone seems to conveniently forget a little thing called Blu-ray"
Um, nope, Blu-Ray is a Disc Technology. Likewise DVD is a disc Technology and not an encoding format nor a video container format in itself.
WebM can handle H264 easily
WebM uses the VP8 video codec in a Matroska container. Oh and using Vorbis audio codec
The reason Matroska was chosen was so new codecs can be included easily. The Ogg container is interesting, but will die soon because it is very hard to add new codecs
There is no problem at all with WebM containers (Matroska) delivering H264 along with MP3 audio streams. Or H264 with Vorbis streams, or VP8 with MP3 streams, or whatever format you so desire.
Irrespective of the licensing situation WebM is unlikely to die in any realistic timeframe because it has chosen (wisely) a very good and fleixible container format - Matroska.
you seem to be confused...
Matroska is a container format, it allows the use of various codecs. WebM specifies exactly one audio codec and exactly one video codec, No choice = no complexity or confusion. By design.
Just open up the video tag Mozilla
If Mozilla only want to ship with a few rather useless codecs, then fine but the video tag should be opened up to support other video codecs such as h264.
How to do this? Rather easily. A video player is just a specialised class of plugin that plays media. Mozilla can define a framework for NPAPI plugins to declare they handle video and an interface the plugin should implements for content type supports, trickplay etc.
It's not hard and it would allow Mozilla to keep their codebase clean without hobbling their browser. As it stands their solution is useless and doesn't address reality.
You've basically described the <embed> tag
"a very good and fleixible container format - Matroska."
A container shouldn't be needed in the first place. All it does is tell the program whats inside it with a few other odds and sods. Its just the usual software over engineering because someone thought making a program recognise the file type using magic numbers embedded at the start was just too easy so something more complicated was required.
Containers contains streams of data + other stuff. They provide a level of indirection that does give benefits over a simple stream. You can add chapter stuff for example. They also save on code because you only need to write code once for a container type, and once for the stream type. If each stream type had its own implementation of the data currently stored in containers, you would need to write container like parsing code for EACH stream type. Which would be a PITA.
>All it does is tell the program whats inside it with a few other odds and sods
Yes, you clearly know nothing about audio/video. Ever heard of muxing before? Have any handy solutions to place audio and video inside one file while keeping it synced? How about for live broadcast where the start of the video isn't available, where does one get their 'magic numbers' (lots of container formats cannot handle this properly)?
Matroska is a great container format compared to most and I'm glad that webm has decided to use it for their implementation.
How else would you fit in subtitles (if you need them, you might not), 2.0 or 5.1 soundtracks (if you need them, you might not), different language tracks (if you need them, you might not), etc...?
Magic numbers me arse
Propose a format for these magic numbers of yours. A format that can store multiple streams, streams of various bandwidths, streams which must be time synchronized, streams holding arbitrary data, all stored in a file which may not have the luxury of file seeks, or even a start or an end due it being delivered sequentially.
Assuming you bother to address these issues, you will have described a container. It's not just a matter of a few magic numbers on the file. Each stream has to be uniquely identified, each stream contains arbitrary data, each stream delivers data at different rates. It is the container's job to manage all that.
Containers are a necessity and some (especially AVI) have even been hacked because of their limitations. The reason MKV is gaining traction is because it doesn't suffer many of the artificial limitations of other containers. It has been built from the ground up as an open standard. It doesn't mean some random app that reads MKV can actually do anything with the data, but it's a damned better format than most of the others floating around.
Seems a simple choice to me
WebM is the only choice, HTML is an open standard, WebM is an open codec.
H264 comes with no future promises.
We need a codec that will evolve and stay open and free.
All the crap about device support is pointless, this isn't a decision based on downloaded video, this is about streaming, and when WebM is chosen as the HTML5 codec chips will be made.
As for Apple products, no problem, the upgrade cycle is short enough that the new chips can be in the next gen devices before wide adoption. :p
For all of you who think containers are so essential...
..ask youself how .wav or .au or .mpg files were played 20 years ago. They didn't have containers and they worked just fine. As for magic numbers - they're already a standard so get yourselves a clue and go read this:
.wav and .mpg are container formats.
20 years ago,
.wav and .au files were single-stream audio-only files -- no video. (They were also huge and low-quality, but that's another argument.)
The MPEG-1 standard wasn't finished until 18 years ago, but I'll call that close enough. It actually includes one of those container formats you seem to hate so much. While it has a single program stream, that stream is a container built from one or more separate elementary streams interleaved using a form of time-division multiplexing. Each of those elementary streams is its own standard format, and can exist outside of an MPEG-1 container (MPEG layer 3 Audio (.mp3) is the best example of this.) So while you can have audio- or video-only MPEG-1 files, once you combine two or more streams (and what is video without audio? ; ), you also have to include the program stream, the container format.
In general, whenever you have two or more data streams that have to be synchronized, you need some container format to manage that synchronization. So, yes, containers are essential when you're doing video with audio. Now, if you think the talkies ruined the film industry, I won't argue with you, that's another discussion for another forum.
What no one seems to be concerned about is that for anyone who wants to pump out some home videos on their website or on youtube they will be safe from the MPEG-LA vampires when they encode with H264, but if they set up their own website to deliver their home movies and charge for them; they will need a license, an expensive license. You may think that this will not affect you in the slightest -- until your snazzy website and it's H264 videos bag you some advertising cash and then you will have provided H264 video and received remuneration for that delivery. MPEG-LA says Money Please.
If the open-source aspect of WebM is unshakeable in terms of attack from patent pools then it will survive and flourish. Stubborn device and software makers will ensure the future of H264.
At least you won't need Flash
I think just about everyone commenting here will agree that the flash player for H-264 video sucks!
Unreliable, insecure, crashes early and often.
Integrated non-flash players such as demonstrated at http://en.wikipedia.org/wiki/Theora are the way to go.
standards & embedded chips
So, regarding some battle between H.264 and WebM -- as far as I'm concerned, as long as the browsers have some sort of video tag plugin, I just don't care about their politics. I mean, I'd prefer WebM to win, but the reality is that I also want to be able to watch videos whether they use a proper format or not. In reality, though, I don't know if either will displace Flash -- for stuff like TV show and movie streaming, they are so paranoid, and are using increasingly complex rights restrictions (to try to prevent stream ripping), I don't see them giving it up to go to a straight Video tag.
Regarding embedded chips, those who way they won't support WebM are probably mistaken. These chips don't decode MPEG2 or H.264 -- that is, you don't thrown in a raw MPEG2 or H.264 stream in and get video frames out -- they accelerate particular steps like iDCT and motion compenstation. So if WebM uses motion compensation (for instance) at all, the chip can still accelerate it. Also, a lot of these are general-purpose chips and are reprogrammable.
just a "sync file" could do the job of syncing two, trhee, ten or more streams really you have the video, the audio , the subtitle and a file telling you the syncing info, you could even index the subtitles or other text streams, think finding the rigth spot in the news...
2 cents a dance
>>if they set up their own website to deliver their home movies and charge for them; they will need a license, an expensive license. <<
The H.264 royalty on retail sales is 2% of the retail price or 2 cents a disk or download, whichever is lower.
MPEG LA thinks commercial scale.
Call them after you manage to sell 100,000 copies of your feature length Trek Wars fan flick and have a check for $2,000 ready to deliver.
There are no royalties on video subscription services when your subscriber list is less than 100,000.
2% of the retail proce per unit does not equate to $0.02, unless of course each unit retails for $1.00, unlikely.
Thats 2 cents more than it should be
why does everyone in the web thing its ok to take money of people merely for providing a 'service' that anyone else could and getting in everyone's way?
Free open standards for the WEB - nothing else thanks.
If you cant provide a real service get out of everyone else's way.