Re: [whatwg] The issue of interoperability of the video element
Dave Singer wrote:snip Lastly, I feel a little hurt that Apple is being so attacked when we take great efforts to develop, implement, promote, and interoperate open systems and specifications, while there are others in the industry who make no such efforts. Could the rhetoric against us be toned down a little, please? I have followed this thread through all its ravelings, and have seen no attacks on Apple (and those more on the decisions than on the company), other than on this particular issue. Is that so unwarranted? It is certain that MSFT has more to be railed against, but the general feeling is that there is a greater than zero chance that Apple would listen and respond positively. Not so with that other guy. I'm just one of the grunts in the trenches, trying to produce web pages that are usable and accessible. I want and need ubiquitous audio and video technologies. That means for general use Real and wmv are out. MPEG4 has serious baggage. At the moment, we're left with ogg theora/vorbis for the minimum supported format. The submarine patents are a red herring. As with gif and mp3, there are/will be alternatives if the sub breaches. Deal with it if and when it happens, as we've done before. As an aside to the lawyers, couldn't adverse possession be invoked in the case of hidden patents? cheers, gary -- Anyone can make a usable web site. It takes a graphic designer to make it slow, confusing and painful to use.
Re: [whatwg] The issue of interoperability of the video element
Nicholas Shanks schrieb: Browsers don't (and shouldn't) include their own av decoders anyway. Codec support is an operating system issue, and any browser installed on my computer supports exactly the same set of codecs, which are the ones made available via the OS (QuickTime APIs in my case, Windows Media APIs on Bill's platform, and from the sounds of it, libavcodec on the Penguin) Browsers should ship with their own decoders (at least one set) because depending on what platform you are the choice of codecs that are installed varies greatly and as a content producer you have no idea what the clients can decode in that scenario. If IE supports WMV, Safari supports MPEG4 and Opera and Mozilla support Ogg out of the box you can at least be somewhat sure that if you provide content in those 3 formats your visitors will almost certainly be able to access the content (and that's a worst case scenario where interoperability is pretty poor). Browsers don't rely on the OS to decode JPEG or PNG or GIF either - I assume that's driven by similiar reasons. Hooking into the media frameworks of the various platforms may be a good idea despite of this, albeit that may mean that on one platform e.g. Firefox can decode WMV while it can't on some other (and in this case content providers may choose to not provide content in alternative formats because Internet Explorer and Firefox on Windows cover 95% of potential customers and they all can do WMV - that could grow to an unfortunate situation where actually improving interoperability with one media system slams the door for Linux and MacOS users). Maik Merten
Re: [whatwg] The issue of interoperability of the video element
On 27 Jun 2007, at 09:28, Maik Merten wrote: Browsers don't rely on the OS to decode JPEG or PNG or GIF either In my experience that seems to be exactly what they do do—rely on the OS to provide image decoding (as with other AV media). I say this because changes that had occurred in the OS (such as adding JPEG-2000 support) are immediately picked up by my browsers. Firefox can decode WMV while it can't on some other (and in this case content providers may choose to not provide content in alternative formats because Internet Explorer and Firefox on Windows cover 95% of potential customers and they all can do WMV - that could grow to an unfortunate situation where actually improving interoperability with one media system slams the door for Linux and MacOS users). WMV 9 is supported on the Mac OS via a (legal) download, so only Linux would get screwed. Once the download is installed, every app that uses QuickTime (including apps that have their own codecs too, such as RealPlayer, VLC) immediately gain the ability to play WMV files. Same is true for the Theora codecs from xiph.org. I assert that any codec written by a browser vendor and available only within that browser is user-hostile (due to lack of system ubiquity), likely to be slower and buggier than the free decoding component written by the codec vendor themselves, and detracts from the time available for implementing other browser changes. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] The issue of interoperability of the video element
On 6/27/07, Nicholas Shanks [EMAIL PROTECTED] wrote: On 27 Jun 2007, at 09:28, Maik Merten wrote: Browsers don't rely on the OS to decode JPEG or PNG or GIF either In my experience that seems to be exactly what they do do—rely on the OS to provide image decoding (as with other AV media). I say this because changes that had occurred in the OS (such as adding JPEG-2000 support) are immediately picked up by my browsers. You do not know what you are talking about. Firefox does not use OS image decoders. likely to be slower and buggier than the free decoding component written by the codec vendor themselves We use official Ogg Theora libraries. and detracts from the time available for implementing other browser changes. No-one's suggesting reimplementing codecs. We're talking about integrating existing codecs into the browser, and shipping them with the browser. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] The issue of interoperability of the video element
On 27 Jun 2007, at 11:55, Robert O'Callahan wrote: In my experience... You do not know what you are talking about. Firefox does not use OS image decoders. And I don't use Firefox, so my point is still valid. Please don't inform me of what you think I know or do not know, it is impolite. For your future reference, Robert, the browsers I am familiar with and was referring to in my statement about image decoders are WebKit- based browsers, OmniWeb 4.5 (historically), Camino and iCab 3. I avoid FireFox and Opera due to their non-native interfaces and form controls. Given your statement I may be incorrect about Camino though. We use official Ogg Theora libraries. No-one's suggesting reimplementing codecs. We're talking about integrating existing codecs into the browser, and shipping them with the browser. This is only possible if the codec is free. I thought we were talking about the problem of adding non-free codecs (namely WMV and MPEG4) to free software, (possibly also involving reverse-engineering the codec). - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] The issue of interoperability of the video element
Nicholas Shanks schrieb: This is only possible if the codec is free. I thought we were talking about the problem of adding non-free codecs (namely WMV and MPEG4) to free software, (possibly also involving reverse-engineering the codec). Reverse-engineering doesn't lead to usable implementations of non-free formats. You end up having *sourcecode* with a free license attached to it, but you're not allowed to *distribute* actual binaries of that code because the codec is still covered by patents. Take for example libavcodec: That actually has WMV support and its sourcecode is open. However, thanks to the MPEG and Microsoft codecs being patented (and because those patents are enforced) you cannot put it into Mozilla. Open source usually only covers copyright. Truly free codecs are open sourced AND don't require patent licensing. Maik Merten
Re: [whatwg] The issue of interoperability of the video element
On 6/28/07, Nicholas Shanks [EMAIL PROTECTED] wrote: For your future reference, Robert, the browsers I am familiar with and was referring to in my statement about image decoders are WebKit-based browsers, OmniWeb 4.5 (historically), Camino and iCab 3. I avoid FireFox and Opera due to their non-native interfaces and form controls.Given your statement I may be incorrect about Camino though. You are. If we're going to make sweeping statements about how browsers work, let's make sure we include IE, Firefox and Opera in our data. We use official Ogg Theora libraries. No-one's suggesting reimplementing codecs. We're talking about integrating existing codecs into the browser, and shipping them with the browser. This is only possible if the codec is free. I thought we were talking about the problem of adding non-free codecs (namely WMV and MPEG4) to free software, (possibly also involving reverse-engineering the codec). No-one's suggesting that. As Maik points out, reverse engineering is a dead end. Shipping a binary codec with, say, Firefox is a theoretical possibility, but for many reasons it's very unlikely to happen. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer schrieb: So a company which owns a patent on a standard that can bought and read at freedom is just as bad as a company which owns a patent on a standard that has absolutely no public documentation? If you're talking about Ogg Theora, then you've got your facts wrong. First of all, Ogg Theora is not owned by a company. It is open source and sourceode is the best and most accurate public documentation you can get. And if you try google, you'll find a lot of additional documentation, such as this detailed explanation: http://www.xiph.org/theora/doc/Theora_I_spec.pdf and the Theora FAQ http://theora.org/theorafaq.html But I may have misunderstood what you were alluding to. Well, I assume he's referring to Apple, Inc. is no better than Microsoft - meaning that Microsoft is the patent-owning entity which publishes no documentation. Maik Merten
Re: [whatwg] The issue of interoperability of the video element
On 6/26/07, Spartanicus [EMAIL PROTECTED] wrote: Desktop client content support will determine the format most content will be published in. Interesting claim, however Apple so far has introduced AAC (high quality drm-less) and MPEG4 for large audiences (OK, YouTube MPEG4 is merely announced and not technically shipping, but in a week that changes) both targeted at mobile devices. What have you done for the web lately? (I don't count scaring companies that are trying to contribute here) that one announcement has probably done more for me as a consumer of video content since VHS rentals (I never collected many DVDs and didn't use NetFlix) Making a different choice for the mobile segment is not only very costly, it will deny mobile access to the majority of web audio and video content. The mobile web historically has made such amusing choices (WML, thankfully dead). However picking a path which isn't viable to the concerns of those markets means mobile customers lose freedom (pick your definition, i don't really care, practically it's availability, technically it's ability without paying through the nose) - WML was created because bandwidth was expensive (bandwidth is still expensive for most mobile customers). Eventually Google created a nice mobile portal (and maybe Google/Apple will make a mobile video conversion portal too) so that mobile customers could get access most of the web (downsampled) without going broke. IMO the mobile sector will follow suit unless there are insurmountable problems using the same format there. The mobile sector has shown a willingness to go in directions which don't necessarily serve anyone well. It has certainly shown a tendency to go off in its own direction which doesn't match the general world (wml? 3gp video/audio? ring tones that cost more than cd sound tracks?). What evidence do you have to show that the mobile sector ever follows suit in reasonable time? I'm not particularly concerned with Apple's decision not to support an open free format. As I said what players with a small market share do is IMO irrelevant in relation to what will become the de facto standard of publishing audio and video content on the web. I'm sorry, I seem to have missed an introduction, which big player are you and why is it OK for you to dictate terms to anyone? (full disclosure: I work for Nokia - I don't represent Nokia. I contribute to mozilla.org - I don't represent mozilla.org. I work to improve myself - the ideas described in these communications do not necessarily represent my views, my employer's, my associates', my affiliates' [if applicable], or those of anyone else I know.) We tabled the ogg discussion a while ago, this advocacy is a huge waste of electronic bits. Agreed with regard to the criticism of Apple. Sorry, this was ambiguous, I've chosen to take it to mean that you agree people shouldn't criticise companies for being concerned with laws and the risk of lawsuits. Couldn't disagree more with regard to fighting for open and free web content formats. I believe an aim of whatwg is a viable implementable standard that reflects the realities of the web while encouraging innovation. MPEG4 is part of the web (a growing part too).
Re: [whatwg] The issue of interoperability of the video element
timeless [EMAIL PROTECTED] wrote: Desktop client content support will determine the format most content will be published in. Interesting claim, however Apple so far has introduced AAC (high quality drm-less) and MPEG4 for large audiences (OK, YouTube MPEG4 is merely announced and not technically shipping, but in a week that changes) both targeted at mobile devices. I fail to see why that relates to what I wrote. What have you done for the web lately? Someone correct me if I'm wrong, but it is my belief that discussion here is based on strength of argument, not on past credentials. By all means counter argue if you think I'm talking rubbish, but I question the value of saying What have you done for the web lately? If you must know, my presence here is as a web author with an interest in making the web a better experience. I developed an early interest in audio and video encoding formats, imo a potentially more important issue than the browser war. The issue of audio and video encoding formats will potentially give a rights holder control over the actual content that we produce and publish. I have advocated the use of open and free to use encoding formats and transport protocols for many years. (I don't count scaring companies that are trying to contribute here) I've no idea what you are referring to. I made no negative comments about any company. What evidence do you have to show that the mobile sector ever follows suit in reasonable time? I gave my opinion, your's may differ. No-one is able to prove future developments. I'm not particularly concerned with Apple's decision not to support an open free format. As I said what players with a small market share do is IMO irrelevant in relation to what will become the de facto standard of publishing audio and video content on the web. I'm sorry, I seem to have missed an introduction, which big player are you See above. and why is it OK for you to dictate terms to anyone? My prediction is based on how IE has been a major factor with the WhatWG and non IE browser manufacturers accepting that IEs market dominance effectively requires others to adopt IEs markup parsing and strive for good convergence with IE in general. It is my opinion that what will be used on the web is largely a numbers game, market share has the ability to make advocacy reasoning pretty much pointless. No-one other than market leaders have the ability to effectively dictate anything to anyone, and I fail to see how you can read my contribution to the discussion as dictating. My advocacy for open and free to use audio and video formats may well be rendered null and void after the market leaders have made their decision, but until they do I will add my voice to the debate. Sorry, this was ambiguous, I've chosen to take it to mean that you agree people shouldn't criticise companies for being concerned with laws and the risk of lawsuits. I agree. Note that I've not done so, in this or any other thread. I believe an aim of whatwg is a viable implementable standard that reflects the realities of the web while encouraging innovation. MPEG4 is part of the web (a growing part too). I agree with what I perceive to be the WhatWG's modus operandi: aim for the best solutions that can realistically be achieved. Don't engage in ivory tower idealism, accept the boundaries that the real world imposes, including commercial realities. But I don't accept that idealistic advocacy regarding encoding format support for the video element is pointless in the situation in which we are today where the market leaders haven't yet decided what they are going to do. -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
I believe an aim of whatwg is a viable implementable standard that reflects the realities of the web while encouraging innovation. MPEG4 is part of the web (a growing part too). If I may, I'd like to echo Timeless's point here. I've been watching this thread with great interest and believe I understand both sides of the issue. Theora is appealing because it provides a Free as in no-cost to implement and Free as in no-encumbrances solution. However, it also provides a solution that nobody uses today. Perhaps even worse, there doesn't seem to be a lot of interest in adopting Theora in the future. And can you blame web users? Theora provides a solution that's high bandwidth and low quality. A very unappealing prospect for the bandwidth-constrained environment of the web.Thus more competitive solutions like MPEG4, WMV, RealPlayer, and Quicktime have been dominating the web. The most popular form of video streaming at the moment is actually the H.263codec through Flash; a non-free codec which is running on a platform that can only roughly be considered a standard. If and when the Dirac http://en.wikipedia.org/wiki/Dirac_%2528codec%2529codec is completed, there will be a viable alternative to the non-free video codec problem that might justify the risk/reward equation for support. Until then, however, we're going to need to look at supporting the existing infrastructure. That infrastructure is based on the following options: - VP6 - Windows Media Video - MPEG4 - RealVideo 30/40 - H.263 - Quicktime Sorenson Out of those solutions, VP6, WMV, Sorenson, and RealVideo can immediately be discarded for their lack of standardization. That leaves H.263 and MPEG4 as the only viable options. H.263 is not a bad choice, IMHO. It's well supported by nearly every major video player, has a variety of library implementations available, is in widespread usage, and has a good tradeoff between bandwidth and quality. It is also a standard under the ITU-T. But what about MPEG4? Specifying MPEG4 has a lot of appeal for both its excellent encoding performance and its single point to obtain licensing and indemnity from. Furthermore, MPEG4 has its own container format and low-bandwidth audio encoding scheme. (AAC is a sight better than having to dictate ADPMC sound.) MPEG4 is also widely supported by media players, though not quite as well as H.263. The MPEG Group also offers low-cost (i.e. free) licensing to anyone shipping less than 50,000 units a year, which means that it would be feasible for upstart browsers to support the standard. That being said, I think I prefer the H.263 standard as a video baseline for a few reasons: 1. It presents several licensing options. The implementer can chose to get indemnity via an available license like MPEG4-Simple (which will play H.263), choose to try and deal with individual patent holders, or simply attempt to ignore the issue. (The last case is particularly appealing in countries that don't recognize the patents related to streaming video technologies.) 2. It's amazingly well supported both in hardware and software. Future mobile devices should have no trouble adding support for H.263. 3. It's already the most popular codec on the web today. While Real has retired their H.263-based codecs, it still lives on in Adobe FLV files. 4. Java decoders are available for creating shunts for browsers that don't currently support the video tag. That leaves me with two (point 5) questions: 1. Would this place too much of a burden on browsers like Mozilla and Opera? Could plugins to local OS codecs or media players slide around the licensing issues? 2. Is there a good choice for container format that wouldn't additionally burden the implementors? Thanks, Jerason
Re: [whatwg] The issue of interoperability of the video element
Hello Jerason, From a technical point-of-view, you make a very good argument. However, I think it is inappropriate for the HTML spec to (directly or indirectly) mandate people pay to implement it. As you point out, H.263 is encumbered by patents and has licensing costs associates with it. Costs that me, you, tool creators, and users will have to pay, either directly or in-directly This just makes things more expensive for everyone since we are essentially being taxed. And it's ridiculous to just accept this tax when there's no reason we have to. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ All the Vlogging News on One Page http://vlograzor.com/ On 6/26/07, Jerason Banes [EMAIL PROTECTED] wrote: I believe an aim of whatwg is a viable implementable standard that reflects the realities of the web while encouraging innovation. MPEG4 is part of the web (a growing part too). If I may, I'd like to echo Timeless's point here. I've been watching this thread with great interest and believe I understand both sides of the issue. Theora is appealing because it provides a Free as in no-cost to implement and Free as in no-encumbrances solution. However, it also provides a solution that nobody uses today. Perhaps even worse, there doesn't seem to be a lot of interest in adopting Theora in the future. And can you blame web users? Theora provides a solution that's high bandwidth and low quality. A very unappealing prospect for the bandwidth-constrained environment of the web.Thus more competitive solutions like MPEG4, WMV, RealPlayer, and Quicktime have been dominating the web. The most popular form of video streaming at the moment is actually the H.263 codec through Flash; a non-free codec which is running on a platform that can only roughly be considered a standard. If and when the Dirac codec is completed, there will be a viable alternative to the non-free video codec problem that might justify the risk/reward equation for support. Until then, however, we're going to need to look at supporting the existing infrastructure. That infrastructure is based on the following options: VP6 Windows Media Video MPEG4 RealVideo 30/40 H.263 Quicktime SorensonOut of those solutions, VP6, WMV, Sorenson, and RealVideo can immediately be discarded for their lack of standardization. That leaves H.263 and MPEG4 as the only viable options. H.263 is not a bad choice, IMHO. It's well supported by nearly every major video player, has a variety of library implementations available, is in widespread usage, and has a good tradeoff between bandwidth and quality. It is also a standard under the ITU-T. But what about MPEG4? Specifying MPEG4 has a lot of appeal for both its excellent encoding performance and its single point to obtain licensing and indemnity from. Furthermore, MPEG4 has its own container format and low-bandwidth audio encoding scheme. (AAC is a sight better than having to dictate ADPMC sound.) MPEG4 is also widely supported by media players, though not quite as well as H.263. The MPEG Group also offers low-cost (i.e. free) licensing to anyone shipping less than 50,000 units a year, which means that it would be feasible for upstart browsers to support the standard. That being said, I think I prefer the H.263 standard as a video baseline for a few reasons: It presents several licensing options. The implementer can chose to get indemnity via an available license like MPEG4-Simple (which will play H.263), choose to try and deal with individual patent holders, or simply attempt to ignore the issue. (The last case is particularly appealing in countries that don't recognize the patents related to streaming video technologies.) It's amazingly well supported both in hardware and software. Future mobile devices should have no trouble adding support for H.263. It's already the most popular codec on the web today. While Real has retired their H.263-based codecs, it still lives on in Adobe FLV files. Java decoders are available for creating shunts for browsers that don't currently support the video tag. That leaves me with two (point 5) questions: Would this place too much of a burden on browsers like Mozilla and Opera? Could plugins to local OS codecs or media players slide around the licensing issues? Is there a good choice for container format that wouldn't additionally burden the implementors? Thanks, Jerason
Re: [whatwg] The issue of interoperability of the video element
Jerason Banes schrieb: Out of those solutions, VP6, WMV, Sorenson, and RealVideo can immediately be discarded for their lack of standardization. That leaves H.263 and MPEG4 as the only viable options. H.263 is not a bad choice, IMHO. It's well supported by nearly every major video player, has a variety of library implementations available, is in widespread usage, and has a good tradeoff between bandwidth and quality. It is also a standard under the ITU-T. [...] That being said, I think I prefer the H.263 standard as a video baseline for a few reasons: H.263 is seriously outperformed by Theora. I don't know where all that Theora is high bitrate and low quality talk comes from. It's not as good as H.264, but it's for sure not worse than H.263 and from my tests it's consistently better at low bitrate video. Maik Merten
Re: [whatwg] The issue of interoperability of the video element
Hi Charles, While I agree with your sentiment, I don't see a better option. The purpose of the HTML5 spec is to provide a unified web applications platform that supports the existing web in a practical manner. If the spec sticks with Theora as the baseline implementation, it runs the risk of no one implementing that part of the specification. If no one implements the Theora codec, then the attempts to standardize the video tag will be all for naught. At the end of the day, I think the decision will come down to one of two options: - The spec can specify Theora as the baseline, very few browsers will implement it, few users will use it (due to a lack of support), and thus the intent of standardizing on a free format will be lost. - The spec can be practical about implementing the video tag and specify H.263 or MPEG4 as a baseline. Existing multimedia toolkits can be reused in implementation and thus all browsers can support the standard. Users will use the format thanks to ubiquitous support. The tax will be a non-issue in most cases despite leaving a bad taste in the standard committee's mouth. Up and coming browsers can choose not to implement that part of the standard if they so choose or piggyback on an existing media player's licensing. I personally think that having a non-free standard implemented in all browsers is preferable to having a free standard implemented in none. Otherwise, what is this tag being standarded for? We already have a mishmash of options available through the embed and object tags. It also occurs to me that the market is likely to define a format like MPEG4 as the standard whether the WHATWG wants it to or not. If the least-common-denominator across browsers is MPEG4 (for example), then why would the market embrace spotty support for theora? The practical solution will win out regardless of what is decided here. Which will force new browsers to support a pseudo-standard rather than a real standard, anyway. Exactly the type of thing that the WHATWG was formed to prevent. Thanks, Jerason On 6/26/07, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Jerason, From a technical point-of-view, you make a very good argument. However, I think it is inappropriate for the HTML spec to (directly or indirectly) mandate people pay to implement it. As you point out, H.263 is encumbered by patents and has licensing costs associates with it. Costs that me, you, tool creators, and users will have to pay, either directly or in-directly This just makes things more expensive for everyone since we are essentially being taxed. And it's ridiculous to just accept this tax when there's no reason we have to. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ All the Vlogging News on One Page http://vlograzor.com/ On 6/26/07, Jerason Banes [EMAIL PROTECTED] wrote: I believe an aim of whatwg is a viable implementable standard that reflects the realities of the web while encouraging innovation. MPEG4 is part of the web (a growing part too). If I may, I'd like to echo Timeless's point here. I've been watching this thread with great interest and believe I understand both sides of the issue. Theora is appealing because it provides a Free as in no-cost to implement and Free as in no-encumbrances solution. However, it also provides a solution that nobody uses today. Perhaps even worse, there doesn't seem to be a lot of interest in adopting Theora in the future. And can you blame web users? Theora provides a solution that's high bandwidth and low quality. A very unappealing prospect for the bandwidth-constrained environment of the web.Thus more competitive solutions like MPEG4, WMV, RealPlayer, and Quicktime have been dominating the web. The most popular form of video streaming at the moment is actually the H.263 codec through Flash; a non-free codec which is running on a platform that can only roughly be considered a standard. If and when the Dirac codec is completed, there will be a viable alternative to the non-free video codec problem that might justify the risk/reward equation for support. Until then, however, we're going to need to look at supporting the existing infrastructure. That infrastructure is based on the following options: VP6 Windows Media Video MPEG4 RealVideo 30/40 H.263 Quicktime SorensonOut of those solutions, VP6, WMV, Sorenson, and RealVideo can immediately be discarded for their lack of standardization. That leaves H.263 and MPEG4 as the only viable options. H.263 is not a bad choice, IMHO. It's well supported by nearly every major video player, has a variety of library implementations available, is in widespread usage, and has a good tradeoff between bandwidth and quality. It is also a standard under the ITU-T. But what about MPEG4? Specifying MPEG4 has a lot of appeal for both its excellent encoding performance and its single point to
Re: [whatwg] The issue of interoperability of the video element
Jerason Banes schrieb: * The spec can specify Theora as the baseline, very few browsers will implement it, few users will use it (due to a lack of support), and thus the intent of standardizing on a free format will be lost. Opera and Mozilla already have implemented (early) Ogg Vorbis and Ogg Theora support. Plus what is lack of support? Encoding apps for Ogg Theora are available on basically every platforms, as are players (yes, even Windows Media Player and QuickTime player can play it with the fitting components installed, same goes for RealPlayer). It's absolutely trivial to encode content for it. * The spec can be practical about implementing the video tag and specify H.263 or MPEG4 as a baseline. Existing multimedia toolkits can be reused in implementation and thus all browsers can support the standard. Users will use the format thanks to ubiquitous support. The tax will be a non-issue in most cases despite leaving a bad taste in the standard committee's mouth. Up and coming browsers can choose not to implement that part of the standard if they so choose or piggyback on an existing media player's licensing. Free Software like Mozilla cannot implement MPEG4 or H.263 and still stay free. The tax *is* an issue because you can't buy a community license that is valid for all uses. Plus even if you implement H.263 or MPEG4 video - what audio codec should be used with that? Creating valid MPEG streams would mean using a MPEG audio codec - that'd be e.g. MP3 or AAC. Additional licensing costs and additional un-freeness. Don't get me wrong: MPEG technology is nice and well performing - but the licensing makes implementations in free software impossible (or at least prevents distribution in e.g. Europe or North America). Maik Merten
Re: [whatwg] The issue of interoperability of the video element
Jerason Banes schrieb: If that's true, then I'm greatly relieved. VP3 (the source of Theora) is generally compared to MPEG1, a standard far exceeded by H.263. I have not seen any publicly available Theora benchmarks that would overturn such impressions. (Do any exist?) Most public benchmarks are usually outdated and using VP3. Albeit the claim is often made that VP3 performed no better than MPEG1 this - concluding from my tests - isn't correct (at least not for the version I tested - actually there were different VP3 versions, the latest one being VP3.2 IIRC). Actually the original encoder xiph.org received from On2 did have a bunch of bugs that impacted on the output. Theora's current encoder is generally in a better shape than what was VP3. I'll gladly send you small test clips showing H.263 and Theora at low bitrates (which would be the major use for web video) if you wish (below one megabyte, even suitable for attaching to an email). Maik Merten On 6/26/07, *Maik Merten* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Jerason Banes schrieb: H.263 is seriously outperformed by Theora. I don't know where all that Theora is high bitrate and low quality talk comes from. It's not as good as H.264, but it's for sure not worse than H.263 and from my tests it's consistently better at low bitrate video.
Re: [whatwg] The issue of interoperability of the video element
On 6/26/07, Maik Merten [EMAIL PROTECTED] wrote: Opera and Mozilla already have implemented (early) Ogg Vorbis and Ogg Theora support. And (if this thread is any indication) are likely to be the only ones. Internet Explorer still holds the majority of the market, and Safari is still the predominant browser in the Mac market. Plus what is lack of support? Encoding apps for Ogg Theora are available on basically every platforms, as are players (yes, even Windows Media Player and QuickTime player can play it with the fitting components installed, same goes for RealPlayer). It's absolutely trivial to encode content for it. The same can be said for H.263 and MPEG4. Linux machines can play these codecs with no issues as long as the codecs are installed separate from the distro itself. The question that I hate to ask (because it goes against my own grain to ask it) is, which is more useful to the web market: Asking Windows users to install Ogg/Theora codecs or asking Linux users to install H.263 codecs? Given that Linux has an extremely small desktop share consisting of expert users, I'm forced to answer that they would be far less impacted by a baseline support of H.263 than Windows users will be impacted by a baseline support of Theora. Free Software like Mozilla cannot implement MPEG4 or H.263 and still stay free. The tax *is* an issue because you can't buy a community license that is valid for all uses. Indeed. That's why I asked how feasible it is for these browsers to plug into underlying media players? On windows that would be WMP, Quicktime on Macs, and libavcodec on Linux/Unix. Plus even if you implement H.263 or MPEG4 video - what audio codec should be used with that? Creating valid MPEG streams would mean using a MPEG audio codec - that'd be e.g. MP3 or AAC. Additional licensing costs and additional un-freeness. Correct me if I'm wrong, but that depends on the container format, doesn't it? If we use the MPEG container format, then yeah. MP3 is pretty much a guaranteed necessity. However, I am not aware of any encumbrances (*grits teeth again*) with the AVI container format. Which would allow for a less-performant baseline like an ADPCM format, which is at least an open standard. Of course, I'm probably going to have to bow to my own argument and agree that the market would never accept such a low audio baseline. Which means that something like MP3 or AAC would indeed be a requirement. Don't get me wrong: MPEG technology is nice and well performing - but the licensing makes implementations in free software impossible (or at least prevents distribution in e.g. Europe or North America). It is a difficult conundrum. If the WHATWG specifies theora, then it runs the risk of being ignored. If it specifies an existing format then it runs the risk of locking out some small cross-section of users. My argument is based around the devil you know approach that the WHATWG has otherwise adopted in its standards. It rubs me the wrong way to suggest it, but I don't see any other way of ensuring that HTML5 video would become as ubiquitous as FLV video has become. Thanks, Jerason
Re: [whatwg] The issue of interoperability of the video element
Jerason Banes schrieb: On 6/26/07, *Maik Merten* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Opera and Mozilla already have implemented (early) Ogg Vorbis and Ogg Theora support. And (if this thread is any indication) are likely to be the only ones. Internet Explorer still holds the majority of the market, and Safari is still the predominant browser in the Mac market. Microsoft isn't part of WHATWG. If they implement video due to market demands they'll most likely push WMV no matter what is discussed here. That doesn't mean we should support WMV usage on the net. Plus what is lack of support? Encoding apps for Ogg Theora are available on basically every platforms, as are players (yes, even Windows Media Player and QuickTime player can play it with the fitting components installed, same goes for RealPlayer). It's absolutely trivial to encode content for it. The same can be said for H.263 and MPEG4. Linux machines can play these codecs with no issues as long as the codecs are installed separate from the distro itself. The question that I hate to ask (because it goes against my own grain to ask it) is, which is more useful to the web market: Asking Windows users to install Ogg/Theora codecs or asking Linux users to install H.263 codecs? Users that download unlicensed MPEG decoders are in a legal grey area depending on where you live (actually it may be darker than just grey). It's not an option to suggest people shall ignore the licensing fees. Of course they could buy licensed decoders - but assuming people will spend money just to enable proper video support in their browsers isn't realistic. Users on all platforms, however, can download and install a codec with free licensing terms without problems. Given that Linux has an extremely small desktop share consisting of expert users, I'm forced to answer that they would be far less impacted by a baseline support of H.263 than Windows users will be impacted by a baseline support of Theora. Every single user will - if at all - have to install whatever codec *once*. Same for Linux and Windows and Mac. People choosing a browser with e.g. Theora support won't have to bother at all. Free Software like Mozilla cannot implement MPEG4 or H.263 and still stay free. The tax *is* an issue because you can't buy a community license that is valid for all uses. Indeed. That's why I asked how feasible it is for these browsers to plug into underlying media players? On windows that would be WMP, Quicktime on Macs, and libavcodec on Linux/Unix. Windows doesn't come with H.263 or MPEG4 (e.g. Part 2) support by default. Oh, and you'd give Microsoft the power to simply drop whatever support they ship and force things down to WMV. Oh, and you can't take libavcodec for granted. Even if it is installed on some systems: I wouldn't be surprised if most installations are not properly licensed. I'm not aware of any way to get a properly licensed libavcodec (which implements basically every format known on earth - and which therefore may infringe basically every patent ever filed in that area). To my knowledge there's not one single suitable audio/video codec combination that is installed by default on Windows, Mac and Linux. Plus even if you implement H.263 or MPEG4 video - what audio codec should be used with that? Creating valid MPEG streams would mean using a MPEG audio codec - that'd be e.g. MP3 or AAC. Additional licensing costs and additional un-freeness. Correct me if I'm wrong, but that depends on the container format, doesn't it? If we use the MPEG container format, then yeah. MP3 is pretty much a guaranteed necessity. However, I am not aware of any encumbrances (*grits teeth again*) with the AVI container format. Which would allow for a less-performant baseline like an ADPCM format, which is at least an open standard. ADPCM is not suitable for web usage. After all we still want to have some bits left for video, right? ;-) Of course, I'm probably going to have to bow to my own argument and agree that the market would never accept such a low audio baseline. Which means that something like MP3 or AAC would indeed be a requirement. There's a reason why free software avoids these codecs. Don't get me wrong: MPEG technology is nice and well performing - but the licensing makes implementations in free software impossible (or at least prevents distribution in e.g. Europe or North America). It is a difficult conundrum. If the WHATWG specifies theora, then it runs the risk of being ignored. If it specifies an existing format then it runs the risk of locking out some small cross-section of users. My argument is based around the devil you know approach that the WHATWG has otherwise adopted in its standards. It rubs me the wrong way to suggest it, but I don't see any other way of ensuring that HTML5 video would become as
Re: [whatwg] The issue of interoperability of the video element
But I don't accept that idealistic advocacy regarding encoding format support for the video element is pointless in the situation in which we are today where the market leaders haven't yet decided what they are going to do. they havent? it seems pretty clear to me adobe - push swf/flv/apollo microsoft - push windowsmedia/silverlight apple - push quicktime/h26[34] due to installed-base LCD, we're stuck with flv unless: microsoftapple agree on a codec, or webkitmozillaopera agree on a codec and IE has to cave in and support it too has any player shown recent interest in change?
Re: [whatwg] The issue of interoperability of the video element
I don't quite get some of the arguments in the thread. Browsers don't (and shouldn't) include their own av decoders anyway. Codec support is an operating system issue, and any browser installed on my computer supports exactly the same set of codecs, which are the ones made available via the OS (QuickTime APIs in my case, Windows Media APIs on Bill's platform, and from the sounds of it, libavcodec on the Penguin) So Mozilla and Opera wouldn't need to license MPEG to get MPEG support, they would either get it if the user had an MPEG codec installed, or they wouldn't. And that would be no different from IE or the user's other browsers, so they wouldn't be at a disadvantage. If a browser implemented it's own codecs, they would almost certainly be slower and more buggy than the ones that exist on the system already. WRT Apple and Ogg Theora: Iagree that given the high risk-to-reward cost of Theora to Apple, it's their right not to ship it, but it would be most consumer unfriendly not to link to xiph.org when a theora video is first encountered. And this link should probably be a redirect via the apple.com domain so that they can intercept and change the path if the destination changes. Hard-coding URLs for codecs into either the HTML or the shipping software is a bad idea. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] The issue of interoperability of the video element
On 26 Jun 2007, at 00:57, Silvia Pfeiffer wrote: So a company which owns a patent on a standard that can bought and read at freedom is just as bad as a company which owns a patent on a standard that has absolutely no public documentation? If you're talking about Ogg Theora, then you've got your facts wrong. First of all, Ogg Theora is not owned by a company. So a company [Apple] which owns a patent on a standard that can bought and read at freedom [MPEG4] is just as bad as a company [Microsoft] which owns a patent on a standard that has absolutely no public documentation [WMA/WMV]? - Geoffrey Sneddon
Re: [whatwg] The issue of interoperability of the video element
Hi Jerason, I think there may be a lack of information about Theora rather than anything else. On 6/27/07, Jerason Banes [EMAIL PROTECTED] wrote: If I may, I'd like to echo Timeless's point here. I've been watching this thread with great interest and believe I understand both sides of the issue. Theora is appealing because it provides a Free as in no-cost to implement and Free as in no-encumbrances solution. However, it also provides a solution that nobody uses today. Perhaps even worse, there doesn't seem to be a lot of interest in adopting Theora in the future. It is not true that Theora is not used today. Wikipedia allows it as the only video codec to publish content in on their site. Archive.org support it as a format. And just about all video published by Linux-related conferences is now published in Ogg Theora. Even some social video hosting sites support it now. I agree however that it is early days and that there is a lot of education to be done around Ogg Theora. And can you blame web users? Theora provides a solution that's high bandwidth and low quality. What makes you say that? Ogg Theora is comparable to MPEG-2, WMV, RelPlayer and many other proprietary codecs - the only codec really outperforming it is H.264. If and when the Dirac codec is completed, there will be a viable alternative to the non-free video codec problem that might justify the risk/reward equation for support. Yes, Dirac is comparable in quality to H.264, but just hasn't got the tool support yet that Ogg Theora has. If we are standardising for a few years down the track, we should indeed consider Ogg Dirac/Vorbis as an alternative. Regards, Silvia.
Re: [whatwg] The issue of interoperability of the video element
On 26 Jun 2007, at 17:46, Maik Merten wrote: * The spec can be practical about implementing the video tag and specify H.263 or MPEG4 as a baseline. Existing multimedia toolkits can be reused in implementation and thus all browsers can support the standard. Users will use the format thanks to ubiquitous support. The tax will be a non-issue in most cases despite leaving a bad taste in the standard committee's mouth. Up and coming browsers can choose not to implement that part of the standard if they so choose or piggyback on an existing media player's licensing. Free Software like Mozilla cannot implement MPEG4 or H.263 and still stay free. The tax *is* an issue because you can't buy a community license that is valid for all uses. Plus even if you implement H.263 or MPEG4 video - what audio codec should be used with that? Creating valid MPEG streams would mean using a MPEG audio codec - that'd be e.g. MP3 or AAC. Additional licensing costs and additional un-freeness. Don't get me wrong: MPEG technology is nice and well performing - but the licensing makes implementations in free software impossible (or at least prevents distribution in e.g. Europe or North America). Under the current spec it is merely a SHOULD — you can have an implementation of the spec that omits it. MPEG4 and WMV are the current de-facto standards. We should really just pave the cowpaths here, meaning those are the real two options. WMV has absolutely no publicly available documentation, so it makes no sense to reference that. MPEG4 has publicly available documentation, but is patent- encumbered. MPEG4 looks better on grounds that it is at least implementable by people outside of MS without reverse engineering it themselves. - Geoffrey Sneddon
Re: [whatwg] The issue of interoperability of the video element
On 6/27/07, Jerason Banes [EMAIL PROTECTED] wrote: The question that I hate to ask (because it goes against my own grain to ask it) is, which is more useful to the web market: Asking Windows users to install Ogg/Theora codecs Actually, we just ask them to install Firefox :-) or asking Linux users to install H.263 codecs? If they can't do it legally, that is a tough thing to ask for. The bottom line is what Maik said in another message: Theora is the only option right now for implementation by free software, so that's what Mozilla will push as the best format for an open Internet. I hope we will also support codecs installed on the user's OS, thereby getting pretty wide (but not universal) support for MPEG4 etc, but we don't have the resources to implement that for Firefox 3. This discussion is not really adding anything new... Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer [EMAIL PROTECTED] wrote: Opera have already implemented support for Ogg Theora and the video tag. (see http://video.google.com.au/videoplay?docid=5545573096553082541pr=goog-sl) Opera has published a one off interim experimental build (Windows only) with video support and native Ogg Theora and Vorbis support, see http://labs.opera.com/ But this support is experimental, it remains to be seen if it will be included in future release versions, and if so with what decoder support. So far the versions published after the aforementioned experimental interim build did not support video. -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
I would like to make clear one more thing: When I attended the iCommons Summit earlier this month, I have met the project manager of the OLPC project, you know the $150 laptop for children in developing nations, and the information that I have right now is that it will not support proprietary media formats. If all goes well, there will be a large public using Theora video in their daily-life. Shouldn't they be able to see Theora video online? Do we not agree that the video element will be a great tool for online education? This won't happen if the video element becomes a failure, a failure if every vendor tries to set a different standard for video. Not to mention that patented formats will not work for the large public using the OLPC systems. See it as you want. Mozilla, Opera, and the KDE team have agreed that Theora and Vorbis are perfect for media over the web. We do not know the official position of Microsoft, although we can imagine. We do know, however, the official stance of Apple. Should everyone change their plans because of Apple's decision? I think not, but then again I work for none of those companies. -Ivo
Re: [whatwg] The issue of interoperability of the video element
On 6/26/07, Silvia Pfeiffer [EMAIL PROTECTED] wrote: It is not true that Theora is not used today. revision3.net is another site that uses/provides Theora. http://revision3.net/diggnation With videolan at least, the theora ones use less cpu than the other formats, which makes it easier to watch things on slower computers. Browser plugins suck though. See http://forum.videolan.org/viewtopic.php?f=16t=35815sid=d20cbd9c67c552fd230edfeb6bd9ad70 and http://forums.divx.com/forum/viewTopic.php?id=2970 and the windows media player plugin for examples. Also, you have liveconnect, xpconnect and npruntime scripting issues and plugins reporting only a small amount of file types they support when they actually support more. You also get plugin installation problems where plugin vendors don't set up the installers properly and browsers can't find the plugins. Anyway, I definitely want native theora support right in the browser so issues like those can be avoided and I can take the support with me on a USB stick for example. If theora performance for the video element is as good or better than videolan, that would be awesome. I really wish Apple could take the risk. -- Michael
Re: [whatwg] The issue of interoperability of the video element
At 10:16 +1000 25/06/07, Silvia Pfeiffer wrote: Thanks Maciej for summarising Apple's position so nicely. I think it's good that you have spelled it out: Apple is happy to support MPEG-4, which has known patent encumberance and unknown submarine patents, while Apple is not happy to support Ogg Theora/Vorbis which has no known patent encumberance can I insert the same phrase you used and unknown submarine patents? Otherwise you mis-characterize the position. What is more, no-one with deep pockets has yet used the Ogg codecs seriously, and therefore there is no honey pot to attract the submarines (hm, do submarines like honey?). This is not the case with H.264 and AAC, as we have made, um, some money using them, among others. More, the major players who are likely to have patents are under a RAND commitment for ISO standards; they are under no obligation at all for Ogg. Are you, Sylvia, prepared to offer any kind of indemnification for this open-ended patent risk? We have had this discussion before, and I am not sure that new arguments are being raised; the Ogg codecs currently offer us more risk than reward. . This has to be very clear to everybody. I also agree: H.264 procudes undoubtedly better quality video than Theora at the same bitrate. And I have no problem with Apple supporting H.264. In particular when I sign up e.g. for movie delivery through Apple, I'd be more than happy for H.264 delivery. But the open Internet/Web should be run on open technology. ISO standards are indeed open standards. Also, on a side note, it is as yet unproven whether Ogg Theora or H.264 are better for video delivery to low-powered devices. In particular when considering the complexity of H.264 and the comparable simplicity of Theora - it may well be that an efficient HW implementation of Theora is better suited to low-powered devices than H.264. This is a matter of ongoing research development. BTW: don't expect the discussion to be gone just because the position of Apple has been made clear. As long as it doesn't make sense in the greater scheme of things, it will re-emerge. Even if it might not get resolved to the satisfaction of everybody. I (and others at Apple) are aware that the situation is not ideal, I assure you. I wish I could see a better solution than the current should. Indeed, as you pointed out, an ability to add codecs would ameliorate the situation. Lastly, I feel a little hurt that Apple is being so attacked when we take great efforts to develop, implement, promote, and interoperate open systems and specifications, while there are others in the industry who make no such efforts. Could the rhetoric against us be toned down a little, please? -- David Singer Apple/QuickTime
Re: [whatwg] The issue of interoperability of the video element
Maciej Stachowiak wrote: This has been discussed to death already, but here are our basic reasons: - MPEG-4 is an ISO open standard (although unfortunately patent-encumbered). No-one is telling you not to support MPEG-4. - H.264 offers considerably better quality at the same bitrate than Theora/Vorbis. - H.264 is better for video delivery to limited-capability and low-power devices that support hardware video decoding. You may have heard that YouTube will be serving their video content as H.264 to AppleTV and iPhone. Again, no-one is telling you not to support it. So that leaves only the following argument _against_ supporting Ogg as well as other things you might want to support: - Ogg Theora/Vorbis offers a royalty-free license for the few known patents, but we would assume additional risk of submarine patents if we supported it. Leaving aside the merits of this final argument for a moment, it might save time when giving your list in future if you only mentioned this one :-) Gerv
Re: [whatwg] The issue of interoperability of the video element
Dave Singer wrote: What is more, no-one with deep pockets has yet used the Ogg codecs seriously, and therefore there is no honey pot to attract the submarines (hm, do submarines like honey?). This is not the case with H.264 and AAC, as we have made, um, some money using them, among others. If you had been making this argument before November last year, would you have included MP3 in that list of technologies people had been making money from but which had attracted no submarines? http://en.wikipedia.org/wiki/Alcatel-Lucent_v._Microsoft shows that this sort of argument about deep pockets and so far shouldn't give Apple much confidence. MP3 was used by a lot of people with deep pockets for quite a while before the submarine surfaced. Gerv
Re: [whatwg] The issue of interoperability of the video element
Hi Dave, On 6/25/07, Dave Singer [EMAIL PROTECTED] wrote: At 10:16 +1000 25/06/07, Silvia Pfeiffer wrote: Thanks Maciej for summarising Apple's position so nicely. I think it's good that you have spelled it out: Apple is happy to support MPEG-4, which has known patent encumberance and unknown submarine patents, while Apple is not happy to support Ogg Theora/Vorbis which has no known patent encumberance can I insert the same phrase you used and unknown submarine patents? Since that was already mentioned before, I saw no reason to repeat it. What is more, no-one with deep pockets has yet used the Ogg codecs seriously, and therefore there is no honey pot to attract the submarines (hm, do submarines like honey?). This is not the case with H.264 and AAC, as we have made, um, some money using them, among others. More, the major players who are likely to have patents are under a RAND commitment for ISO standards; they are under no obligation at all for Ogg. Are you, Sylvia, prepared to offer any kind of indemnification for this open-ended patent risk? We have had this discussion before, and I am not sure that new arguments are being raised; the Ogg codecs currently offer us more risk than reward. I have previously said so and I will repeat it: Ogg Vorbis is being used by many large players - even Microsoft is using it in their games. Theora is not that far yet, but I assume the technologies in use in Theora are being used in VP6, since Theora is essentially VP3 - and VP6 is one of the core Flash codecs. So, I cannot see that repeated argument of no large players are using them being valid any longer. In fact, it seems that Fraunhofer used to claim that Vorbis may infringe on some of their patents. They have since withdrawn that claim, which to me signifies they have done their homework and seen no reason to attack vorbis any longer. All they'd need to do is to state that Vorbis is infringing patents and Vorbis would change or be dead. This has not happened. So, how likely is the submarine patents claim now? I also agree: H.264 procudes undoubtedly better quality video than Theora at the same bitrate. And I have no problem with Apple supporting H.264. In particular when I sign up e.g. for movie delivery through Apple, I'd be more than happy for H.264 delivery. But the open Internet/Web should be run on open technology. ISO standards are indeed open standards. On some scale of openness. http://en.wikipedia.org/wiki/Open_standards But I don't want to get into that discussion. All these standards are important and MPEG, H.264 have an important place. However with its current restrictions not on the Web. As long as not everybody on the Internet can use video in the same way, we cannot be satisfied in this committee. It's not your fault that the MPEG conditions are the way they are. And it is completely your choice to support whatever codecs you decide you want to support. But you must accept that this committee can have a discussion about the consequences of your choices - and this has nothing to do with personal attacks and rhetorics. Your support to the open systems is highly valued, but it's not the subject of discussion of this thread. Best Regards, Silvia.
Re: [whatwg] The issue of interoperability of the video element
According to Wikipedia, ATT is trying to sue companies such as Apple Inc. over alleged MPEG-4 patent infringement.[1][2][3] I would be fascinated to see a statement from Apple, Inc. regarding this. It's also quite interesting that different portions of MPEG-4, including different sections of video and audio are licensed separately, so what this means is that any vendor willing to support MPEG-4 for video and audio has to locate every patent holder and pay them. Oh, and will you look at this, Apple, Inc. holds one the patents! US 6,134,243 [4]. So Apple gets money for every single license sold. How nice. They are attempting to lock vendors into MPEG-4 and get money from licenses in the process. Apple, Inc. is no better than Microsoft. [1] http://www.engadget.com/2006/02/10/atandt-claims-mpeg-4-patent-infringement-wants-apple-to-pay-up/ [2] http://www.theinquirer.net/?article=29679 [3] http://www.pcmag.com/article2/0,1895,1923218,00.asp [4] http://www.mpegla.com/m4s/m4s-att1.pdf
Re: [whatwg] The issue of interoperability of the video element
Dave Singer schrieb: At 10:16 +1000 25/06/07, Silvia Pfeiffer wrote: can I insert the same phrase you used and unknown submarine patents? Otherwise you mis-characterize the position. What is more, no-one with deep pockets has yet used the Ogg codecs seriously, and therefore there is no honey pot to attract the submarines (hm, do submarines like honey?). Obviously there is a bunch of Ogg codecs. Well, as for Ogg Vorbis there e.g. are... Microsoft (their game division loves Ogg Vorbis), Epic Megagames, id Software and many more (actually I have problems finding major game studios that don't use Vorbis). Some manufacturers (one example is Samsung) put Vorbis into their DAPs. Oh, and AOL is shipping it with WinAmp, the #1 digital media player for the Windows platform. Ogg Speex again is used by many VoIP products, this includes Xbox Live (again, Microsoft). And Ogg Theora's technology was used commercially as VP3 (you'd have to ask On2 on what revenue was raised in that time period) - Theora itself is in basically every Linux distribution out there, of course including the commercial ones. Red Hat and Novell and whatnot - again, multi-million dollar deployments. Now, you could argue if that honey pot is large enough or not. No idea what the usual patent troll threshold is. Fact is: There is a submarine threat for both MPEG (you're already having that risk) and Ogg (you'd like to avoid putting that potential risk on top of the risks you're already taking). That is my understanding of your situation and it won't help arguing Tomorrow you could be sued for using H.264 or MP3 or AAC or Tomorrow you could be sued for using Theora or Vorbis. ISO standards are indeed open standards. Well, as usual it depends on how one defines open. If open is assumed to mean usable even for people/organizations without money then standards with patent license fees (no matter if ISO or not) are not open, even if they're more open than e.g. completely proprietary stuff. I (and others at Apple) are aware that the situation is not ideal, I assure you. I wish I could see a better solution than the current should. Indeed, as you pointed out, an ability to add codecs would ameliorate the situation. Lastly, I feel a little hurt that Apple is being so attacked when we take great efforts to develop, implement, promote, and interoperate open systems and specifications, while there are others in the industry who make no such efforts. Could the rhetoric against us be toned down a little, please? If there's a problem, let's get constructive and let's try to solve it. If Apple doesn't want to take the IP risk of shipping anything but QuickTime then let's find someone who's willing to do it ;-) If Safari is encountering application/ogg and it can't decode that stuff then redirect (after asking of course) the user to a fitting QuickTime component download page on e.g. xiph.org or even automate the process of installing a fitting 3rd-party component after the user acknowledged the process. That won't be as smooth as native and out of the box support - but if the whole process only involves like 4 user mouse clicks then operability is as okay as it can be under the given circumstances. Maik Merten
Re: [whatwg] The issue of interoperability of the video element
On 25 Jun 2007, at 13:21, Ivo Emanuel Gonçalves wrote: According to Wikipedia, ATT is trying to sue companies such as Apple Inc. over alleged MPEG-4 patent infringement.[1][2][3] I would be fascinated to see a statement from Apple, Inc. regarding this. Seeming they are already under risk from what they already support, what advantage do Apple get by supporting more codecs, therefore opening up themselves to further risks? It's also quite interesting that different portions of MPEG-4, including different sections of video and audio are licensed separately, so what this means is that any vendor willing to support MPEG-4 for video and audio has to locate every patent holder and pay them. No, they don't, it all goes through MPEG-LA. Oh, and will you look at this, Apple, Inc. holds one the patents! US 6,134,243 [4]. So Apple gets money for every single license sold. How nice. They are attempting to lock vendors into MPEG-4 and get money from licenses in the process. Apple, Inc. is no better than Microsoft. So a company which owns a patent on a standard that can bought and read at freedom is just as bad as a company which owns a patent on a standard that has absolutely no public documentation? Also, a large part of this topic has been around H.264, Apple holds no known patents affecting H.264. - Geoffrey Sneddon
Re: [whatwg] The issue of interoperability of the video element
At 13:21 +0100 25/06/07, Ivo Emanuel Gonçalves wrote: According to Wikipedia, ATT is trying to sue companies such as Apple Inc. over alleged MPEG-4 patent infringement.[1][2][3] I would be fascinated to see a statement from Apple, Inc. regarding this. I regret that we (like most companies) cannot comment on possible pending litigation (fascinating as some of these cases are). Sorry. It's also quite interesting that different portions of MPEG-4, including different sections of video and audio are licensed separately, so what this means is that any vendor willing to support MPEG-4 for video and audio has to locate every patent holder and pay them. Yes, video and audio are separate; but there are also pools that simplify the position. Oh, and will you look at this, Apple, Inc. holds one the patents! US 6,134,243 [4]. So Apple gets money for every single license sold. It's nice that you have done the research and found what we are doing with our patents. Or are you guessing? How nice. They are attempting to lock vendors into MPEG-4 Pardon? We use it and are happy when others do. *We* are not asking more. It's not us who are proposing any lock or mandate; you might check the Ogg community for that suggestion. Also, you might wonder whether licensing of standards is a net income or cost for us. and get money from licenses in the process. Apple, Inc. is no better than Microsoft. And Ivo is no better than Sylvia. This isn't a very helpful comparison. (Actually, I know Sylvia but regret that I don't think I have ever met you). -- David Singer Apple/QuickTime
Re: [whatwg] The issue of interoperability of the video element
Hello, On 6/25/07, Maik Merten [EMAIL PROTECTED] wrote: [...] If Safari is encountering application/ogg and it can't decode that stuff then redirect (after asking of course) the user to a fitting QuickTime component download page on e.g. xiph.org or even automate the process of installing a fitting 3rd-party component after the user acknowledged the process. Just an FYI There's plans to register the video/ogg MIME type, and use for Ogg based video. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ All the Vlogging News on One Page http://vlograzor.com/
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer [EMAIL PROTECTED] wrote: No need to encode as a java applet - all you need to do is put the java applet on the server together with your Ogg Theora content. And - by all means - this is not supposed to be an end solution, but just a fix to bridge the gap until all Browsers support the baseline codec. I don't understand why Java is needed client side if content can be authored as video src=myvid.mpg/video, but this isn't the place to explain what I presume it is caused by my lack of understanding of Java. My main worry relates to the usability and accessibility of future audio and video web content. Content including the wrapping should be free, to consume, to serve, to manipulate and to create. That basic principle should make it possible to write, publish and distribute free clients and authoring software. Combined this is imo of great importance to keep the threshold as low as possible to what might become the most extensive resource of human knowledge and communication. Audio and video are no longer peripheral in that pool of knowledge and communication, they are essential. Support in clients with a small market share like Opera and Safari is imo unlikely to be a significant consideration for content creators when deciding which encoding format to use. MS and Mozilla with their , combined ~95% of the market will probably determine what will be used. Opera and Safari will probably have to follow suit if they can. If IE and Mozilla support a common codec, and if that codec roughly meets the quality vs bandwidth requirements of content providers then imo there's a high probability that this format will be used to create future audio and video web content. Anyone know if Microsoft and Mozilla have expressed their wishes and intentions? -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
Forgive my intruston, as I have been a lurker on this discussion for some months, and some of the discussion often goes over my head. This may have been proposed (if it has, I apologize for wasting your time), and perhaps I do not fully appreciate the implications - but perhaps a solution would be to require the video element to include a codec URI as an attribute? This way, any codec could theoretically be used, and new ones could be added as things evolve. The markup would then be something like this: video codec=mp4 http://codecs.apple.com/mp4 src=myvideo.mpg/video or video codec=theora src=myvideo.the/video The codecs would be contained in a special file that the browser manages. Users could update, add to, and manage their list of codecs by using a contol panel. For new codecs on the scene, a URL in the codec attribute would point the browser to a specific place on the internet where the new codec may be downloaded. This new codec would be cached (the browser would in this case identify the codec by the URL string), so it does not need to be repeatedly downloaded. The only trick here is that those organizations that wish to introduce new codecs would have to implement their codec URL in such a way as to make sure that the browser downloads the proper codec for the platform (OSX, WinXP, Vista, Linux, etc.) - so they would need to do some browser sniffing and offer up the proper codec to the browser based on its host platform. An example of this alternate method would be: video codec=http:/codecs.apple.com/quicktime src=myvideo.mpg/video The codec attribute could also be indicated in the stylesheet so you don't need to write the codec attribute for each reference on your site. - Jeff
Re: [whatwg] The issue of interoperability of the video element
So a company which owns a patent on a standard that can bought and read at freedom is just as bad as a company which owns a patent on a standard that has absolutely no public documentation? If you're talking about Ogg Theora, then you've got your facts wrong. First of all, Ogg Theora is not owned by a company. It is open source and sourceode is the best and most accurate public documentation you can get. And if you try google, you'll find a lot of additional documentation, such as this detailed explanation: http://www.xiph.org/theora/doc/Theora_I_spec.pdf and the Theora FAQ http://theora.org/theorafaq.html But I may have misunderstood what you were alluding to. Regards, Silvia.
Re: [whatwg] The issue of interoperability of the video element
On 6/25/07, Spartanicus [EMAIL PROTECTED] wrote: My main worry relates to the usability and accessibility of future audio and video web content. Content including the wrapping should be free, you don't quite mean that. if a content producer wants to make pay content, it should be free to do that too, no? There are huge industries which drive a large portion of the industrialized world based on a premise like this. Support in clients with a small market share like Opera and Safari is imo unlikely to be a significant consideration for content creators when deciding which encoding format to use. Unless they're targetting the mobile market which is basically dominated by Opera and WebKit (Safari and a Nokia derivative). (I'm excluding Pocket IE, I've never seen real people actually use it. And while I know the minimo team, I've never seen normal people use it either and I don't know of any devices that ship with it, so the market share there today is effectively 0). MS and Mozilla with their , combined ~95% of the market will probably determine what will be used. Again, this is dependent on the market. In Korea, the market says you must use IE because of the crypto layer. In the mobile market, the considerations are different. I can't speak for Nokia any more than Dave or any of the other Apple employees can speak for Apple, but shipping ogg is currently not an option. We tabled the ogg discussion a while ago, this advocacy is a huge waste of electronic bits. As for codec download urls, they really don't work. If I use iCab (npapi,macosx,ppc) and get sent to an ActiveX/w32/ia32 codec download url, it doesn't help me. And unfortunately even having the right browser (e.g. WMP10), when it does know the codec from the stream and does know where to phone home, it can still fail to find the relevant codec. Embedding the codec name into html is a non starter, the codec could change or authors could have no clue and will get it wrong. Opera and Safari will probably have to follow suit if they can. If IE and Mozilla support a common codec,
Re: [whatwg] The issue of interoperability of the video element
Hello, (Sorry if this gets posted twice.) On 6/25/07, timeless [EMAIL PROTECTED] wrote: On 6/25/07, Spartanicus [EMAIL PROTECTED] wrote: My main worry relates to the usability and accessibility of future audio and video web content. Content including the wrapping should be free, you don't quite mean that. if a content producer wants to make pay content, it should be free to do that too, no? There are huge industries which drive a large portion of the industrialized world based on a premise like this. I believe he means free as in freedom or liberty. And not free as in free of charge or gratis as you are using the word. The words look and are spelled the same but they have very very different meanings. Anything that is patent encumbered is NOT free as in freedom or liberty. But if you can get people to voluntarily pay for it, there's nothing that goes against the concept of freedom to do that. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ All the Vlogging News on One Page http://vlograzor.com/
Re: [whatwg] The issue of interoperability of the video element
On Sunday 24 June 2007 01:07, Silvia Pfeiffer wrote: Such a development is a clear sign to change the spec to require theora/vorbis support instead of just recommending it. A baseline codec has to be a requirement. Thus, I suggest to change the wording to User agents must support Theora video and Vorbis audio, as well as the Ogg container format. Or a clear sign that the video tag was doomed to failure anyway. I really can't imagine Microsoft or even Apple to let a multi-billion industry go, for the sake of implementing HTML5. Keeping it, or changing to wording will not change the behavior of Microsoft and Apple, but will only ensure that HTML5 will never become fully supported in the major browsers. `Allan
Re: [whatwg] The issue of interoperability of the video element
Allan Sandfeld Jensen [EMAIL PROTECTED] wrote: Thus, I suggest to change the wording to User agents must support Theora video and Vorbis audio, as well as the Ogg container format. Or a clear sign that the video tag was doomed to failure anyway. I really can't imagine Microsoft or even Apple to let a multi-billion industry go, for the sake of implementing HTML5. I've been struggling with the question what purpose the video element serves if interop isn't going to be achieved, which is the current state of affairs. Afaics as it stands the following codec support is likely: IE: Windows Media and possibly MPEG4 Apple: Quicktime and MPEG4 Opera: uncertain, but not likely to support Quicktime or Windows Media Mozilla: uncertain, but not likely to support Quicktime or Windows Media Afaics the currently most used way to serve video is through Flash. From a content provider's point of view Flash has very good client support, but the quality vs bitrate ratio isn't great. Flash is likely to improve on that latter point long before browser support for the video element will reach a level for content providers to consider using it. I understand the desire amongst browser manufacturers to support video content natively regardless of the above, but afaics native browser support will be irrelevant since content providers are unlikely to start serving content using the video element and continue using Flash. Keeping it, or changing to wording will not change the behavior of Microsoft and Apple, but will only ensure that HTML5 will never become fully supported in the major browsers. Support for the video element without a common codec may well become fully supported, but pointless. Consequently and with regret I favour removing video from the spec. -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
On 6/24/07, Spartanicus [EMAIL PROTECTED] wrote: Allan Sandfeld Jensen [EMAIL PROTECTED] wrote: Thus, I suggest to change the wording to User agents must support Theora video and Vorbis audio, as well as the Ogg container format. Or a clear sign that the video tag was doomed to failure anyway. I really can't imagine Microsoft or even Apple to let a multi-billion industry go, for the sake of implementing HTML5. I've been struggling with the question what purpose the video element serves if interop isn't going to be achieved, which is the current state of affairs. Afaics as it stands the following codec support is likely: IE: Windows Media and possibly MPEG4 Apple: Quicktime and MPEG4 Opera: uncertain, but not likely to support Quicktime or Windows Media Mozilla: uncertain, but not likely to support Quicktime or Windows Media Afaics the currently most used way to serve video is through Flash. From a content provider's point of view Flash has very good client support, but the quality vs bitrate ratio isn't great. Flash is likely to improve on that latter point long before browser support for the video element will reach a level for content providers to consider using it. I understand the desire amongst browser manufacturers to support video content natively regardless of the above, but afaics native browser support will be irrelevant since content providers are unlikely to start serving content using the video element and continue using Flash. Keeping it, or changing to wording will not change the behavior of Microsoft and Apple, but will only ensure that HTML5 will never become fully supported in the major browsers. Support for the video element without a common codec may well become fully supported, but pointless. Consequently and with regret I favour removing video from the spec. A video element that is natively part of html and has a standard set of API functions will enable applications that are impossible today, even with embedded elements such as flash. Imagine e.g. a mash-up of video extracts from several video hosting sites where you take an offset from each and put them together in a new video without having to manually edit that content. Only if all videos are in the same format and all hosting sites provide the same API will such a mashup be possible. I for one see the video and audio elements as one of the main novelties that make html5 important. If we put a requirement into the spec for a common baseline codec and the value of that can be demonstrated through several hosting sites - e.g. wikipedia, archive.org - and new applications will be demonstrated with the new video element - then I think there is a reason to go forward. In any case: plugins can be written for IE and for Safari that make them support Ogg Theora and the video tag, even if neither Microsoft nor Apple will be distributing them. And as a work-around at the beginning, java applets such as cortado enable Ogg Theora support even without a need for native support. Where there's a will, there's a way. We have to do what is right, not what is politically acceptable. Regards, Silvia.
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer [EMAIL PROTECTED] wrote: A video element that is natively part of html and has a standard set of API functions will enable applications that are impossible today, even with embedded elements such as flash. Imagine e.g. a mash-up of video extracts from several video hosting sites where you take an offset from each and put them together in a new video without having to manually edit that content. Only if all videos are in the same format and all hosting sites provide the same API will such a mashup be possible. I for one see the video and audio elements as one of the main novelties that make html5 important. You get no argument from me against the basic value of native browser support for video and audio, although imo the example you use is an edge use case and might not work in practice (with my limited knowledge of modern video encoding techniques I'm inclined to believe that the key frame nature of video formats will make it very difficult to splice encoded videos together). What I question is the practical value of specifying something that afaics will end up being useless for web deployment (controlled intranet usage could be possible). If we put a requirement into the spec for a common baseline codec and the value of that can be demonstrated through several hosting sites - e.g. wikipedia, archive.org - and new applications will be demonstrated with the new video element - then I think there is a reason to go forward. I'm uncomfortable with having a baseline codec. Even if IE would support a baseline codec, they are likely to also include a codec with a considerably better quality vs bitrate. Given their market share I fear that could result in a considerable number of content providers choosing to use the proprietary format. This would result in a schism in the availability of web content. I feel passionately that all public web content, be it text, images, audio, video or any other form should exclusively be made available using open, rights free encoding formats and transport protocols. This would result in lower quality encoding formats given the absence of commercial incentives to develop such formats and protocols, but the benefits far outweigh this drawback imo. In any case: plugins can be written for IE and for Safari that make them support Ogg Theora and the video tag, even if neither Microsoft nor Apple will be distributing them. Imo for content providers to choose video over Flash, client support needs to be close to Flash. Requiring IE and Safari users to go and download and install third party software to play content would imo be considered too much of a hindrance when Flash simply works. Where there's a will, there's a way. We have to do what is right, not what is politically acceptable. Frustrated as I am with the current state of affairs, I don't see any point in taking a principal stance if it will result in being ignored. -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
On 6/24/07, Silvia Pfeiffer [EMAIL PROTECTED] wrote: A video element that is natively part of html and has a standard set of API functions will enable applications that are impossible today, even with embedded elements such as flash. Imagine e.g. a mash-up of video extracts from several video hosting sites where you take an offset from each and put them together in a new video without having to manually edit that content. Only if all videos are in the same format and all hosting sites provide the same API will such a mashup be possible. I for one see the video and audio elements as one of the main novelties that make html5 important. If we put a requirement into the spec for a common baseline codec and the value of that can be demonstrated through several hosting sites - e.g. wikipedia, archive.org - and new applications will be demonstrated with the new video element - then I think there is a reason to go forward. In any case: plugins can be written for IE and for Safari that make them support Ogg Theora and the video tag, even if neither Microsoft nor Apple will be distributing them. And as a work-around at the beginning, java applets such as cortado enable Ogg Theora support even without a need for native support. Where there's a will, there's a way. We have to do what is right, not what is politically acceptable. I could not possibly put it in better words than this. Thank you, Silvia. The video and audio elements are one of the best things to have come out of HTML 5. If veiled interests from Microsoft and Apple may turn those elements useless, then something is clearly wrong. Are one or two corporations the ones who decide what will work and what will not work on the web? If so, then, there's no point to joint-ventures from the public and browser developers to create something like HTML 5, because it will never work unless Microsoft and Apple say so. If you people believe that, you may as well just forget about it. HTML 5 will never work. However, if we do try to get HTML 5 working on every browser, either by demand, or through programming those features ourselves (in the case of free software browsers) it's a step in the right direction. The more browsers supporting HTML 5, the more web designers/programmers will try to implement its new features on their work. We have to go against the tide. The faster we see some support of the HTML 5 features on browsers, the faster this process will work. And you have to keep in mind that video and audio are one of the most desired features for the general public. The same way they can show images, they can also show video and audio files? That's just a feature too awesome to let it go to waste! And the only way to make it work is for as many browsers as possible to choose a de facto standard for video and audio over the web. A consensus was reached in this list during the discussion of the video and audio elements. The majority ruled in favor of Theora and Vorbis. So should you. One or two corporations, in spite of their size, are not the ones running the web: we are. We can have video and audio working outside of Flash. We can have anyone host video or audio on their web site and make it work without the middle man, being it YouTube or any other video hosting web site. And you can only get this in the real world by having as many vendors supporting the Theora and Vorbis standards. Best regards, Ivo Emanuel Gonçalves
Re: [whatwg] The issue of interoperability of the video element
On 6/24/07, Spartanicus [EMAIL PROTECTED] wrote: Imo for content providers to choose video over Flash, client support needs to be close to Flash. Requiring IE and Safari users to go and download and install third party software to play content would imo be considered too much of a hindrance when Flash simply works. Cortado is a java applet that simply works (apart from a few bugs :) and provides Ogg Theora support to Web Browsers even now. There is no need to install third-party-software, apart from Java. For Flash video to work, you have to have the Flash plugin installed. For Cortado to work, you have to have Java installed. The install-base of Flash and Cortado is probably comparable. So, client support needs to be close to Flash can be fulfilled with a bit of effort. Regards, Silvia.
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer [EMAIL PROTECTED] wrote: Imo for content providers to choose video over Flash, client support needs to be close to Flash. Requiring IE and Safari users to go and download and install third party software to play content would imo be considered too much of a hindrance when Flash simply works. Cortado is a java applet that simply works (apart from a few bugs :) and provides Ogg Theora support to Web Browsers even now. There is no need to install third-party-software, apart from Java. For Flash video to work, you have to have the Flash plugin installed. For Cortado to work, you have to have Java installed. The install-base of Flash and Cortado is probably comparable. So, client support needs to be close to Flash can be fulfilled with a bit of effort. Personally I detest Java (resource hog, slow as wading through molasses) and don't have it installed, so forgive my potential ignorance. Why create an HTML video element with the express purpose of supporting video natively in clients if video needs to be coded as a Java applet with Java handling it? And didn't MS stop including their Java in recent OSs after they lost the court case with Sun? -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
On 6/25/07, Spartanicus [EMAIL PROTECTED] wrote: Personally I detest Java (resource hog, slow as wading through molasses) and don't have it installed, so forgive my potential ignorance. Don't we all hate java? ;-) Why create an HTML video element with the express purpose of supporting video natively in clients if video needs to be coded as a Java applet with Java handling it? No need to encode as a java applet - all you need to do is put the java applet on the server together with your Ogg Theora content. And - by all means - this is not supposed to be an end solution, but just a fix to bridge the gap until all Browsers support the baseline codec. The native support would always be preferential to any other fix. And didn't MS stop including their Java in recent OSs after they lost the court case with Sun? I don't know enough about this subject, but I believe that you always had to install a java VM to get java support in browsers (as you do with flash). Wasn't the problem with MS and Java rather one of lack of interoperability and standards conformance? I am well aware that the Java solution is not perfect and native support is heaps better. Therefore the need for the video element and for an interoperable version with a common baseline codec. Regards, Silvia.
Re: [whatwg] The issue of interoperability of the video element
On Jun 23, 2007, at 10:58 AM, Ivo Emanuel Gonçalves wrote: Dear WHATWG members, It has come to my attention that Apple developers behind the WebKit platform, which powers the web browser Safari, apparently intend to support the video element of the HTML 5 spec, section 3.14.7. It's all fine and well, but not a victory for web interoperability, as they do not intend to follow the User agents should support Theora video and Vorbis audio, as well as the Ogg container format part. In their own words: should support in a spec does not denote a requirement. We could have a perfectly suitable implementation of audio and video as seen in this draft spec without having theora/vorbis codecs available.[1] What this means, in my opinion, is that they will push for QuickTime video, in spite of the effort of the Opera developers to push Theora forward as the de facto standard for web video. Even if Mozilla and the KDE team prepare their web browsers to support Theora, by choosing to alienate it, Apple is allowing Microsoft to put WMV support alone in their Internet Explorer, for if Apple, one of the big players, shuns Theora, so will Microsoft. Considering the statistics, Internet Explorer being currently the web browser with bigger market share, it will force pretty much every web designer/programmer to stick to WMV only. Our current plan is to primarily support MPEG-4, including H.264/AVC video and AAC audio. We may support other codecs as well - it won't necessarily be the full set of codecs supported by QuickTime. This has been discussed to death already, but here are our basic reasons: - MPEG-4 is an ISO open standard (although unfortunately patent- encumbered). - Ogg Theora/Vorbis offers a royalty-free license for the few known patents, but we would assume additional risk of submarine patents if we supported it. - H.264 offers considerably better quality at the same bitrate than Theora/Vorbis. - H.264 is better for video delivery to limited-capability and low- power devices that support hardware video decoding. You may have heard that YouTube will be serving their video content as H.264 to AppleTV and iPhone. That's our current plan. We may revise it in light of future events, but it is unlikely that even a MUST-level requirement in the HTML spec would have much effect on whether we support Ogg or not. Regards, Maciej
Re: [whatwg] The issue of interoperability of the video element
On 6/25/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: Our current plan is to primarily support MPEG-4, including H.264/AVC video and AAC audio. We may support other codecs as well - it won't necessarily be the full set of codecs supported by QuickTime. This has been discussed to death already, but here are our basic reasons: - MPEG-4 is an ISO open standard (although unfortunately patent- encumbered). - Ogg Theora/Vorbis offers a royalty-free license for the few known patents, but we would assume additional risk of submarine patents if we supported it. - H.264 offers considerably better quality at the same bitrate than Theora/Vorbis. - H.264 is better for video delivery to limited-capability and low- power devices that support hardware video decoding. You may have heard that YouTube will be serving their video content as H.264 to AppleTV and iPhone. That's our current plan. We may revise it in light of future events, but it is unlikely that even a MUST-level requirement in the HTML spec would have much effect on whether we support Ogg or not. Thanks Maciej for summarising Apple's position so nicely. I think it's good that you have spelled it out: Apple is happy to support MPEG-4, which has known patent encumberance and unknown submarine patents, while Apple is not happy to support Ogg Theora/Vorbis which has no known patent encumberance. This has to be very clear to everybody. I also agree: H.264 procudes undoubtedly better quality video than Theora at the same bitrate. And I have no problem with Apple supporting H.264. In particular when I sign up e.g. for movie delivery through Apple, I'd be more than happy for H.264 delivery. But the open Internet/Web should be run on open technology. Also, on a side note, it is as yet unproven whether Ogg Theora or H.264 are better for video delivery to low-powered devices. In particular when considering the complexity of H.264 and the comparable simplicity of Theora - it may well be that an efficient HW implementation of Theora is better suited to low-powered devices than H.264. This is a matter of ongoing research development. BTW: don't expect the discussion to be gone just because the position of Apple has been made clear. As long as it doesn't make sense in the greater scheme of things, it will re-emerge. Even if it might not get resolved to the satisfaction of everybody. Regards, Silvia.
