Quote:
Originally Posted by
AppleInsider 
... standard doesn't need to specify an official codec. There's no official codec for graphics; web developers can use JPEG, GIF, PNG, or any other format. If users can't see the image, they might need to load a helper plugin. There is no problem related to lacking an official graphics format.
This is the most important point of the article. If browsers support a generalized video/audio OS infrastructure, then there is no longer a need to support anything directly in the browser.
For instance, every Windows box supports a boatload of audio and video codecs via the standard multimedia APIs (which Media Player wraps around.) And if anything is missing, new codecs can be installed into the OS, where all apps can see and use them.
Similarly, every Mac has a boatload of codecs via its multimedia APIs (which tie to the underlying Quicktime infrastructure.) Similarly, new codecs can be added to the OS, and applications will then be able to use them.
I don't know what the deal is with Linux, but if there isn't a similar multimedia architecture, somebody really should develop one.
With a browser designed to use OS-standard multimedia APIs, the whole argument becomes moot. Firefox no longer has to pay license fees for its codecs, it will just use what the OS provides.
And, of course, this in no way removes the possibility of using a plugin to provide something that is otherwise unavailable - and this doesn't break use of <video>. Just like third party Java plugins can tap the <applet> tag and not need to use <embed>, so can audio and video plugins.
Quote:
Originally Posted by
HoserHead 
H.264 is equally vulnerable to submarine patents. If someone has a patent on something in H.264, companies that use it can be sued.
Of course, but if someone tries attacking H.264, they also attack some of the biggest players in the business, like Sony and Disney (since H.264 is what Blu-Ray uses.)
Theora doesn't have any such big-muscled supporters.
Quote:
Originally Posted by
melchior 
the solution of installing plugins leaves exactly where we are today and what the "<video>" tag is trying to solve.
Not
exactly the same.
A video-specific plugin that provides a codec for a generalized player is easier to implement and use than an <embed> object that provides the entire player. The video-plugin can be ignored by content providers - they just provide content in a given format and let the browser decide which plugin to use (or to use none, if it's supported internally). Using <embeds>, the content provider usually needs to know all kinds of ugly details about the player and the plugin that provides it.
It also means the user doesn't have to learn several different user interfaces for the videos, since the plugin only has to provide the codec, not the entire player.
Quote:
Originally Posted by
bbwi 
Just like Bluray won over night, so will OGG!
That's really amusing, since Blu-Ray uses H.264 for its content.
And BD hardly won "overnight". It was a long struggle, backed (both politically and financially) by some very large mega-corporations.
Quote:
Originally Posted by
ascii 
Leave the codec unspecified, as with the IMG tag. This will enable competition and encourage continued innovation. If they fix on one format only, then vendors will simply implement that and be done with it, and no pressure on them to keep innovating.
Bingo! Exactly like how it is with <img> tags. Today, browsers have support for PNG, but dropped XPM (which was in some of the oldest browsers.) This happens based on what people want/need, without fanfare and without most people even noticing.
HTML 5's <video> and <audio> tags sets up the much-needed infrastructure for this to happen, but we really don't want it to go beyond that.
Where would the web be if the HTML standards mandated all images be in XPM format, simply because it was open and popular at the time of the first browsers? Similarly, we don't want it to mandate any audio or video formats - what we're using today will certainly be obsoleted by other formats in the future, and browser developers shouldn't be forced to violate standards in order to support them.