Re: [whatwg] Chipset support is a good argument
As the Eolas or RIM cases show, patent trolls can wait for a very long time until they are sure that their victim has no way out. It does not prove that Theora is clean that Google has not been sued yet. IMHO, Chris
Re: [whatwg] Chipset support is a good argument
Small authors are hardly an alternative to YouTube because they use YouTube (or a similar service) to publish their content. Neither do YouTube publish most of the stuff on their own; they only allow the authors to do it using YT technology. In short, if you do not have the know-how to serve your video content, you will just use YouTube and never bother. And if you do have, you will not begin with reading the HTML specification either. IMHO, Chris
Re: [whatwg] Chipset support is a good argument
For those of you that are concerned whether Microsoft will support web video: Internet Explorer already does, albeit in the Microsoft WayT: * dynsrc Property (IMG, INPUT, INPUT type=image, ...) URL:http://msdn.microsoft.com/en-us/library/ms533742(VS.85).aspx :-)
Re: [whatwg] Chipset support is a good argument
2009/7/6 Kristof Zelechovski giecr...@stegny.2a.pl: Small authors are hardly an alternative to YouTube because they use YouTube (or a similar service) to publish their content. [snip] In short, if you do not have the know-how to serve your video content, you will just use YouTube and never bother. I am a small author and I have basic knowledge about how to encode a video. it's really not hard using a GUI frontend for ffmpeg2theora; it's pretty much only a matter of selecting a good compromise between encoding quality, resolution and bitrate, checking the result and trying again with different resolution or quality until you get what you want. You usually get subsequent videos right at the first try. But in the past I've used YouTube to host my videos because I don't have the know-how to write a Flash video *player* that works on different browsers, with workarounds for bugs that may crash old (but still widely used) versions of the plugin, alternative encodings for old plugins that don't support H.264, etc. The problem is not that I don't know how to encode a video, it's that I don't know how to write a video player that works as well as the YouTube one. I know that there are free ones around, but in my limited tests they don't work well with old Flash versions and are more complicated than a simple video tag. HTML5 solves this problem because now the player is embedded in the browser, so I started using video src=whatever.ogv and hiding the YouTube object blurb inside it as a fallback. This should work with every browser (except maybe Safari without XiphQT???), gives me the freedom to choose exactly the resolution I want and a bit of Independence from YT, which is good (think about cases like a troll flagging my videos: AFAIK YouTube automatically removes videos after a certain number of flags). With HTML5 video I can also get better quality because the videos don't have to go through two lossy encodings and I can also push the bitrate up a bit, since my website doesn't have a billion visitors each day. And if you do have, you will not begin with reading the HTML specification either. I did. And after reading it I decided to use the autoplay and controls attributes. Except the missing reference to Ogg/Theora, I found the spec much more informative and useful than other tutorials found on the interwebs that suggested using autoplay=false to disable autoplay (completely wrong, of course) or presented examples using WMV-encoded videos. Yes I'm talking about w3schools. ciao -- Lino Mastrodomenico
Re: [whatwg] Chipset support is a good argument
On Jul 6, 2009, at 12:52 AM, Lino Mastrodomenico wrote: HTML5 solves this problem because now the player is embedded in the browser, so I started using video src=whatever.ogv and hiding the YouTube object blurb inside it as a fallback. This should work with every browser (except maybe Safari without XiphQT???), gives me the freedom to choose exactly the resolution I want and a bit of Independence from YT, which is good (think about cases like a troll flagging my videos: AFAIK YouTube automatically removes videos after a certain number of flags). Here's an example of some markup that will work on a wide range of browsers, if you provide Ogg and MP4 versions of your video: http://camendesign.com/code/video_for_everybody . The MP4 version can be played either through video in browsers that support that, or by Flash or QuickTime or Windows Media Player. This actually results in video that works better in more browsers than Flash alone. (Personally I'd recommend putting the H.264 source first instead of last, so browsers that support both H.264 and Theora will pick the higher-quality video.) If you are willing to ignore IE and older browser versions, you can use the simpler markup here that just uses video with two sources: http://daringfireball.net/2009/07/ffmpeg2theora Regards, Maciej
[whatwg] Chipset support is a good argument
[to list as well, oops] -- Forwarded message -- From: David Gerard dger...@gmail.com Date: 2009/7/6 Subject: Re: [whatwg] Chipset support is a good argument To: Ian Hickson i...@hixie.ch 2009/7/6 Ian Hickson i...@hixie.ch: Given the volume of support Theora has gotten without it being in the spec, I don't see why putting it in HTML5 would have any effect on author demand. The demand already exists, and the customer pressure on Apple will rise as more and more sites make use of Theora. I don't see that the spec saying must...Theora would have any effect. This doesn't address the power of a should. If anything, I think it would be a negative effect, since it would mean that at least one thing in the spec was there despite it being known that one vendor is actively refusing to implement it (as opposed to just not having gotten to it yet). And then there's IE, of course. But if you were considering them, most of HTML5 wouldn't exist. - d.
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Kartikaya Gupta wrote: You've expressed something similar in a couple of the other threads as well, and I find it puzzling. It's true that if you spec things that will never be implemented, it harms the integrity of the spec. But on the other hand, if you allow any one vendor to determine what does or does not go into the spec [1], you're are exposing the spec to a much greater risk. What risk? In at least one other thread [2] you've implied that you treat all browser vendors as equal. If you put this together with the veto power it means that any browser vendor, regardless of size can get things axed from the spec. Am I missing something? What is stopping me from becoming a browser vendor and stating flat-out that I will not support any of the new additions in HTML5 just to kill off a good chunk of the spec? (Since I am working on a browser currently playing catch-up, this would certainly make my life easier). Nothing is stopping you from doing that. It seems to me that you need to either take away this veto power you've given browser vendors, or you need to draw a line between the vendors that do have veto power and the ones that don't. I haven't given browser vendors this veto power, they have it regardless. If implementors don't implement the spec, then the spec is fiction. There's nothing I can do about that. If you have already drawn such a line, I would like to know exactly where it is and what criteria were used to determine which vendors to allow and which ones to disallow. In practice, a browser vendor has to have an installed base of a percent or so overall before they can really affect the direction of the Web. This isn't a decision I have made myself. It's just how the world is. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
2009/7/6 Maciej Stachowiak m...@apple.com: Here's an example of some markup that will work on a wide range of browsers, if you provide Ogg and MP4 versions of your video: http://camendesign.com/code/video_for_everybody. The MP4 version can be played either through video in browsers that support that, or by Flash or QuickTime or Windows Media Player. This actually results in video that works better in more browsers than Flash alone. My first goal is to get as much as possible of my users to watch my videos, but my secondary goal is to do so in a way that encourages a sustainable video ecosystem on the web. I don't think that including an easy and always available fallback to H.264 gives Apple and Microsoft any incentive to support Theora or other free alternatives. Moreover, while MP3, MPEG-4 ASP and H.264 are entirely fine and widely used for pirated music and movies (which is illegal anyway), I prefer not to put any H.264-encoded file on my website, things like these scare me: http://www.streaminglearningcenter.com/articles/46/1/H264-Royalties-what-you-need-to-know/Page1.html and: http://www.streamingmedia.com/article.asp?id=11011page=1c=7 Apparently the MPEG LA has not yet decided if and how much they want me to pay from january 2011. I'm sorry if this sounds like FUD, but I will not use H.264 until is available without fees for the websites (guaranteed forever, not in a we-may-change-our-mind-anytime way) and with an open-source-like patent licence for encoding and decoding. I'm not asking to the MPEG LA to kill their business, they can sell a single patent licence to the open source/free software community for a ridiculously high price. Insanely high. If it's applicable to derived works, the community may well pay for it, and if it uses (for patents) terms similar to the ones that the GNU GPL uses (for copyright) then the MPEG LA will still be able to make more money by selling traditional lower-priced licences to proprietary software vendors. I hope they change their mind soon, but until the MPEG LA keeps H.264 captive, it's simply not an option for me as a web developer. (Personally I'd recommend putting the H.264 source first instead of last, so browsers that support both H.264 and Theora will pick the higher-quality video.) I use a high enough bitrate (roughly 0.2-0.25 bits per pixel, but it changes a lot depending on the material and the resolution) that most people can't tell the difference even on side-by-side comparisons. And if they did I don't want to penalize browsers that chose to support only Theora, since they IMO did the right thing for a sustainable future of the video on the web. Anyway I tried deinstalling XiphQT on my Mac and Safari doesn't play the YouTube fallback inside video, so I'll include a small JS that detects the situation and completely removes video leaving only the YT object (BTW, canPlayType in Safari 4.0 seems buggy: it always returns no, even with XiphQT installed). -- Lino Mastrodomenico
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Jonas Sicking wrote: On Sun, Jul 5, 2009 at 8:14 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: It's not the standard alone that makes it happen. The standard is for the general market neither a necessary nor a sufficient requirement for uptake. However, for the individual vendor, a standard and the perception that the market is adopting it will be a sufficient requirement to make a decision to create a product. Lacking the standard, just the perception that the market is adopting makes taking that decision just that much harder. I don't buy it. Nobody bases their business decisions on what specs say, they base them on what their customers and potential customers say they are going to spend money on. (Or the equivalent in the relevant market.) It's not the spec by itself that affects business decisions. It's the people that back the spec that does. Having names like W3C, Mozilla, Opera, Google, and the many other parties participating here officially get behind a HTML spec that endorses Theora sends a signal that this isn't just a buzz word, but something that is likely to stick around. Especially in the context of what the future of the web is going to look like. Even better would be if we can get names like Apple and Microsoft to endorse this too, but I don't think it stands and falls by having these endorsements right now. Especially since so far I see no reason that couldn't come later. Theora is already being endorsed by Mozilla, Opera, and Google; I don't think the incremental benefit of having the W3C spec mention Theora would offset the loss of having the spec move away from describing consensus. (For the same reason, I expect to split out the SQL stuff from Web Storage before Web Storage moves on. This seems like the same situation to me.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Sun, Jul 5, 2009 at 8:14 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: It's not the standard alone that makes it happen. The standard is for the general market neither a necessary nor a sufficient requirement for uptake. However, for the individual vendor, a standard and the perception that the market is adopting it will be a sufficient requirement to make a decision to create a product. Lacking the standard, just the perception that the market is adopting makes taking that decision just that much harder. I don't buy it. Nobody bases their business decisions on what specs say, they base them on what their customers and potential customers say they are going to spend money on. (Or the equivalent in the relevant market.) It's not the spec by itself that affects business decisions. It's the people that back the spec that does. Having names like W3C, Mozilla, Opera, Google, and the many other parties participating here officially get behind a HTML spec that endorses Theora sends a signal that this isn't just a buzz word, but something that is likely to stick around. Especially in the context of what the future of the web is going to look like. Even better would be if we can get names like Apple and Microsoft to endorse this too, but I don't think it stands and falls by having these endorsements right now. Especially since so far I see no reason that couldn't come later. / Jonas
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009 09:02:51 + (UTC), Ian Hickson i...@hixie.ch wrote: On Mon, 6 Jul 2009, Kartikaya Gupta wrote: You've expressed something similar in a couple of the other threads as well, and I find it puzzling. It's true that if you spec things that will never be implemented, it harms the integrity of the spec. But on the other hand, if you allow any one vendor to determine what does or does not go into the spec [1], you're are exposing the spec to a much greater risk. What risk? The risk I described below, where any one-man browser vendor can get a good chunk of the spec axed. In at least one other thread [2] you've implied that you treat all browser vendors as equal. If you put this together with the veto power it means that any browser vendor, regardless of size can get things axed from the spec. Am I missing something? What is stopping me from becoming a browser vendor and stating flat-out that I will not support any of the new additions in HTML5 just to kill off a good chunk of the spec? (Since I am working on a browser currently playing catch-up, this would certainly make my life easier). Nothing is stopping you from doing that. Seriously? If I were to declare that I, as a browser vendor, will not support anything in HTML5 that wasn't in HTML4, would you actually remove all the new additions from the HTML5 spec? It seems to me that you need to either take away this veto power you've given browser vendors, or you need to draw a line between the vendors that do have veto power and the ones that don't. I haven't given browser vendors this veto power, they have it regardless. No, the browser vendors don't make changes to the HTML5 spec. You do, since you're the editor. I'm not talking about indirect layers of abstraction where they influence what you write. I'm talking about the person who actually makes the cvs commits because when push comes to shove, that person is the one who is actually making the changes to the spec (or not making any change, as the case may be). If implementors don't implement the spec, then the spec is fiction. There's nothing I can do about that. Ah, but there *is* something you can do, and you're doing it. What you're doing to combat the spec from becoming fiction is saying if a browser vendor won't implement this, I will take it out of the spec. This works to keep the spec and reality in sync, and prevents the spec from becoming fiction. It also provides browser vendors the veto power I'm talking about. If you have already drawn such a line, I would like to know exactly where it is and what criteria were used to determine which vendors to allow and which ones to disallow. In practice, a browser vendor has to have an installed base of a percent or so overall before they can really affect the direction of the Web. This isn't a decision I have made myself. It's just how the world is. I'm not talking about the direction of the Web. I'm talking about the text that resides at http://www.whatwg.org/specs/web-apps/current-work/. The two are not the same thing. One is supposed to be a representation of the other, but that doesn't happen magically. You are that missing piece in the middle that is taking the real web and translating into the text at that URL. And as such, in the case of conflicting vendor behavior, you are the one that gets to decide which vendors you will take into account and which ones you will not. So let me re-ask my question: if a browser vendor has an installed base of greater than a percent or so, and they flat-out state they will not implement, e.g. all the new input types in HTML5, will you take them out of the spec? If the answer is yes, I would like specifics as to where that percent or so number comes from. There's lots of different ways people use to measure market share, which one are you using? kats
Re: [whatwg] Chipset support is a good argument
On Jul 6, 2009, at 3:00 AM, Lino Mastrodomenico wrote: (BTW, canPlayType in Safari 4.0 seems buggy: it always returns no, even with XiphQT installed). That was fixed just after Safari 4.0 shipped, it should work in WebKit nightly builds. See http://trac.webkit.org/changeset/43972. eric
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Kartikaya Gupta wrote: Seriously? If I were to declare that I, as a browser vendor, will not support anything in HTML5 that wasn't in HTML4, would you actually remove all the new additions from the HTML5 spec? Not immediately, but if you had notable market share and we could not convince you to implement these new features, then yes, I'd remove them and then work with you (and everyone else) to try to come up with solutions that you _would_ agree to. Even if you did not have notable market share, I would work with you to understand your objections, and try to resolve them. (Naturally if your goals are substantially different than the WHATWG's goals, then this might not go anywhere. For example, if Microsoft said that we should abandon HTML in favour of Silverlight, without making Silverlight backwards- compatible with HTML, then this would be somewhat of a non-starter, since backwards-compatibility is an underpinning of our work.) I'm not talking about the direction of the Web. I'm talking about the text that resides at http://www.whatwg.org/specs/web-apps/current-work/. The two are not the same thing. If they're not one and the same, then I'm not doing my job. So let me re-ask my question: if a browser vendor has an installed base of greater than a percent or so, and they flat-out state they will not implement, e.g. all the new input types in HTML5, will you take them out of the spec? Yes. If the answer is yes, I would like specifics as to where that percent or so number comes from. There's lots of different ways people use to measure market share, which one are you using? I haven't needed to exclude a browser vendor before, so this hasn't come up. In practice, it's any browser vendor that has enough influence that if they fail to implement something, it'll affect broad deployment of the feature. Generally speaking, that would be the browsers that are important enough for sites like Wikipedia to include in their reports, e.g. on: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers ...but again, so far I've not had to decline the feedback of any browser vendor, including a number that were much smaller than those on that page. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
Kartikaya Gupta wrote: I'm not sure whether specs can create demand, and frankly, I find it somewhat irrelevant to the point at hand. The fact is there is already demand for a single encoding format that will be compatible with as many browsers as possible. The only question is what that format will be. In this case, the spec doesn't need to create demand for anything, it just needs to tell people what that format is. The key point I think you've missed is that putting Theora (or H.264) as THE format in a specification won't make it so. One or the other codec is completely untenable under present circumstances to at least one major browser vendor. It is better that the specification reflect reality--that there is no such format, and there will not be one in the foreseeable future, than that it reflects a mythical utopia. Perhaps what could break the deadlock would be Apple conceding to implementing Theora, or Mozilla conceding to implementing H.264. In either case, the decision to implement would most likely be a result of market pressure, not some arcane specification. Browser vendors can and will ignore specifications if the burden of implementation does not match the value of having it. A lot of those authors (not major publishers like YouTube, but the long tail that includes everybody else) will not bother to read the details of the decision; they will simply assume that since it is in the standard it will soon be supported by all the major browsers, and they will make their choices and start publishing content with that in mind. I think you have a misconceived notion of the world here, too. Most of the HTML is not manually written by authors, it is automatically generated from programs, be it a Wiki-style generator, or a discrete utility like Dreamweaver. For the most part, those who write these programs--the people who will truly be writing and using the video tags--will be driven by what works in practice, not a statement in a specification that everyone ignores. 1) Do you agree with my view that specifying Theora for the video element would result in a self-fulfilling prophecy? In short, no. 2) Do you think that it is better to sit on the fence and not specify anything, thereby forcing authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats? Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec? Well, pursuant to the answer to question 1, the choice is either between lying about the reality in claiming something works when it does not or admitting that there is no right answer. Since one of the intents of HTML 5 is to codify the status quo, I think it would be living up to its goal in following the latter steps. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 7:30 PM, Joshua Cranmerpidgeo...@verizon.net wrote: Perhaps what could break the deadlock would be Apple conceding to implementing Theora, or Mozilla conceding to implementing H.264. In either case, the decision to implement would most likely be a result of market pressure, not some arcane specification. Given that Apple's only stated reason for not implementing Theora support alongside H.264 is the patent risk, and given that a company nearly as large as Apple (Google) has taken the risk and not gotten sued yet, I'm personally hoping that market pressure won't be necessary to get Apple to change its mind. Every other good argument I've heard advanced against Theora argues against supporting it as the only standard, but not against supporting it as a baseline minimal standard. I think you have a misconceived notion of the world here, too. Most of the HTML is not manually written by authors, it is automatically generated from programs, be it a Wiki-style generator, or a discrete utility like Dreamweaver. For the most part, those who write these programs--the people who will truly be writing and using the video tags--will be driven by what works in practice, not a statement in a specification that everyone ignores. As someone who does write one of those programs, I have to say it's remarkable how many people actually do want to pointlessly follow meaningless requirements of specifications. How many respectable web app packages *don't* slavishly include things like type=text/css so that the W3C validator will magically bestow conformance upon them? (Until the validator gets updated and they have to scramble to fix the new pointless things it covers.) How many have gone out of their way to eliminate table-based markup, because they heard it was bad practice -- and replaced it with divs and spans with presentational classes? I once did some quick manual hacking and determined that a MediaWiki page could have the size of its HTML source cut by 5% or so if you took out all the pointless stuff that XHTML 1 requires but HTML 5 permits you to omit. And that's comparing the *gzipped* files. Seriously. Keep in mind that all browsers simply ignore this garbage. The pages were totally identical after parsing (unless I messed up). That said, the above admittedly only applies if the specification does actually work in practice. But don't underestimate web app authors' desire to conform to standards, even ones that make no sense or that they don't understand.
Re: [whatwg] Chipset support is a good argument
On Sun, 5 Jul 2009, Eric Flores wrote: I agree with 80% of your reponses to the Codecs for audio and video conversation. However, I think that you are underestimating the influencing power of the spec with regarding to available hardware support. Hardcoding a spec in hardware is a very expensive and time consuming proposition. Chipmakers do not see an incentive to add a spec to their chips if they do not have guidance that provides them a roadmap. Even if some of the browsers choose not to follow the spec, it is good for everybody to have clarity on what is the recommended roadmap (whatever roadmap is decided). The point is that there is no decided roadmap. On the other side, I'm firmly convinced that some vested interest could lobby and even pay the chipmakers for having them not adding support to Ogg. This is a free market, isn't it? As you say, it's a free market. If people want Theora chips, then it's likely that they will become available. For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Definitively not as important as the above, I also have some reservations whenever you talk about alignment of 'all the players'. Are you really expecting agreements from ALL the players? Or just the big ones? I assume that you are disregarding the smallish browsers, aren't you? I'm talking primarily about the browser vendors who take part in this mailing list's discussions and have stated an opinion, regardless of size. Finally, it looks like Dirac looks worth discussing. I hope that their proponents do not drop the ball. Agreed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
2009/7/5 Ian Hickson i...@hixie.ch On Sun, 5 Jul 2009, Eric Flores wrote: [...] On the other side, I'm firmly convinced that some vested interest could lobby and even pay the chipmakers for having them not adding support to Ogg. This is a free market, isn't it? As you say, it's a free market. If people want Theora chips, then it's likely that they will become available. For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. I think that if Theora support is recommended in HTML5, this *will* generate demand, since content producers and (most) browser vendors alike will take advantage of it. Chips may well, in that scenario, become available. Sam
Re: [whatwg] Chipset support is a good argument
On Sun, 5 Jul 2009, Sam Kuper wrote: 2009/7/5 Ian Hickson i...@hixie.ch On Sun, 5 Jul 2009, Eric Flores wrote: [...] On the other side, I'm firmly convinced that some vested interest could lobby and even pay the chipmakers for having them not adding support to Ogg. This is a free market, isn't it? As you say, it's a free market. If people want Theora chips, then it's likely that they will become available. For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. I think that if Theora support is recommended in HTML5, this *will* generate demand, since content producers and (most) browser vendors alike will take advantage of it. Chips may well, in that scenario, become available. Most browser vendors are already implementing Theora, and content producers will use whatever the browser vendors support, regardless of whether it's in the spec or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson i...@hixie.ch wrote: For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Chipset support is a good argument
On Jul 5, 2009, at 3:41 PM, Robert O'Callahan wrote: On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson i...@hixie.ch wrote: For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. For H.264, a lot of the demand was created by the initial ISO/ITU standard and the follow-on standards for hardware products such as HD video disc players, set-to boxes and mobile phones. This was actually considerably earlier than H.264 deployment on the Web. For Microsoft's WMV to participate in some of the same markets, it had to go through a formal standards process, becoming SMPTE VC-1. SMPTE has also standardized Dirac Pro (a subset with no interframe compression) as VC-2. A spec for Theora through a formal standards process might more effectively focus latent demand than a mention in the HTML spec. It would also greatly clarify the patent situation, since many holders of wide-ranging patents on video compression participate in these groups. I've asked the Xiph folks if they'd be willing to take Theora to an organization such as SMPTE.[1] Regards, Maciej [1] http://lists.xiph.org/pipermail/theora/2009-July/002418.html
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 11:00 AM, Maciej Stachowiak m...@apple.com wrote: A spec for Theora through a formal standards process might more effectively focus latent demand than a mention in the HTML spec. You may be right, but that is an orthogonal issue. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 8:41 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson i...@hixie.ch wrote: For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. Silvia.
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Robert O'Callahan wrote: Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. I disagree with both these statements, I don't think they are in fact accurate. Demand can be focused around a specification if one exists, but a specification cannot create demand, and the lack of a specification is not an impediment to deployment. We have seen both facets of this repeatedly demonstrated through the lifetime of the Web, not least of which by HTML itself. Indeed, cutting features that didn't have demand despite being in HTML4 for a decade is one of HTML5's achievements. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 9:00 AM, Maciej Stachowiakm...@apple.com wrote: On Jul 5, 2009, at 3:41 PM, Robert O'Callahan wrote: On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson i...@hixie.ch wrote: For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. For H.264, a lot of the demand was created by the initial ISO/ITU standard and the follow-on standards for hardware products such as HD video disc players, set-to boxes and mobile phones. This was actually considerably earlier than H.264 deployment on the Web. For Microsoft's WMV to participate in some of the same markets, it had to go through a formal standards process, becoming SMPTE VC-1. SMPTE has also standardized Dirac Pro (a subset with no interframe compression) as VC-2. A spec for Theora through a formal standards process might more effectively focus latent demand than a mention in the HTML spec. It would also greatly clarify the patent situation, since many holders of wide-ranging patents on video compression participate in these groups. I've asked the Xiph folks if they'd be willing to take Theora to an organization such as SMPTE.[1] I don't think putting it through SMPTE will magically create hardware support. VC-1 and VC-2 didn't magically get hardware support through being standardised by SMPTE. It is a combination of standardisation and uptake that will get the confidence for the market. I think the W3C is in a much better position to achieve this right now than the SMPTE. Which standards body adopts it doesn't make much of a difference to the market. Don't get me wrong though: I don't have anything against putting Theora through SMPTE - if SMPTE would indeed accept such a submission. I could imagine SMPTE be interested in it for digital TV type transmissions, e.g. for picture-in-picture in combination with VC-1 or VC-2. But the SMPTE process will take a minimum of 2 years and a dedicated person to travel to meetings, prepare the extensive paperwork required, and lobby the SMPTE members - an expense that Xiph is simply not in a position to fund. Also, the documentation required for a standard is already available: a open specification, an open reference implementation, test data, and a validation approach. So, it would be a rather expensive experiment just to get political support from the TV folks. The only thing that SMPTE would probably add is a call for patent holders to come forward now. This is something that the W3C can do, too. If widely enough publicized, it should bring the risk down. Please note that this is my personal opinion and not Xiph's official stance. Regards, Silvia.
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 11:44 AM, Ian Hicksoni...@hixie.ch wrote: On Mon, 6 Jul 2009, Robert O'Callahan wrote: Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. I disagree with both these statements, I don't think they are in fact accurate. Demand can be focused around a specification if one exists, but a specification cannot create demand, and the lack of a specification is not an impediment to deployment. We have seen both facets of this repeatedly demonstrated through the lifetime of the Web, not least of which by HTML itself. Indeed, cutting features that didn't have demand despite being in HTML4 for a decade is one of HTML5's achievements. It's not the standard alone that makes it happen. The standard is for the general market neither a necessary nor a sufficient requirement for uptake. However, for the individual vendor, a standard and the perception that the market is adopting it will be a sufficient requirement to make a decision to create a product. Lacking the standard, just the perception that the market is adopting makes taking that decision just that much harder. Regards, Silvia.
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 1:44 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 6 Jul 2009, Robert O'Callahan wrote: Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. I disagree with both these statements, I don't think they are in fact accurate. Demand can be focused around a specification if one exists Specs can't create author demand for features that authors don't actually want, but if authors want a general feature (say, simple CSS animations) then having an implementation of that feature creates demand for that particular incarnation of the feature, and giving it the CSS WG imprimatur increases demand further. Some authors want a royalty-free video codec. We have an implementation, Theora. I believe linking HTML5 to it would increase author demand for it to be supported in all browsers, and help those authors make a stronger case. If I didn't think so, I wouldn't be wasting my time here. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: It's not the standard alone that makes it happen. The standard is for the general market neither a necessary nor a sufficient requirement for uptake. However, for the individual vendor, a standard and the perception that the market is adopting it will be a sufficient requirement to make a decision to create a product. Lacking the standard, just the perception that the market is adopting makes taking that decision just that much harder. I don't buy it. Nobody bases their business decisions on what specs say, they base them on what their customers and potential customers say they are going to spend money on. (Or the equivalent in the relevant market.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Robert O'Callahan wrote: Some authors want a royalty-free video codec. We have an implementation, Theora. I believe linking HTML5 to it would increase author demand for it to be supported in all browsers, and help those authors make a stronger case. Given the volume of support Theora has gotten without it being in the spec, I don't see why putting it in HTML5 would have any effect on author demand. The demand already exists, and the customer pressure on Apple will rise as more and more sites make use of Theora. I don't see that the spec saying must...Theora would have any effect. If anything, I think it would be a negative effect, since it would mean that at least one thing in the spec was there despite it being known that one vendor is actively refusing to implement it (as opposed to just not having gotten to it yet). If I didn't think so, I wouldn't be wasting my time here. I have no doubt that you are arguing in good faith. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Sun, 5 Jul 2009, Eric Flores wrote: The point is that there is no decided roadmap. There was one, and has been recently dropped. Actually there has never been a roadmap on this issue. My point is that thinking that the free market will solve the issue by any of the two routes that you stated is even more unrealistic than assuming that Apple will implement Theora just because it is part of the spec. Apple has said they won't implement Theora regardless of whether it's in the spec or not. I agree though that it might be that the two outcomes I describe are also unlikely. Apple will not change their format even if the rest of the world uses any other thing. On the other side, the silent giant will not support anything other than their WMV and WMA format. Even if Apple and Mozilla reach an agreement, what will we do once Microsoft decides to speak up? Yes, I know the response. I don't. I wish Microsoft would speak up, as that might help tilt the balance one way or the other. Having a preferred format tips the balance for the chipmakers to make a decision, and in the case of Theora, helps to stir discussion about the supposed hidden patents. I agree entirely. It is sad that we can't find one. Theora might not be the best. But is the best that we have. We don't even have Theora right now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Kartikaya Gupta wrote: 1) Do you agree with my view that specifying Theora for the video element would result in a self-fulfilling prophecy? No. I don't think it would make any difference to what browsers implement, and as far as I can tell, what browsers implement is the only thing that affects what authors adopt. 2) Do you think that it is better to sit on the fence and not specify anything, thereby forcing authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats? I don't think it makes any difference whether we specify something or not; if the browsers aren't all going to implement the same thing, then that is what is going to force authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats. Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec? I think it would be harmful to spec something that is actively different than what a browser vendor will implement. This is why HTML5 started -- because the W3C wrote specs that were idealistic and did not match reality. My view with regards to question (2) above is that one way or another, the web will settle on a single encoding format. This can be done the easy way or the hard way. The hard way is to not specify anything, and let authors and vendors battle it out for years at everybody's expense, leaving a trail of carnage and cruft behind that will then need to supported for decades. The easy way is to specify something and cross your fingers. Even if it doesn't work, at worst it will just prolong an already long and bloody battle. The benefits from the best-case scenario make the risk more than worth it. We already know what Apple will do if we put Theora in the spec. They'll ignore it. So it will not make any difference one way or the other as far as video is concerned. It will, however, mean that HTML5 is less in line with what authors can actually rely on. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Ian Hickson wrote: On Mon, 6 Jul 2009, Robert O'Callahan wrote: Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. I disagree with both these statements, I don't think they are in fact accurate. Demand can be focused around a specification if one exists, but a specification cannot create demand, and the lack of a specification is not an impediment to deployment. We have seen both facets of this repeatedly demonstrated through the lifetime of the Web, not least of which by HTML itself. Indeed, cutting features that didn't have demand despite being in HTML4 for a decade is one of HTML5's achievements. I'm not sure whether specs can create demand, and frankly, I find it somewhat irrelevant to the point at hand. The fact is there is already demand for a single encoding format that will be compatible with as many browsers as possible. The only question is what that format will be. In this case, the spec doesn't need to create demand for anything, it just needs to tell people what that format is. I believe that if HTML5 specified Theora, that would become a self-fulfilling prophecy, and Theora would become the standard (both specified and actual) of the web. There's already been a huge amount of press (on Slashdot, OSNews, Ars Technica, etc.) about the debate on this list. If a decision were to be made in favor of Theora, that would immediately be broadcast by the same channels and a lot of people (including actual and potential web authors) would be aware of it. A lot of those authors (not major publishers like YouTube, but the long tail that includes everybody else) will not bother to read the details of the decision; they will simply assume that since it is in the standard it will soon be supported by all the major browsers, and they will make their choices and start publishing content with that in mind. Since there is already some browser support for it, those efforts won't just fizzle and die. As there is an increase of Theora-encoded content, support for it will increase (including in terms of hardware) and it will drive a virtuous cycle pushing Theora to be even more widespread. In a nutshell, what I'm thinking is that putting Theora in the HTML5 spec would not be enough to magically get authors to start generating Theora-encoded content. It is, however, enough to make authors in the process of deciding between H.264 and Theora for their video content to pick Theora. It's just a little push, but that little push is enough to make all the difference. Now, I suppose all of the above may hold for H.264 instead of Theora, but I think it is far less likely given the distribution of vendors and their reasons for being in favor of a particular codec. If you disagree, that's fine. Just replace all instances of Theora with H.264 and read on. I'm also ignoring the Dirac possibility which has been mentioned a few times but doesn't seem to be being actively pursued. If that satifies everybody, so much the better. So, my questions to you are: 1) Do you agree with my view that specifying Theora for the video element would result in a self-fulfilling prophecy? 2) Do you think that it is better to sit on the fence and not specify anything, thereby forcing authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats? Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec? My view with regards to question (2) above is that one way or another, the web will settle on a single encoding format. This can be done the easy way or the hard way. The hard way is to not specify anything, and let authors and vendors battle it out for years at everybody's expense, leaving a trail of carnage and cruft behind that will then need to supported for decades. The easy way is to specify something and cross your fingers. Even if it doesn't work, at worst it will just prolong an already long and bloody battle. The benefits from the best-case scenario make the risk more than worth it. kats
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009 04:06:25 + (UTC), Ian Hickson i...@hixie.ch wrote: On Mon, 6 Jul 2009, Kartikaya Gupta wrote: Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec? I think it would be harmful to spec something that is actively different than what a browser vendor will implement. This is why HTML5 started -- because the W3C wrote specs that were idealistic and did not match reality. You've expressed something similar in a couple of the other threads as well, and I find it puzzling. It's true that if you spec things that will never be implemented, it harms the integrity of the spec. But on the other hand, if you allow any one vendor to determine what does or does not go into the spec [1], you're are exposing the spec to a much greater risk. In at least one other thread [2] you've implied that you treat all browser vendors as equal. If you put this together with the veto power it means that any browser vendor, regardless of size can get things axed from the spec. Am I missing something? What is stopping me from becoming a browser vendor and stating flat-out that I will not support any of the new additions in HTML5 just to kill off a good chunk of the spec? (Since I am working on a browser currently playing catch-up, this would certainly make my life easier). It seems to me that you need to either take away this veto power you've given browser vendors, or you need to draw a line between the vendors that do have veto power and the ones that don't. If you have already drawn such a line, I would like to know exactly where it is and what criteria were used to determine which vendors to allow and which ones to disallow. One of the failings of HTML5, IMHO, is that it is trying to both document existing behavior and spec new features. These two activities should use different processes with regard to vendor consensus, but they are instead getting lumped together, and the new features are getting stifled as a result. kats [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020722.html, your replies to Anne [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020747.html
