Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Media The Internet IT

Browser Vendors Force W3C To Scrap HTML 5 Codecs 640

snydeq writes "Major browser vendors have been unable to agree on an encoding format they will support in their products, forcing the W3C to drop audio and video codecs from HTML 5, the forthcoming W3C spec that has been viewed as a threat to Flash, Silverlight, and similar technologies. 'After an inordinate amount of discussions on the situation, I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship,' HTML 5 editor Ian Hickson wrote to the whatwg mailing list. Apple, for its part, won't support Ogg Theora in QuickTime, expressing concerns over patents despite the fact that the codec can be used royalty-free. Opera and Mozilla oppose using H.264 due to licensing and distribution issues. Google has similar reservations, despite already using H.264 and Ogg Theora in Chrome. Microsoft has made no commitment to support <video>."
This discussion has been archived. No new comments can be posted.

Browser Vendors Force W3C To Scrap HTML 5 Codecs

Comments Filter:
  • by ditoa ( 952847 ) on Thursday July 02, 2009 @02:06PM (#28562189)

    Perhaps it is a stupid question but why do the vendors have a say what goes into the spec and what doesn't? Isn't it up to them to choose to implement the spec fully or not? FFS just make it Ogg Vorbis/Theora and if Apple doesn't want to support it then Safari can just not support that part of the spec. It isn't like any of the browser are 100% complient anyway.

    • by hansraj ( 458504 ) on Thursday July 02, 2009 @02:12PM (#28562283)

      Perhaps because there is no point having a standard if no one is willing to adopt it.

      • Re: (Score:3, Informative)

        by ditoa ( 952847 )

        But Mozilla already have supported it with Firefox 3.5??

      • Re: (Score:3, Insightful)

        by nine-times ( 778537 )

        Sometimes you put something into a standard as a way of pressuring people to adopt something. Make it the standard, and if Apple won't adopt it, make a big stink about how Safari isn't really HTML5 compliant.

        I suspect that the problem is that companies like Apple, Microsoft, and Adobe have enough influence on the W3C to kill something like this.

        • by beelsebob ( 529313 ) on Thursday July 02, 2009 @04:39PM (#28564819)

          The problem is not that apple won't adopt it, it's that apple *can't* adopt it, and nor can nokia, and nor can sony erricson, and nor can RIM, and nor can any of the other smart phone makers. There is *no* hardware support for decoding Ogg Theora, that makes it totally unsuitable for the task at hand. Even ignoring the submarine patent risk and the fact that it's far worse quality than h.264.

        • Re: (Score:3, Interesting)

          by Simetrical ( 1047518 )

          I suspect that the problem is that companies like Apple, Microsoft, and Adobe have enough influence on the W3C to kill something like this.

          The W3C is irrelevant. The WHATWG didn't start out as part of the W3C, and if the W3C tried to push it around it could just break off again. The contents of the HTML 5 spec are determined solely by Ian Hickson, currently employed by Google. His only oversight is a steering committee. I can't find who's on the steering committee, but I'm very certain that it includes no one from Microsoft or Adobe, and Mozilla plus Opera almost certainly have more votes than Apple.

          The fact is, the HTML 5 standard is no

    • by Radhruin ( 875377 ) on Thursday July 02, 2009 @02:12PM (#28562287)
      The stated reason is that, if vendors will refuse to implement a portion of the spec, that part shouldn't be in the spec. The spec isn't supposed to force vendors to implement something, it's supposed to be a common set of rules that everyone can follow, and mandating Theora is counter to that goal.
      • by causality ( 777677 ) on Thursday July 02, 2009 @02:44PM (#28562983)

        The stated reason is that, if vendors will refuse to implement a portion of the spec, that part shouldn't be in the spec. The spec isn't supposed to force vendors to implement something, it's supposed to be a common set of rules that everyone can follow, and mandating Theora is counter to that goal.

        Sure, but there needs to be a way to distinguish between:

        • A) refusing to implement because there are sound engineering reasons not to do so
        • B) refusing to implement because doing so would make it harder for a company to lock people into proprietary formats

        No standards body worthy of the slightest respect should ever concern itself with that second category.

        I am not fond of putting it this way, but I think what really needs to happen is for the average user to grow a pair and realize why Item B is not in their interests and never will be. So long as the masses of users have no understanding of these things, it is always going to be an uphill battle to maintain an Internet that is as free and open as possible.

    • If no browser will support the codecs then webmasters wont use html 5 and stick with html4. When IE owned a significant marketshare a couple of years ago the web evolution slowed down to a halt. Firefox can't adopt H.264 because its patented and Firefox can be shutdown if a lawsuit over infringement takes place.

      And Firefox does not have a significant enough marketshare for developers to care about Ogg Vorbis/Theora. Besides all the professional tools do not support it so it wont ever be used. It wont ever b

      • by TheRaven64 ( 641858 ) on Thursday July 02, 2009 @02:41PM (#28562917) Journal

        Besides all the professional tools do not support it so it wont ever be used

        Which professional tools are these? Most video editing software I've seen uses either QuickTime or Windows Media for exporting, and both of these have (free) plugins for encoding Theora (and Dirac). You wouldn't want to use Theora as an intermediate format - something like MJPEG or Pixlet with no inter-frame compression is better for that - but exporting from most tools is pretty trivial.

      • Re: (Score:3, Insightful)

        by horza ( 87255 )

        Besides all the professional tools do not support it so it wont ever be used. It wont ever be used because professional tools do not support. Its a catch-22 just like Microsoft Windows and Office. You can't ever leave the platform.

        Like Microsoft said they wouldn't support ODT, throwing their weight behind OOXML instead?

        Transcoding to any format shouldn't be a problem these days, ESPECIALLY one with an open spec, so there is no reason for a tool not to support Ogg.

        Phillip.

    • Re: (Score:3, Interesting)

      by phantomfive ( 622387 )
      In most cases, the purpose of a standards organization is not to be the supreme commander and dictate what everyone has to do, it's purpose is to be the consensus builder and find a compromise that everyone can agree on.......at least agree on enough to implement it. The web browser writers hold the most power in this case because if the standard doesn't get implemented by the majority of web browsers, then it is irrelevant. W3C has to keep this in mind at all times, otherwise they will fail at what they
    • Re: (Score:3, Insightful)

      by WarJolt ( 990309 )

      It isn't like any of the browser are 100% complient anyway.

      That is the excuse Microsoft used to set back open web standards years with IE. Two wrongs don't make a right.

  • Apple's concern (Score:5, Insightful)

    by commodoresloat ( 172735 ) * on Thursday July 02, 2009 @02:07PM (#28562195)

    Apple, for its part, won't support Ogg Theora in QuickTime, expressing concerns over patents despite the fact that the codec can be used royalty-free.

    Or perhaps their concern is precisely because of this fact?

    • Re:Apple's concern (Score:5, Informative)

      by Radhruin ( 875377 ) on Thursday July 02, 2009 @02:14PM (#28562313)
      Apple also doesn't want to support anything doesn't have off-the-shelf hardware acceleration. Until Apple can buy chips to decode Theora that will work in the iPhone, Theora is a no go for them.
    • Re:Apple's concern (Score:5, Interesting)

      by Microlith ( 54737 ) on Thursday July 02, 2009 @02:15PM (#28562353)

      No, if something being royalty-free were a downside they would not have included a BSD userspace with OS X. While Ogg Theora is royalty free, there are no -known- patent violations. As I recall back when Vorbis was getting off the ground, the implication was made that people with patents wouldn't care unless it got off the ground and then they would start looking for violations.

      Basically, Theora and Vorbis are huge unknowns with potential patent bombs in them, regardless of what the developers and /. thinks. And all it takes is someone with a patent and the muster to enforce it and everyone who implemented them in their browser suddenly has a huge problem.

      • Re:Apple's concern (Score:4, Interesting)

        by StormReaver ( 59959 ) on Thursday July 02, 2009 @02:43PM (#28562975)

        > While Ogg Theora is royalty free, there are no -known- patent violations.

        The exact same argument can be made for the BSD base Apple uses for OSX. It doesn't matter that BSD went through a long copyright case way back when; both because that case was about copyrights rather than patents, and because unknown patent violations can easily have crept into the code base since then. In fact, I can safely go out on a limb and guarantee that every non-trivial piece of software (including everything Apple has) is violating software patents. Software patents are handed out by the USPTO like Bibles are handed out in prison.

        Apple's argument that they won't use Theora because of potential patent problems rings completely hollow. I'm not going to speculate on their motives, but the one they gave is nonsense.

      • Re:Apple's concern (Score:5, Insightful)

        by TheRaven64 ( 641858 ) on Thursday July 02, 2009 @02:45PM (#28563009) Journal

        Theora is a bit different from Ogg in this respect. Theora is based on VP3, which was both patented and commercially distributed for a number of years. If VP3 had been infringing someone else's patents, then they would likely have sued back when a company was making money from it. The patents that were required to VP3 were released by On2 under a free, irrevocable, license and then (I believe) allowed to lapse.

        Dirac is in a weaker position; it is believed to be patent free, but no one has done a patent search to make sure and it is not based on an existing codec.

      • Re:Apple's concern (Score:5, Insightful)

        by Binary Boy ( 2407 ) on Thursday July 02, 2009 @02:45PM (#28563023)

        Absolutely - the notion of "submarine patents" rising up, should Theora take off, is not a new idea, and not specific to Apple. By mandating Theora in HTML5, you'd be risking the years of negotiations on the spec on the bet that there are no such patents - a bet I'd be surprised if any good Slashdot reader would take.

        As others have pointed out, HTML has never mandated a specific image format reference in an IMG tag; a type of plugin referenced in OBJECT or EMBED; or the type of resource referenced in an A tag; it's outside it's scope. Let the standard focus on its scope, and let the market hash out the rest - it's not the end of the world to not have a single, mandated codec - in fact, I'd argue that having such a thing would unnecessarily limit our options - Theora is, to be kind, not the most efficient codec on the market; and the situation will likely only get worse. Don't hamstring HTML5 by hitching it to any particular codec.

      • Re:Apple's concern (Score:4, Insightful)

        by Daniel_Staal ( 609844 ) <DStaal@usa.net> on Thursday July 02, 2009 @02:58PM (#28563261)

        Exactly. I hear 'royalty free' and I think of GIF, which was also royalty free... Until it wasn't. Which was an absolutely huge mess.

        Honestly, if I were Apple and the Theora foundation offered a $100-per-million-device license saying basically 'we swear we are the sole authority on Ogg Theora, and you have a license from us to implement it to the spec' I'd be much happier than without it. Because then I'd have a set contract, spelling out the cost, and that if someone then comes along and says 'wait, we own this part of the spec, and you owe us $Xbillion' I could turn around to the Theora foundation and say 'Your breach of contract just cost me $Xbillion, and I expect you to pay that.' Basically, at that point the risk is Theora's, and not Apple's.

        Apple is unwilling to take the risk that there are IP problems with the spec. It would take a lot of costly research and examinations for them to prove there aren't any, and there is no real benefit to them to spend the money and time. Translation: At free, it costs to much.

    • by Futurepower(R) ( 558542 ) on Thursday July 02, 2009 @02:19PM (#28562459) Homepage
      My understanding is that Apple doesn't want to work on QuickTime because it is buggy and no one wants to fix it.
  • Apple? (Score:4, Interesting)

    by ichthus ( 72442 ) on Thursday July 02, 2009 @02:08PM (#28562227) Homepage
    What's with Apple? They had no problem paying Sorenson Media in the past. What, specifically, is wrong with Theora?
    • Simple (Score:4, Informative)

      by Benanov ( 583592 ) <brian,kemp&member,fsf,org> on Thursday July 02, 2009 @02:17PM (#28562401) Journal

      They don't know who to pay.

  • by Millennium ( 2451 ) on Thursday July 02, 2009 @02:15PM (#28562339)

    So not counting Microsoft (which has had nothing to say on the matter, and therefore cannot be counted one way or another), the only party blocking this is Apple, and they're blocking it based solely on a trumped-up and prima facie invalid argument, and furthermore, an argument that has never once impeded any of Apple's past actions. In other words, "BAWWWWW they din pik my pet codec BAWWWWW i wants every1 usin only my codec BAWWWWW BAWWWWW BAWWWWW!"

    Seriously, folks; QuickTime uses a plug-in architecture for a reason. If Apple were truly concerned about Theora and patents, all they'd need to do is implement it as a plug-in -something they should have absolutely no trouble doing, as it's their own architecture- which could then be trivially removed if the need ever arose. But no; this is a step back towards the bad old days of Not-Invented-Here syndrome at Apple.

    • Re: (Score:3, Insightful)

      by DECS ( 891519 )

      Perhaps you're not aware that there are already Ogg+Theora etc plugins for QuickTime, and that anyone can install them for free.

      Some of the reasons Apple has no interest in using FOSS codecs are:

      - Codecs are bleeding edge technology, and FOSS is typically behind the curve (as Theora is)
      - Codec algorithms are patented to high heaven and impossibly difficult to vet for patent submarines.
      - Nobody sues FOSS until a monied company adopts it. Apple doesn't want to be the target.
      - There is already a technically su

    • by ray_mccrae ( 78654 ) on Thursday July 02, 2009 @03:08PM (#28563437)

      Except it isn't just Apple blocking it. Nokia also sided against Ogg Theora, but then I guess that wouldn't be sensationalist enough for the /. crowd.
      Neither is h.264 Apple's codec. apart from patents apples only other contribution was to give the MPEG group the MOV container for use as the MP4 container file format.

  • by Pentium100 ( 1240090 ) on Thursday July 02, 2009 @02:18PM (#28562437)

    How about making the browser use system (DirectShow on Windows, whatever-it's-called on Linux) codecs, so everybody could be using whatever codec they want. Look, a lot of media players on Windows (like WMP and MPC) use DirectShow, so thew users can install additional codecs.

    Why they want to include the codecs in the browsers. This way is worse. If system codecs were used, then the sites could choose whether to use h.264, ogg or some other codec, like XviD.

    Also, this way all of the patent/license/whatever issues for the browser vendors would go away. And if the users are watching video files on their computers they most likely have codecs already installed.

    • by malevolentjelly ( 1057140 ) on Thursday July 02, 2009 @02:33PM (#28562779) Journal

      You're right on a technical level, you really are. But wouldn't that make playing video on the web more like it was in the web 1.0 era? People would have to stay on top of codecs and go surf for these sorts of things. I believe flash won out originally because it was a seamless solution for the end users-- one plugin to rule them all.

      Honestly, the solution you're suggesting is not unlike the way Silverlight/Moonlight handles media-- except that it does have a default/preferred codec.

      Why, you could circumvent the lack of a video tag on IE (or anything else) by using the pluggable codec support in Silverlight 3 to provide a Theora codec. ;) And that won't require any proprietary tools and very little code- just (if the browser is IE, load the following silverlight control, point it to the codec and your theora video)

      We might as well just keep using the object tag to embed media files and let the system figure out what's supposed to run it, if we're going to use system codecs. On Windows, WMP will do it, on Linux, mplayer (or gstreamer if the user is a sadomasochist), and on mac it will be Quicktime. I mean, it's progressive, in an absolutely regressive sort of way.

    • Re: (Score:3, Interesting)

      by BZ ( 40346 )
  • The real reasons... (Score:5, Interesting)

    by jonnyj ( 1011131 ) on Thursday July 02, 2009 @02:26PM (#28562595)

    Vendors never actually mean what they say. Here are the real reasons:

    Apple won't support a codec that's incompatible with its huge installed base of ipods and iphones. They don't care about royalty fees because most Safari users pay for an OS X licence, and they want the free browsers to look sub-par compared with theirs.

    Microsoft won't support a codec that makes the web more reliable for non-Windows users - especially Linux users. They don't care about royalty fees because all IE users pay for a WIndows licence, and they want the free browsers to look sub-par compared with theirs.

    Google, Opera and Mozilla won't support anything that puts them at risk of needing to pay royalties on the huge number of free downloads they give away.

    Nobody actually cares about end users or developers. If you think they do, you're kidding yourself.

    • Re: (Score:3, Insightful)

      True, most of them probably don't care much about users. However, the stance of Apple and Microsoft in your post clearly is clearly negative for developers and users because it locks everybody into paying them. Google, Opera, and Mozilla, while they don't necessarily actively HELP users, they're not actively hurting them either.

      I'm not normally the 'rah rah open source' type, but the way you present that, one of the choices is clearly better.

      All that said, I think it's just fine to remove codecs from the

    • Re: (Score:3, Insightful)

      by BZ ( 40346 )

      > Google, Opera and Mozilla won't support anything that puts them at risk of needing to pay
      > royalties on the huge number of free downloads they give away.

      That statement is hard to reconcile with the fact that Google is shipping H.264 support in chrome.

      That discrepancy is easy to account for by noting that the MPEG-LA licensing terms for H.264 (see http://www.mpegla.com/avc/AVC_TermsSummary.pdf [mpegla.com] ) have a cap on royalty payments. Looking at the rates there, anything over 10 million shipping units is ef

  • by SuperKendall ( 25149 ) on Thursday July 02, 2009 @02:31PM (#28562737)

    You can still make use of the tag in a cross platform way. Video For Everybody [camendesign.com] Is a simple set of code that uses the video tag with only two input files - an ogg and an mp4 - and lets the tag work for, well, everyone. IE6? Check. Safari? Check. iPhone? Yep.

    It falls back to whatever method works for playback - including using Flash to play the h.264 if it needs to.

    It's pretty funny to see so many people bitching about Apple not supporting ogg when Microsoft ignores the tag altogether. Everyone, start supporting the video tag today as widespread use is the only way to get big companies to fully adopt it - perhaps that will motivate Apple to someday support ogg.

  • by Animats ( 122034 ) on Thursday July 02, 2009 @03:29PM (#28563805) Homepage

    What we really need in HTML standarization:

    • Valid XML, all the time. Require that the tags balance, as in XHTML. This will make the document tree well-defined, which, at the moment, it is not. So all software that works on the DOM will behave consistently.
    • Errors put the browser in "dumb rendering" mode. Rather than a "best effort" approach, browsers should, upon detecting a serious error in the input, drop to "dumb mode" - default font, default colors, etc., after displaying an error message. Much of the incompatibility between browsers comes from inconsistent handling of bad HTML. So there should be a penalty, but not a fatal one, for bad code.
    • No more upper code pages. The only valid character sets should be Unicode, or ASCII with HTML escapes. Chars above 127 in ASCII mode are to be rendered as a black dot or square. No more "Latin-1", or the pre-Unicode encodings of Han or Korean. So all pages will render in all browsers, provided only that they have some full Unicode font.
    • Downloadable fonts. Netscape used to have downloadable fonts. The font makers bitched. Bring that feature back, despite the whining. No more having to express fonts as images.
    • WebForms. Get the WebForms proposal back on track. Any needed processing for input should be do-able without Javascript.
    • 2D layout The "div"/"clear" model of layout was a flop. Horrors of Javascript are needed just to make columns balance. Absolute positioning is overused as a workaround for the limits of "div"/"clear". (Text on top of text happens all too often.) Tables were actually a better layout tool, because they're a 2D system. HTML needs a 2D layout model that can't accidentally result in overlaps. There are plenty of those around; most window managers have one. There's been a quiet move back to tables for layout, but people are embarrassed to admit it.
    • Better parallelism. Pages must do their initial render without "document.write()". Forcing sequentiality during initial page load should be considered an error. This will make pages load faster. Some ad code will have to be rewritten.
    • by Phroggy ( 441 ) <slashdot3NO@SPAMphroggy.com> on Thursday July 02, 2009 @05:04PM (#28565173) Homepage

      Valid XML, all the time. Require that the tags balance, as in XHTML. This will make the document tree well-defined, which, at the moment, it is not. So all software that works on the DOM will behave consistently.

      You're wrong. The document tree is well-defined in HTML 5. You don't need XML, you just need to follow the HTML spec. Of course, we can't force people to follow the spec, and the Web is currently full of non-conforming pages that include half-assed attempts at using bits and pieces of XHTML mixed with HTML. XHTML doesn't make anything better.

      Errors put the browser in "dumb rendering" mode. Rather than a "best effort" approach, browsers should, upon detecting a serious error in the input, drop to "dumb mode" - default font, default colors, etc., after displaying an error message. Much of the incompatibility between browsers comes from inconsistent handling of bad HTML. So there should be a penalty, but not a fatal one, for bad code.

      You're wrong. If your browser does this, users will use some other browser (regardless of whether it conforms to the HTML5 spec or not, because users don't care about that). You're right that broken code is a problem, but HTML5 addresses this by more clearly defining how broken code should be handled, so that all browsers can try to render even bad code in a consistent and compatible way.

      No more upper code pages. The only valid character sets should be Unicode, or ASCII with HTML escapes. Chars above 127 in ASCII mode are to be rendered as a black dot or square. No more "Latin-1", or the pre-Unicode encodings of Han or Korean. So all pages will render in all browsers, provided only that they have some full Unicode font.

      You're wrong. If you make a browser that doesn't support these other character sets, users will choose something else (see above). Of course everybody should be using UTF-8 these days, but we can't force them to.

      Downloadable fonts. Netscape used to have downloadable fonts. The font makers bitched. Bring that feature back, despite the whining. No more having to express fonts as images.

      It's back [alistapart.com], but in CSS, not HTML.

      WebForms. Get the WebForms proposal back on track. Any needed processing for input should be do-able without Javascript.

      HTML5 includes Web Forms 2.

      2D layout The "div"/"clear" model of layout was a flop. Horrors of Javascript are needed just to make columns balance. Absolute positioning is overused as a workaround for the limits of "div"/"clear". (Text on top of text happens all too often.) Tables were actually a better layout tool, because they're a 2D system. HTML needs a 2D layout model that can't accidentally result in overlaps. There are plenty of those around; most window managers have one. There's been a quiet move back to tables for layout, but people are embarrassed to admit it.

      CSS layout has some problems. Balanced columns is certainly one of them (although tables certainly doesn't fix that). They're working on it, but this can be addressed by improving CSS, outside of HTML.

      Better parallelism. Pages must do their initial render without "document.write()". Forcing sequentiality during initial page load should be considered an error. This will make pages load faster. Some ad code will have to be rewritten.

      I'm not sure what you're talking about exactly, but this sounds like a JavaScript implementation issue and not an HTML issue at all.

  • by gig ( 78408 ) on Thursday July 02, 2009 @04:45PM (#28564909)

    Audio video codecs are outside the scope of HTML. Whatever it says in the HTML 5 spec about video codecs, that will not magically change the last 20 years of digital audio video away from MPEG to something else.

    The current audio video standard is ISO MPEG-4 (2001) and the codecs are H.264/AAC. Supporting this standard is not an academic issue because the world is full of content as well as hardware and software players and authoring tools that conform to this standard. It's also the video in Flash and in YouTube, which is considered the de facto standard in "Web video". When people talk about Web video they usually mean YouTube or something very like it. They are talking about MPEG-4.

    The MPEG-4 content that you find in the world and on the Web today includes:

    - every song ever offered for sale in or purchased from iTunes Store
    - every song ripped from a CD by iTunes since 2002
    - every video ever made on a cell phone (3GPP is part of MPEG-4) including the iPhone's recent shoot, edit, upload to YouTube feature which is H.264/AAC
    - every video on YouTube is stored as MPEG-4 (no matter what format you originally uploaded)
    - almost all of the video that runs in Adobe Flash, excluding 320x240 movies which may be the old codec
    - all of the consumer video shot on solid state storage, and most of it from a few years before that
    - all Podcast video is H.264 and most Podcast audio is AAC
    - Blu-Ray

    Nobody has explained how all of this content would be transcoded to Ogg or other non-standard format in order to be published on the Web. Where would the computing time come from? How would it be practically done? What are you going to tell someone who wants to upload a video from their camera or phone directly to the Web? That they should transcode it into a non-standard audio video codec first?

    The players are very important also, because they have H.264/AAC decoding HARDWARE, which enables them to work efficiently enough to run on batteries. You can't drop a new software codec into these, you have to drop in a replacement audio video decoder chip. These include:

    - every iPod and all of their competitors, except for the ones that only play MP3 which is part of MPEG-2
    - every PC with a recent NVIDIA GPU can decode H.264/AAC without breaking a sweat or busting its batteries because it happens in the GPU
    - Internet set-top boxes such as AppleTV and Netflix
    - PlayStation3 and other game boxes
    - even the Zune has MPEG-4 hardware in it, although somewhat underutilized from what I hear

    Even software players cannot so easily be modified to support a non-standard codec, because of the scope of the MPEG-4 support. We're talking about every Mac and every PC in the world, because they all have one or both of these:

    - every QuickTime/iTunes since 2002 is MPEG-4
    - every Adobe FlashPlayer version 9 or 10 is MPEG-4

    The reason those 2 match both each other and all the hardware players is because of the benefits of standardization, which took place almost a decade ago for MPEG-4 and goes back further to previous MPEG versions. If you, or Mozilla, or anyone, wants to make an audio video player, they only need to conform to the MPEG-4 standard to enable their player to play all of the content from QuickTime/iTunes and Flash. You can come along in 2009 and decide to get your feet wet in audio video players and simply by following a published ISO specification you can have instant equality with QuickTime and Flash and others. Again, the benefit of standardization.

    A very important consideration that is often completely ignored by Web-centric people as they talk about audio video is the authoring tools! People who make audio and video all day long also want to publish their work on the Web. MPEG-4 is standardized QuickTime, so there is not just 8 years of MPEG-4 authoring tools right now, there is almost 18 years of digital audio video practice realized in MPEG-4. A key feature here is that these tools must not make content that has a "content tax" on it, like

Real programmers don't comment their code. It was hard to write, it should be hard to understand.

Working...