Originally Posted by nht
Exactly, so what? The point is that the IP for webkit is based on copyright protection so the fact that WebKit is open source doesn't really support his position all that much vis a vis patent protections.
WebKit itself doesn't decode <video> tags on its own, so the video patent licenses don't come into play at all. It passes it down to another layer.
In Safari, it passes <video> tags down to QuickTime. In Google Chrome, it passes <video> tags down to a private copy of ffmpeg statically compiled into the browser binary. In the open-source alternative Google Chromium, it also passes <video> tags down to ffmgeg, but by default it filters out H.264 content and discards it to avoid incurring patent trouble.
True. The major browser makers may/will have to pay a fee. On the other hand, unless Google will indemnify you from patent suits then VP8 is probably more risky an alternative. Note that while Google will claim it's unencumbered it isn't offering indemnity unless I missed something recently.
They have an interesting strategy -- if anybody files suit against anybody else for the use of patented technology within VP8, then Google will revoke that person's license to use any other related, Google-owned patents. I said a while ago that I was curious whether or not Google owned any patents that could be related to both VP8 and H.264 -- if they do, then they could use that as ammunition.
Then you download the proprietary h.264 plugin from Mozilla's site just like you do for a gazillion other useful plugins for firefox.
Mozilla seems to be of the opinion that, because the <video> tag is pure HTML5 markup, it should be possible to render it in-browser without the aid of any external code. They view the need to load plugins to display video as a "bad thing", and therefore they consider this <video> tag to be a good opportunity to start the process of getting rid of such plug-ins.
Personally, I think there's nothing wrong with the idea of providing an extensible library of video codecs, with the ability for the user to add on extra codecs as time goes by, such as MS will be doing in IE9, provided proper provisions can be put in place ensure consistent compatibility and behaviour. (Hint: Apple, do the same with Safari!!!) But there should still be a base implementation that is guaranteed to work in any browser regardless of the presence or absence of 3rd party plugins. And it oughn't be patent-encumbered.