[whatwg] Removal of Ogg is *preposterous*
Allow me to be the voice of the small Web developer -- which I consider to be the foundation of the World Wide Web. In reference to: http://html5.org/tools/web-apps-tracker?from=1142to=1143 The recent removal of the mention of Ogg in HTML5 and the subsequent replacement of its paragraph with the weasel-worded paragraph that would make Minitrue bust their collective shirt buttons in pride: p class=big-issueIt would be helpful for interoperability if all+ browsers could support the same codecs. However, there are no known+ codecs that satisfy all the current players: we need a codec that is+ known to not require per-unit or per-distributor licensing, that is+ compatible with the open source development model, that is of+ sufficient quality as to be usable, and that is not an additional+ submarine patent risk for large companies. This is an ongoing issue+ and this section will be updated once more information is+ available./p is a preposterous and gross mischaracterization of fact (dare I say lie). At the very least, it's FUD. It pains me to state what is and has always been public knowledge, and is being intentionally ignored just to get the spec published: - The Xiph developers were extremely zealous and almost fiduciarily diligent in researching all possible patent threats to Vorbis technology, and for more than a year they found none -- they even did the research *before* beginning to code, explicitly to avoid submarine patents. I know, because I was subscribed to their mailing list and read status updates of this research, practically at the start of the project. I also know that big-name software houses and media players manufacture products with Vorbis technology, and none of them have been sued. It's been what, seven years now? - The Theora codec has had its patents practically relinquished by On3 with a perpetual royalty-free license. - Ogg and its audio/video codec technologies are the ONLY free software media technologies with implementations widely available on all consumer computing platforms -- from WM codecs to Linux DLLs, passing through the entire range of hardware (floating-point and fixed-point) and OSes. - Without guaranteed Ogg support (whose integration in user agents I think I already established to be sort of a weekend-level junior programmer project at NO COST, due to the ready availability of the technology in all platforms), authors *will be* forced to use patent-encumbered technology. Remember MP3? Well, with HTML5 it's 1997 all over again. Ian, revert. This compromise on basic values is unacceptable, *whatever* the practical reasons you have deemed to compromise for. If you don't revert, you will be giving us independent authors the shaft. And we will remember it forever. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Someone is speaking well of you. signature.asc Description: This is a digitally signed message part.
Re: [whatwg] Removal of Ogg is *preposterous*
I'm sure that many people would be happy to see a mandate if someone were willing to offer an indemnity against risk here. You seem quite convinced there is no risk; are you willing to offer the indemnity? Large companies (Nokia, Microsoft, and Apple) have expressed anxiety, and are asking (among other things) that an independent analysis be done. The W3C staff are, I believe, actively working on the issue. I'm sure that they would be pleased to consider whatever background material you can offer them. I fail to see how asking for an analysis of the problem is giving anyone the shaft, since no decision has yet been even offered let alone reached. Did you read the piece that I edited from the discussions at the HTML meeting? At 3:27 -0500 11/12/07, Manuel Amador (Rudd-O) wrote: Allow me to be the voice of the small Web developer -- which I consider to be the foundation of the World Wide Web. In reference to: http://html5.org/tools/web-apps-tracker?from=1142to=1143 The recent removal of the mention of Ogg in HTML5 and the subsequent replacement of its paragraph with the weasel-worded paragraph that would make Minitrue bust their collective shirt buttons in pride: p class=big-issueIt would be helpful for interoperability if all+ browsers could support the same codecs. However, there are no known+ codecs that satisfy all the current players: we need a codec that is+ known to not require per-unit or per-distributor licensing, that is+ compatible with the open source development model, that is of+ sufficient quality as to be usable, and that is not an additional+ submarine patent risk for large companies. This is an ongoing issue+ and this section will be updated once more information is+ available./p is a preposterous and gross mischaracterization of fact (dare I say lie). At the very least, it's FUD. It pains me to state what is and has always been public knowledge, and is being intentionally ignored just to get the spec published: - The Xiph developers were extremely zealous and almost fiduciarily diligent in researching all possible patent threats to Vorbis technology, and for more than a year they found none -- they even did the research *before* beginning to code, explicitly to avoid submarine patents. I know, because I was subscribed to their mailing list and read status updates of this research, practically at the start of the project. I also know that big-name software houses and media players manufacture products with Vorbis technology, and none of them have been sued. It's been what, seven years now? - The Theora codec has had its patents practically relinquished by On3 with a perpetual royalty-free license. - Ogg and its audio/video codec technologies are the ONLY free software media technologies with implementations widely available on all consumer computing platforms -- from WM codecs to Linux DLLs, passing through the entire range of hardware (floating-point and fixed-point) and OSes. - Without guaranteed Ogg support (whose integration in user agents I think I already established to be sort of a weekend-level junior programmer project at NO COST, due to the ready availability of the technology in all platforms), authors *will be* forced to use patent-encumbered technology. Remember MP3? Well, with HTML5 it's 1997 all over again. Ian, revert. This compromise on basic values is unacceptable, *whatever* the practical reasons you have deemed to compromise for. If you don't revert, you will be giving us independent authors the shaft. And we will remember it forever. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Someone is speaking well of you. Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Attachment converted: DaveG49:signature 96.asc (/) (001050A8) -- David Singer Apple/QuickTime
Re: [whatwg] Removal of Ogg is *preposterous*
On Tue, 11 Dec 2007, Manuel Amador (Rudd-O) wrote: http://html5.org/tools/web-apps-tracker?from=1142to=1143 The recent removal of the mention of Ogg in HTML5 and the subsequent replacement of its paragraph with the weasel-worded paragraph that would make Minitrue bust their collective shirt buttons in pride: p class=big-issueIt would be helpful for interoperability if all+ browsers could support the same codecs. However, there are no known+ codecs that satisfy all the current players: we need a codec that is+ known to not require per-unit or per-distributor licensing, that is+ compatible with the open source development model, that is of+ sufficient quality as to be usable, and that is not an additional+ submarine patent risk for large companies. This is an ongoing issue+ and this section will be updated once more information is+ available./p is a preposterous and gross mischaracterization of fact (dare I say lie). At the very least, it's FUD. It is intended to be exactly truthful, actually. I apologise if you believe this to be fear mongering. It pains me to state what is and has always been public knowledge, and is being intentionally ignored just to get the spec published: - The Xiph developers were extremely zealous and almost fiduciarily diligent in researching all possible patent threats to Vorbis technology, and for more than a year they found none -- they even did the research *before* beginning to code, explicitly to avoid submarine patents. While this is very true, and admirable, and impressive, it is sadly not a guarantee. Certain companies (Nokia and Apple among them) have reported that they still fear that undisclosed patents may exist that cover the relevant codecs, as they might exist for other formats like MPEG4/H.264. The difference is that while Apple (for example) have already assumed the risk of submarine patents with H.264, they currently have taken no risks with respect to the aforementioned codecs, and they do not wish to take on that risk. Given the extremely large sums of money that are awarded for patent violations (cf. Microsoft's recent settlements), it is understandable that companies with the high profile of Apple and Nokia would not wish to take on such risks. I also know that big-name software houses and media players manufacture products with Vorbis technology, and none of them have been sued. It's been what, seven years now? MP3 is and old codec as well, yet the threat of submarine patents covering MP3 surfaced recently, much to Microsoft's chagrin. Unless the codecs are older than the patent lifetime, there is unfortunately no guarentee. Patent trolling companies are patient and will wait for bigger targets, as has been seen time and time again. (As an example of this, the Eolas patent case is still fresh on everyone's minds, I'm sure.) - The Theora codec has had its patents practically relinquished by On3 with a perpetual royalty-free license. I do not believe anyone doubts that On3 is acting in good faith. It is not On3 that people are worried about. - Ogg and its audio/video codec technologies are the ONLY free software media technologies with implementations widely available on all consumer computing platforms -- from WM codecs to Linux DLLs, passing through the entire range of hardware (floating-point and fixed-point) and OSes. As much as I am personally a supported of the free software development model, I cannot let that control the spec's development. I agree, however, that any codec selected absolutely must be compatible with free software licenses, as is clear in the paragraph that you so rashly called FUD. - Without guaranteed Ogg support (whose integration in user agents I think I already established to be sort of a weekend-level junior programmer project at NO COST, due to the ready availability of the technology in all platforms), authors *will be* forced to use patent-encumbered technology. Remember MP3? Well, with HTML5 it's 1997 all over again. Ogg is not necessarily the only solution that avoids patent encumbrence. There are codecs that have been in existence for longer than the patent lifetime, for instance. Dave Singer posted a quite thorough analysis of this issue recently. Ian, revert. This compromise on basic values is unacceptable, *whatever* the practical reasons you have deemed to compromise for. If you don't revert, you will be giving us independent authors the shaft. And we will remember it forever. Apple, Nokia, Microsoft and other large companies have stated that they will not support Theora purely based on the requirement in the spec. Having or not having this requirement in the spec thus makes no difference to independent authors. In the meantime, having this requirement is causing difficulties for those of us actually trying to find a true solution to the problem. I assure you that your needs are not being
Re: [whatwg] Time and Date (was: Joe Clark's Criticisms of the WHATWG and HTML 5)
On Fri, 23 Mar 2007, Colin Lieberman wrote:
Matthew Raymond wrote:
I support the time element for the opposite reason, in fact. I don't
want to see authors styling the date format. I'd rather see the date
format localized or customized to a user preference. If the author
wants it in a specific format, they can use CSS to style the element
in such a way as to show its contents:
HTML:
| time datetime=-MM-DD(*)???;YY;D???(*)/time
CSS (using css3-content):
| time { content: contents; }
I agree to a point. Time and date should be machine readable in markup,
but I don't know if UAs should *default* to user preference over-riding
the author's chosen format.
My argument here is cultural or sociological - If, in 10 years, kids
grew up only ever seeing dates presented in one format, they wouldn't
learn about how dates work elsewhere. This seems like a small thing, but
I think the flavor of dealing with varieties of date formats is just one
way that we get to participate in a really cool, big world full of lots
of different people.
I think it is highly unlikely that time would be so successful as to
hide all other date formats from users. Would we only be so lucky!
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] address markup (was: Re: time and meter elements)
On Tue, 11 Dec 2007 11:03:17 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 13 Feb 2007, Matthew Raymond wrote: A name element may have some uses, such as providing a hook for adding people to your contact list: | address | nameJohn Hopkins/namebr | Phone: (359) 555-1701 | /address Notwithstanding what I consider misuse of br in that example, I would encourage people to use hCard to mark up a name instead of us introducing an element for the purpose. How would you mark that up instead? address (currently) doesn't allow block-level descendents. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
(Despite the subject line, this thread quickly veered way from Joe's blog post and instead covered a variety of subjects. I have attempts to address the points that had substance and may affect the spec in my replies below. Please let me know if I missed something in this thread that you believe should have resulted in a change to the spec.) On Thu, 22 Mar 2007, Henri Sivonen wrote: FWIW, I think samp and kbd don't deserve to be in HTML and I am not convinced that the use cases for var could not be satisfied by i. I'm lukewarm on all three, but the cost to keeping these is probably slightly less than the cost to removing them, so I'm tending towards keeping them... I tend to agree. But then they should not be used as a basis for arguing anything about the design of HTML5 or as bases for analogies for including new semantic elements of similar kind. Agreed. The CSS community has requested a date or time element because they want to restyle dates and times according to locale. I tend to think that this has huge potential for people getting confused and missing appointments. Time zones are impractical and confusing enough without DWIM changing them. Sorry, by locale I just meant the syntax, not the time zone. Also, the aforementioned research indicated that there are substantial amounts of content on the Web that uses invented elements, IDs, and class attributes to mark up dates and times. For example, I found about the same number of pages with the obscure ID updatedtime as I did pages with a button element; date was the 14th most frequently seen class name. However, merely marking up something as *a* date without knowing *what* date is not particularly interesting. (Compare with the fluffiness of Dublin Core.) Well, it helps a little -- microformats for example add the what using their own semantics, and CSS doesn't need the what to decide on the how (to present). I'm inclined to think that the cite element is useless. i could be used for marking up titles of works and b could be used for magazine and newspaper-style marking up of first instance of personal names. I have yet to see a markup consumption use case that would work on the public Web and would use cite. cite is used more than button. It's used almost as often as h6. One of the reasons for keeping var, cite, em, etc, separate, instead of saying that authors should just use i for all of them, is that it makes styling them differently much easier. Assuming, of course, that you want to style them differently instead of just italicizing all of them. This seems common enough to keep them, given the arguments listed at the top of this e-mail. I am still on the fence about using cite in my thesis. Currently I am using it to mark up titles of works. Any advice as to what the specshould say on the matter is welcome; in fact I have a whole folder of such advice that I'll be addressing in due course. (Why is i class=var better than var?) It isn't. But i is better than var for editor UIs if all you want to do is to italicize (the common case). Granted, and i is allowed. It is semantically less precise, but that doesn't necessarily matter. | * note and reference for footnotes, endnotes, and sidenotes | (not aside in �HTML5�) Yes, this is an area where document and converter authors currently need to come up with their own class-based hacks. Ideally a continuous media user agent could show footnotes in context so that they don't become de facto endnotes. If anyone has any ideas on this, please post them to the list. (The CSS group is also looking at footnotes closely.) One thing to consider when looking at footnotes is would the title= attribute handle this use case as well as what I'm proposing?. If the answer is yes, or almost, then it's probably not a good idea to introduce the new feature. I am not happy with title='' for footnotes. First, there are all the usual objection against putting natural-language text in attributes. Agreed. Second, tooltips (the typical screen media presentation of title='') have significantly different properties compared to print footnotes when it comes to reader attention. Tooltips aren't very discoverable and are inconvenient to read. Footnotes, on the other hand, are rather easy to read. Moreover, footnotes containing prose (as opposed to just URIs or other identifier data) actually work as a device for emphasizing stuff that the author pretends to de-emphasize while knowing that (s)he is really emphasizing. Tooltips don't work like this. I remember reading somewhere (I forget where) that many people read the footnotes first when they turn a new page in a book. This is why I'd be interested in being able to turn asides into footnotes in print. CSS is working to improve support for
Re: [whatwg] simple numbers
While I think there is certainly something to be said for the proposal, I don't think there is enough evidence that authors really want or need this. I think we should focus on having CSS support this first. Maybe we could think about a general purpose element which allows formating for regionalisation of values. Example for datetimes. Consider an application where you have the timezone of your users, you have to pan the date accordingly to the timezone of the user, and you have to do this server side. Besides, if it's a public site and you don't have timezones of your users, you will only display a datetime that will match the server's system date. If we could have a tag that takes a UTC/GMT and format it accordingly to client system dates and his system/browser preference ( dd/mm/, yy/mm/dd, mm/dd/, ) we would get rid of a problem all web developpers came across. I think that it would be a good thing to have a data regionalisation tag that would allow to display dates, datetimes, numbers, currencies, ... tag type=datetimeTue, 11 Dec 2007 10:57:14 GMT/tag format could be overridden tag type=datetime format=/mm/dd HH:MMTue, 11 Dec 2007 10:57:14 GMT/tag tag type=number251234565455.26/tag or even a styles like declaration ? tag format=type: currency; decimals: 2251234565455.2654656/tag $ Anyway, I think it's worth discussing about this because it would be a good think for usability of browsers. If this is implemented, we will see a cool extension for Firefox 7.0 that will allows to convert foreign currencies on the fly on websites. -- Fabien Meghazi Website: http://www.amigrave.com Email: [EMAIL PROTECTED] IM: [EMAIL PROTECTED]
Re: [whatwg] Removal of Ogg is *preposterous*
Ian Hickson schrieb: The difference is that while Apple (for example) have already assumed the risk of submarine patents with H.264, they currently have taken no risks with respect to the aforementioned codecs, and they do not wish to take on that risk. Which surely means that they won't ever support any new codecs or new features at any point in the future. This would be the only way to stop adding new risks. I totally understand that companies want to keep their risks low. If this gets abused as cheap excuse as why they won't support anything but their pet-formats things are getting pretty shallow, though. If patents are such a threat to big companies they better should drive serious efforts to get the patent lottery into a more sane state or they innovation potential is endangered. As much as I am personally a supported of the free software development model, I cannot let that control the spec's development. I agree, however, that any codec selected absolutely must be compatible with free software licenses, as is clear in the paragraph that you so rashly called FUD. The problem is that the requirements describe the emtpy set, as is correctly described with However, there are no known codecs that satisfy all the current players. MPEG codecs are non-free, incompatible with free software and are carrying additional submarine risks for all those who haven't yet licensed them. The requirements ask for codecs that are not an additional submarine patent risk for large companies. What about small companies? Why should e.g. Opera or Mozilla want to license MPEG and be subject of MPEG submarines instead of choosing codecs that were designed to avoid patents since the initial planning stages? I guess it may appear to be more desirable to take the submarine risk of free codecs and in exchange get all the benefits of not getting into the IP licensing mess. To put it into a nutshell: To respect the needs of the big players for sure is important - but same shall apply to the needs of the not-so-big ones. I know you don't intend anything else, but the current wording may be a bit unfortunate. There are codecs that have been in existence for longer than the patent lifetime, for instance. Dave Singer posted a quite thorough analysis of this issue recently. I doubt those old codecs can help implementing video and audio functionality in a way satisfying current demands. I can't imagine streaming e.g. audio with ADPCM or GSM ;-) Maik
Re: [whatwg] simple numbers
On Dec 11, 2007 12:28 PM, Andy Mabbett [EMAIL PROTECTED] wrote: tag type=datetime format=/mm/dd HH:MMTue, 11 Dec 2007 10:57:14 GMT/tag Neither of those encodes the date - specifically, the month - in a machine-readable format. We cannot expect all UAs to know every language variant and local abbreviation. If your model /were/ adopted, we would need a value attribute, which - in the case of type=datetime - takes an ISO date-time, like: value=2007-12-11T10:57:14Z Yeah of course this was an example. The datetime format whithin the tag would be to define. I just took the representation of GMT date in javascript but of course the goal would be to use a format that would be readable for everyone in any language because it would be displayed as is in browsers not supporting the tag. And of course the best format would be the international format as you mentioned. Anyway, for backward compatibility sake, I would say that we need a format human readable, and the T Z letters make it hard to read, so I think it would be better to get rid of them like this : tag type=date2007-12-11 10:57:14/tag Would render 2007-12-11 10:57:14 if tag is not supported If tag is supported, the formating will occur according to the system localization. -- Fabien Meghazi Website: http://www.amigrave.com Email: [EMAIL PROTECTED] IM: [EMAIL PROTECTED]
Re: [whatwg] Removal of Ogg is *preposterous*
On Tue, 11 Dec 2007, Maik Merten wrote: Ian Hickson schrieb: The difference is that while Apple (for example) have already assumed the risk of submarine patents with H.264, they currently have taken no risks with respect to the aforementioned codecs, and they do not wish to take on that risk. Which surely means that they won't ever support any new codecs or new features at any point in the future. This would be the only way to stop adding new risks. One would imagine that they would happily take new risks if the rewards were great (e.g. a better codec). Sadly the rewards in the case of Ogg Theora are low -- there isn't much content using Theora, and Theora isn't technically an especially compelling codec compared to other contemporary codecs like, say, H.264. One way to get a company like Apple to want to take the risk of implementing Theora would be to cause there to be a large pool of existing Theora content out there. Obviously, this presents a bootstrapping problem (aka a chicken and egg problem). If patents are such a threat to big companies they better should drive serious efforts to get the patent lottery into a more sane state or they innovation potential is endangered. I assure you that this is happening, but it's somewhat out of the scope of the work on HTML5. :-) The problem is that the requirements describe the emtpy set, as is correctly described with However, there are no known codecs that satisfy all the current players. Indeed. Work is ongoing to address this. If we had a solution today, we wouldn't be having this discussion, the spec would just be updated to require that. Sadly, work to get a solution here is likely to occur mostly behind closed doors, since it's principally a political problem and not a technical one. I am not actively involved in the work to find a solution here. To put it into a nutshell: To respect the needs of the big players for sure is important - but same shall apply to the needs of the not-so-big ones. I know you don't intend anything else, but the current wording may be a bit unfortunate. I think the current wording in the spec is actually biased towards the small players more than the big ones, but if you think it's the other way around then I probably have struck the right balance. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Removal of Ogg is *preposterous*
Ian Hickson schrieb: One would imagine that they would happily take new risks if the rewards were great (e.g. a better codec). Sadly the rewards in the case of Ogg Theora are low -- there isn't much content using Theora, and Theora isn't technically an especially compelling codec compared to other contemporary codecs like, say, H.264. If keeping the web free of IP licensing horrors and being interoperable with as many players as possible (commercial and non-commercial entities, open source or not, free software or not) isn't much of a reason things are looking cheerless for the web indeed. I don't exactly see why the web should embrace non-free standards just because the big players made the mistake of licensing definitely-encumbered formats and are unwilling to take further risks. (I am aware this is a pretty hard wording and that things aren't quite that easy.) The old wording was a SHOULD requirement. No MUST. If the big players don't want to take the perceived risk (their decision) they'd still be 100% within the spec. Thus I fail to see why there was need for action. One way to get a company like Apple to want to take the risk of implementing Theora would be to cause there to be a large pool of existing Theora content out there. Obviously, this presents a bootstrapping problem (aka a chicken and egg problem). In a world where content is served on a per-user basis (streaming, DRM encrypted media files) I don't think this is much of an argument. HTML5 is a future standard which will serve future content. I think the current wording in the spec is actually biased towards the small players more than the big ones, but if you think it's the other way around then I probably have struck the right balance. I was specifically thinking of the additional submarine patent risk for large companies part. Nobody wants to get struck by a submarine, so either this requirement should be extended to all sort of entities or dropped completely (as its hard by definition to make an informed statement about submarine patents). Maik
Re: [whatwg] [HTML5] 2.9.16. The samp element
2007-12-11 05:56 Ian Hickson: On Tue, 21 Mar 2006, Christoph Paeper wrote: Would the following be inadequate usage according to this specification? a href=foo.imgsampimg src=foo.t.img alt=...//samp/a Yes. The former would be appropriate if a computer output the given image and that was the subject under discussion; That means screenshots, doesn't it? But computers output many more kinds of images, e.g. when they render, scan, read out cameras or other media, reel through films ... I think it's hard to tell the essential difference. Of course almost nobody actually uses |samp| in galleries and the like at the moment, so it's not a big deal. I'm not convinced that there's really a need to unambiguously mark up thumbnails as distinct from anything else, though. Neither am I, but there are programs or browser plugins that could make good use out of this information. OTOH it might fit better into the |rel| (or |rev|) attribute of the surrounding |a| (or it's done by a predefined class for |img|). Another question would be whether the linked image had to be the original (e.g. the full-size screenshot) or just a better representation of it (e.g. the larger scan of a book cover). PS: Thanks for the personal CC, I've not been watching the list for a while.
Re: [whatwg] simple numbers
2007-12-11 06:20 Ian Hickson: I considered all the feedback on having a number element (or similar), quoted below. While I think there is certainly something to be said for the proposal, I don't think there is enough evidence that authors really want or need this. JFTR: http://www.mediawiki.org/wiki/Extension:UnitsFormatter Its scope is a little different (and it should probably comply to the Unified Code for Units of Measure http://aurora.regenstrief.org/UCUM/ ucum.html), but it's one little proof at least that the idea itself is not just esoteric or academic. I think we should focus on having CSS support this first. I consider localised numbers (and dates) inside non-localised text harmful, but this markup / metadata is useful for extraction (of several kinds).
Re: [whatwg] Removal of Ogg is *preposterous*
Am Dienstag, 11. Dezember 2007 09:27 schrieb Manuel Amador (Rudd-O): Hello, Ian, revert. This compromise on basic values is unacceptable, *whatever* the practical reasons you have deemed to compromise for. If you don't revert, you will be giving us independent authors the shaft. And we will remember it forever. This is a part of a bigger problem. Today an important part of our culture is stored digitally. To not lose this culture for coming generations it's necessary to have fileformats and codecs for text, images, audio, video, ... that could be used free independent of specific computersystems and companies. For example an UNESCO World Heritage Committee for fileformats and codecs: - Choose usable fileformats and codecs - Set a deadline - After this deadline it's not allowed to claim any kind of rights to this fileformats and codecs to avoid problems like with JPEG in the past. tschuess [|8:)
[whatwg] Removal of Ogg Vorbis and Theora
Please, anybody, tell me it's not true.Ogg Vorbis/Theora is perfect for web applications. We need to suport those. Is there anybody else than me that realise it cost 0.75$ US to of patents licensing LEGALLY have an MP3 decoder? I devellop for embedded applications, and it cost 15000$ Just to ship around 100 Units with a MP3 software Encoder. Ogg and Theora does a comparable cost but are free. I still can't imagine why anybody would retract those two great standarts from HTML5, unless they have codecs they what royalties from!)-Jerome MarchandFrom: Manuel Amador To: [EMAIL PROTECTED] Subject: Removal off Ogg technology: *preposterous* Allow me to be the voice of the small Web developer -- which I consider to be the foundation of the World Wide Web. In reference to: http://html5.org/tools/web-apps-tracker?from=1142to=1143 The recent removal of the mention of Ogg in HTML5 and the subsequent replacement of its paragraph with the weasel-worded paragraph that would make Minitrue bust their collective shirt buttons in pride: p class=”big-issue”It would be helpful for interoperability if all+ browsers could support the same codecs. However, there are no known+ codecs that satisfy all the current players: we need a codec that is+ known to not require per-unit or per-distributor licensing, that is+ compatible with the open source development model, that is of+ sufficient quality as to be usable, and that is not an additional+ submarine patent risk for large companies. This is an ongoing issue+ and this section will be updated once more information is+ available./p is a preposterous and gross mischaracterization of fact (dare I say lie). At the very least, it’s FUD. It pains me to state what is and has always been public knowledge, and is being intentionally ignored just to “get the spec published”: - The Xiph developers were extremely zealous and almost fiduciarily diligent in researching all possible patent threats to Vorbis technology, and for more than a year they found none — they even did the research *before* beginning to code, explicitly to avoid submarine patents. I know, because I was subscribed to their mailing list and read status updates of this research, practically at the start of the project. I also know that big-name software houses and media players manufacture products with Vorbis technology, and none of them have been sued. It’s been what, seven years now? - The Theora codec has had its patents practically relinquished by On3 with a perpetual royalty-free license. - Ogg and its audio/video codec technologies are the ONLY free software media technologies with implementations widely available on all consumer computing platforms — from WM codecs to Linux DLLs, passing through the entire range of hardware (floating-point and fixed-point) and OSes. - Without guaranteed Ogg support (whose integration in user agents I think I already established to be sort of a weekend-level junior programmer project at NO COST, due to the ready availability of the technology in all platforms), authors *will be* forced to use patent-encumbered technology. Remember MP3? Well, with HTML5 it’s 1997 all over again. Ian, revert. This compromise on basic values is unacceptable, *whatever* the practical reasons you have deemed to compromise for. If you don’t revert, you will be giving us independent authors the shaft. And we will remember it forever. _ Découvrez de nouvelles façons de rester en contact grâce à Windows Live! Visitez la Cité @ Live dès aujourd’hui! http://www.tonadresselive.ca/?icid=LIVEIDFRCA006
Re: [whatwg] Removal of Ogg Vorbis and Theora
hey let me add my voice to this. having the mention of ogg in the spec is *beneficial* to [wired] humanity. look what open standards have gotten us [the flowering of culture and intelligence on the web]. is this just another manifestation of our ooxml future ... ? i hope not. -- \js
Re: [whatwg] Video codec requirements changed
Ian Hickson wrote: I've temporarily removed the requirements on video codecs from the HTML5 spec, since the current text isn't helping us come to a useful interoperable conclusion. I don't think this solves any problem, neither in the short term or the long term. I suggest that the should text is put back in. When a codec is found that is mutually acceptable to all major parties I will update the spec to require that instead and then reply to all the pending feedback on video codecs. Sure, when that happens the text can be revised. But not before. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
[whatwg] *AGAINST* Removal of ogg from spec
After wasting what seemed like an eternity reading what can only be described as pure and unabridged dribble from Nokia. Before I continue to write this responce I would just like to thank Nokia for wasting 20mins of my life. I must express my disappointment that w3c is caving to pressure to remove an essentially free codec from the specification that was at best a recommendation, after all it said *should* not *must*, as to the preferred codec. In fact while we are here, supporting the removal of things beneficial to the end user, perhaps with HTML5 we should recommend that the html code be compiled so that users cannot read it as that would benefit a few minority companies that have done clever things with js/html/css and want to hide those things as trade secrets/IP. Maybe Nokia would be as good as to point out which codec is better? wmv? divx? mov? My argument in favour of a free codec is that all browsers could ship with it, without fear of being sued, this would allow users to watch/listen to clips/movies/music out of the box without scouring the Internet for codec XYZ for a once off use. That is not to say that the use of OGG should be explicit, of course anyone should be able to choose which codec they use to display their clips but for people just beginning (and even experts) it would be nice to have a single codec that is an implied standard. This way they don't have to worry will xyz be able to watch my funny 5min clip as they know that IE, FF, (er.. whats that mac browser called again?), etc will play ogg out of the box (so to speak). A good question that jumps to mind though is who are Apple / Nokia to tell anyone what should be a web standard, surely 2 companies that (in the scheme of things) aren't even that big (I will concede that Nokia are the market leaders in phones, but Apple are 2nd to who?? oh yes MS??), I would also point of that of the two companies opposing this one (apple) isn't known for its interoperability (propriety hardware/software, DRM locked music downloads that only play on apple products). Really if *anyone* should have any sway here (and I personally think that no 1 or 2 companies should) it should be Google lets face it they are the largest power on the Internet whether you love em/hate em/dont know who they are.. Another is what is Nokia thinking? (what am I on about you ask.. read on my children) Nokia build phones (yea I am dead smart), phones are only just getting to the point that they are decent enough to browse the web on but (yes i said but) there is no standard in place for them and lets be honest here, if a phone user comes across a divx clip its safe to say they won't be able to watch it.. Why? well phones generally aren't know for their ability to download new plug-ins (eg codecs). Now say we imply that ogg should be the default/standard for web AV (audio/visual) then all phones come with it built in and Nokia don't have to pay anyone royalties to use it, and mister end user (the guy that usually gets shafted by DRM and other incompatibilities) can browse and watch ogg clips on all the HTML5 compliant pages till his little heart is content. So we must ask ourselves why would Nokia want to get rid of a standard (that's not even set in stone) that is likely to mean they have to pay out more money per unit (thereby pushing prices of end user appliances up)? Sounds like they know something we don't (no I am not a conspiracy theorist/paranoid nutter), I just find it strange that a company that stands to lose profit margin would take such a stance.. Well thats my word count for the next month or so.. and a case of RSI to go with it.. I just hope that others here believe that these are vaild points and wont stand for companies forcing bad decisions upon the rest of us. -- Regards, Ryan McLean
Re: [whatwg] Removal off Ogg technology
On 11 Dec 2007, at 15:33, Wilson Michaels wrote: In reference to: http://html5.org/tools/web-apps-tracker?from=1142to=1143 I am a retired software developer who is outraged that Ogg technology has been removed from HTML5. It must be reinstated as a should option so that the world is not held hostage to proprietary implementations of media technologies. Proprietary technologies eventually are used to limit inovation and prevent entry of other thechnologies that threaten the proprietary company in some way. We don't need another MP3 fiasco. What difference is there between a SHOULD that few, if any, major companies implement, and one that doesn't exist? The spec will never recommend any format that cannot be freely (as in beer) be implemented safely by developers (i.e., without risking being sued). Also, MP3 is not a proprietary standard: you can go out and buy a copy of the spec if you wish, and pay any patent charges due. You still, as with anything invented within the last 20 years (including Ogg/Vorbis/ Theora), run the risk of a submarine patents. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Removal off Ogg technology
The difference with the should is that the browsers who support standards will support ogg natively. The fact that big companies like nokia etc don't actually use OGG is less my concern, it's more about the free developers knowing that ogg will be supported at the users' end. Patents is less my area of expertise as I am (luckily) a resident of the EU, but this whole submarine patent bussiness has got me thinking that America better clean up ship quickly. Geoffrey Sneddon wrote: On 11 Dec 2007, at 15:33, Wilson Michaels wrote: In reference to: http://html5.org/tools/web-apps-tracker?from=1142to=1143 I am a retired software developer who is outraged that Ogg technology has been removed from HTML5. It must be reinstated as a should option so that the world is not held hostage to proprietary implementations of media technologies. Proprietary technologies eventually are used to limit inovation and prevent entry of other thechnologies that threaten the proprietary company in some way. We don't need another MP3 fiasco. What difference is there between a SHOULD that few, if any, major companies implement, and one that doesn't exist? The spec will never recommend any format that cannot be freely (as in beer) be implemented safely by developers (i.e., without risking being sued). Also, MP3 is not a proprietary standard: you can go out and buy a copy of the spec if you wish, and pay any patent charges due. You still, as with anything invented within the last 20 years (including Ogg/Vorbis/Theora), run the risk of a submarine patents. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Removal of Ogg is *preposterous*
On Tue, 11 Dec 2007 17:11:57 +0100, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 11 Dec 2007, at 13:36, Maik Merten wrote: The old wording was a SHOULD requirement. No MUST. If the big players don't want to take the perceived risk (their decision) they'd still be 100% within the spec. Thus I fail to see why there was need for action. There's a question within the W3C Process whether patents that are covered by a SHOULD via a reference are granted a RF license similarly to anything that MUST be implemented. Both Nokia and MS raised concerns about this relating to publishing the spec as a FPWD. And these concerns are total rubbish (as pointed out by Apple and others): [[[ 8.1. Essential Claims Essential Claims shall mean all claims in any patent or patent application in any jurisdiction in the world that would necessarily be infringed by implementation of the Recommendation. A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no non-infringing alternative for implementing the normative portions of the Recommendation. Existence of a non-infringing alternative shall be judged based on the state of the art at the time the specification becomes a Recommendation. ]]] - http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential In other words, the patent policy makes it clear that to be covered, something must be required in order to implement. A SHOULD-level requirement is clearly not required. So any such concern about the wording that was in the spec is more FUD than fact. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Asynchronous database API feedback
Dnia 10-12-2007, Pn o godzinie 21:22 -0600, Dimitri Glazkov pisze: Guys, I think the point was that it's not unreasonable to have synchronous API. The argument about slow/busy devices is valid, but I still think the developer should have the choice of either going with a simple query/receive calls in their code as opposed to braving complexity of asynchronous API. I fully agree with this point and do believe that if it's a low-hanging fruit, it should be included into the implementation. Allowing the script to wait until the transaction completes would be enough to provide synchronization, wouldn't it? A stubborn programmer can still do it: make a transaction set an event upon completion and make the script loop until that event is set. Upon the theory that the transaction in question is a quickie, it would be quite acceptable, especially if the script engine fiddled with thread priorities a bit. If I am right, it is not such a big issue after all. Chris
Re: [whatwg] Asynchronous database API feedback
Dnia 10-12-2007, Pn o godzinie 16:04 -0800, Dan Mosedale pisze: On Dec 10, 2007, at 12:21 PM, Geoffrey Garen wrote: I'd hate for GMail to mysteriously stop working every couple of days just because of some background process that I had no knowledge of. As a developer, how would you debug such a problem? As a tech support worker, how would you explain it to an end user? +1. Having a bug in a single web-app be able to completely freeze the entire UI of the entire browser (not just that window/tab) seems like a pretty painful user experience, almost to the point of being unacceptable. If an end user ran into this problem very often, I would expect them to blame the browser, and perhaps even switch to a browser which didn't have this problem (i.e. didn't support localStorage). As a user, assuming a synchronous interface with timeouts, I would almost certainly want my browser to enforce a _much_ shorter timeout than 5 seconds... something on the order of 200ms, maybe. Anything that makes repainting stop just feels really bad. Does that mean asynchronous script execution as well? Because if not, it cannot be done, except that the browser implements a script kill timeout, which applies to all scripts, including local database access when it is supported. Best regards, Chris
[whatwg] Removal of Ogg - eyes on you
You all have garnered quite the attention over removing Ogg Vorbis/Theora as a recommended audio/video codec in HTML5. Just a reminder: the rest of the Internet is watching, and is hoping with all its heart that you do the Right Thing here. http://yro.slashdot.org/article.pl?sid=07/12/11/1339251 http://yro.slashdot.org/article.pl?sid=07/12/09/2045200 They (we?) also seem to think you have done the world quite the injustice in bending to corporate fears over submarines. It's the fault of the vendors for not fully researching their own codecs, before putting millions of dollars and man-hours behind implementing such. Vorbis and Theora seem to be the safest options in avoiding such things. And they're still technologically competitive! Specify an open format as your recommendation (or specify simply that the format simply MUST BE an open format!), and let the vendors implement it thusly. Don't buy into the FUD - it's a sign of malicious laziness and/or outright subversion, on the part of your corporate interests. -Andrew Harris http://andrewharris.org/
Re: [whatwg] Removal of Ogg is *preposterous*
On 11 Dec 2007, at 18:09, Manuel Amador (Rudd-O) wrote: Fact: Vorbis is the *only* codec whose patent status has been widely researched, nearly to exhaustion. Repeating the same FUD over and over again (which you just did) may lead the world to believe this to be false, but it's TRUE. You should at least have talked to Monty @ Xiph before jumping to rash conclusions. So undisclosed patents have been looked at? How? -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Removal of Ogg is *preposterous*
El Mar 11 Dic 2007, Dave Singer escribió: I'm sure that many people would be happy to see a mandate if someone were willing to offer an indemnity against risk here. You seem quite convinced there is no risk; are you willing to offer the indemnity? No. Unlike Apple, I don't have a huge patent portfolio. My patent count reaches the awesome number of *zero*. Would you be willing to offer patent indemnity to unlicensed users of your Apple AAC audio format? Because I fail to see why leaving users without a free choice for audio *helps* things. I dunno, maybe I'm just dumb as a rock. Large companies (Nokia, Microsoft, and Apple) have expressed anxiety, and are asking (among other things) that an independent analysis be done. The W3C staff are, I believe, actively working on the issue. I'm sure that they would be pleased to consider whatever background material you can offer them. I fail to see how asking for an analysis of the problem is giving anyone the shaft, since no decision has yet been even offered let alone reached. The fact that no decision has been finalized is somewhat relieving, because it means we can still revert to the pro-free stance. Did you read the piece that I edited from the discussions at the HTML meeting? No. I just recently enlisted here. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ signature.asc Description: This is a digitally signed message part.
Re: [whatwg] OGG in HTML5
On 11 Dec 2007, at 16:20, alex wrote: I am a webdeveloper and a fierce supporter of opensource. I was under the impression the standards were being designed in the same opensource spirit, but I may have been wrong. Standards are developed inline with the policies of the organisations they are developed by. http://www.w3.org/Consortium/Process/ describes the W3C process document. The issue here is that the chairs think the reasons given for not publishing a working draft are strong enough (i.e., it is the strength of the arguments, not the number in favour of the arguments that is important). Setting OGG as the de facto standard is the best idea i've heard in a long time, How can you set a de-facto standard? By the very meaning of de-facto, you cannot. We can set a de-jure standard, but not a de-facto one. and now it's all coming down because a few companies (some of which are known for their vendor lock-in tactics) want to keep their empire. No, it is coming down because a few companies don't want to take the risk of being sued for submarine patents which might exist for Ogg/ Vorbis/Theora. Do you want to pick up the bill for patent infringement? MS has to pay 1.52 billion USD for (submarine) patent infringement covering MP3. Unsurprisingly, major companies don't want to take such a risk on a codec that has few advantages over current standards such as MPEG-4. But why, then, are they happy to support MPEG standards? They already do: it had/has clear technical advantages to prior de-facto formats (the same cannot be said for Theora, which is less efficient than MPEG-4). They have already taken the risk to support it, and people have already had the chance to sue them, and that has not yet happened. In the case of MS and Apple, they already support video formats at the OS level, and don't re-implement them within the browser (and have already therefore paid patent charges). Finally, the risk of supporting both is greater than supporting just one. There are already widespread de-facto standards, so that is what they will choose to support, not a container/codec combination that has (comparatively) very little content. I am not saying that ogg should be enforced onto anyone, if nokia wishes to keep using a different format, no problem, but by making it a standard, we at least know that ogg will be supported by all (standards-compatible) browsers, and as such it can be deployed by those who are opposed to vendor lock-in or monopoly positions. It won't be supported by all (currently) standards-compatible browsers. Apple, a major browser vendor, has said they don't intend to implement Ogg/Vorbis/Theora just because the spec requires it (i.e., if you can get a critical mass of web content using it, you may well be able to get them to support it). OGG is the choice of freedom, enabling that freedom for all webdevelopers is a must in my opinion, although in the same spirit, it can not be enforced upon anyone, therefor the original text stating it should instead of it must is probably the best way to go. If it is a MUST, then the spec is irrelevant: it will be ignored by major companies. We must settle at a compromise between the two POVs to get the spec implemented at all; we otherwise run the risk of major companies not implementing any part of the spec whatsoever, leaving us far worse off that we would be otherwise. Also, if it a MUST everyone in the WG would be issuing a RF license covering any patents they hold covering Ogg/Vorbis/Theora to everyone else in the WG (as per http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential ), which companies such as MS and Nokia have said they are unwilling to do. As far as compromises go, there are several viable solutions, including MJPEG and H.261 (the latter is only slightly worse than Theora, and is so old (as of next year, even the revision to it will be 20 years old) that any and all patents have either expired or are invalid). This still leaves questions open regarding container format and audio (which I know less about, and won't comment so much on). If you truly do want make no compromises yourself, you may be able to get the major browser manufacturers that are currently unwilling to implement Ogg/Vorbis/Theora to implement them by getting a critical mass of content out there. Bear in mind, though, that MS still does not support MPEG-4 out of the box (except for Zune), despite the huge amount of MPEG-4 content already out there. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Removal of Ogg is *preposterous*
On Dec 11, 2007, at 1:21 PM, Manuel Amador (Rudd-O) wrote: I actually think this Slashdot comment summarizes the sentiment perfectly: Methinks you are being a bit myopic here. Where would we be today if the HTML spec didn't specify jpg, gif, and png as baseline standards for the image tag? Can you imagine a huge mishmash of competing proprietary image standards, many of which wouldn't even render in free software browsers like Firefox? That would be a nightmare, but unfortunately, that's what's currently happening with video. Much like the image standard in HTML means that any browser can display anything in an image tag, so too must the video standard in HTML guarantee that any browser can display anything in a video tag. That's what the proposed specification is about. That's interesting, because none of the HTML specifications up until now have actually mandated *ANY* format for baseline standards. Really. Go check out the HTML 4.01 specs: http://www.w3.org/TR/ html401/struct/objects.html All that's said is Examples of widely recognized image formats include GIF, JPEG, and PNG. Now HTML5 may very well change this, but the argument that the HTML specification mandated JPEG/GIF/PNG and this what made image rendering standards work on the web is fundamentally flawed; the specification mandated no such thing. -Henry
Re: [whatwg] Removal of Ogg is *preposterous*
No, I won't pay. It's not my problem, and they can foot the bill. If they were wise, they would fund patent reform efforts as the most enduring way to prevent these disasters from continually arising. But they won't because they also benefit from the patent racket. And even if Apple gets sued for patent infringement, that doesn't mean that the suit has merits -- experts already looked at the evidence surrounding Vorbis and patentability, and unanimously said it's clear. That's not what Dave is meaning: If Apple gets sued for patent infringement, will you pay however many billion USD they have to? If you truly believe there are no patents covering Ogg/etc. then you can safely agree knowing that you'll never have to give away any of your money. -- Geoffrey Sneddon http://gsnedders.com/ -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Q: How was Thomas J. Watson buried? A: 9 edge down. signature.asc Description: This is a digitally signed message part.
Re: [whatwg] Asynchronous database API feedback
On Dec 11, 2007, at 11:22 AM, Aaron Boodman wrote: How does the globalStorage implementation deal with this problem? It has a synchronous storage API. True it is probably designed for smaller amounts of data, but there's nothing preventing an author from using it for large amounts (is there?). Also, some of the concerns raised here have nothing to do with the amount of data stored. Or does globalStorage not guarantee that data is written when the setter returns? I see nothing in the globalStorage spec that suggests that the data must be on the disk by the time setItem() returns, and I think it would be crazy for a user agent to voluntarily store the data out to disk before returning from the method. ~Brady
Re: [whatwg] Asynchronous database API feedback
On Dec 11, 2007 11:22 AM, Aaron Boodman [EMAIL PROTECTED] wrote: Or does globalStorage not guarantee that data is written when the setter returns? A thing I've been thinking about for Gears would be the ability to spin up an in-memory/async session database, with the sense of session being the same as for session cookie. For this database, when control returns from an update statement, the data is _not_ guaranteed to be on disk, and if your browser crashes it is explicitly guaranteed to be gone. So far, so useless, except if you allowed the system to attach that database to a persistent database. In such a system, you could do synchronous operations against the session database, and bulk async operations to propagate the data to the persistent database. -scott
Re: [whatwg] Asynchronous database API feedback
On Dec 11, 2007, at 11:40 AM, Aaron Boodman wrote: I thought it would be useful if the spec had a simple synchronous API for cases where the developer expects operations to happen quickly and/or doesn't care if they timeout ocassionally (because, for example, the application will retry automatically later). I think the assertion of many here is that the web developer *can't* have any knowledge about whether or not the operation will happen quickly... If the application's solution is to handle timeouts and try again later, what if their execution environment doesn't change? Such as the user is playing a system-intensive game, or transferring a large amount of HD video, or any other disk-intensive task that is long running. Or the user is on limited power device that will always be slower, and the query the application is trying to execute is *just* over the timeout threshold, and it will never be fast enough. And I can think of a lot more! This application will never succeed in storing its data, and the developer/user won't have any recourse. In this case we've given the application developer the tool to shoot themselves in the foot and they won't even know it. It's clear that most people here feel passionately that this is the wrong thing to do. Perhaps it's best that we table this until something like workerpools are in the spec. I don't see the advantage of replacing a targeted form of asynchronicity that has some consensus with a general purpose form of asynchronicity that brings a lot of other concerns/debate along with it ~Brady
Re: [whatwg] OGG in HTML5
2007/12/11, alex [EMAIL PROTECTED]: I am a webdeveloper and a fierce supporter of opensource. I was under the impression the standards were being designed in the same opensource spirit, but I may have been wrong. Setting OGG as the de facto standard is the best idea i've heard in a long time, and now it's all coming down because a few companies (some of which are known for their vendor lock-in tactics) want to keep their empire. I am not saying that ogg should be enforced onto anyone, if nokia wishes to keep using a different format, no problem, but by making it a standard, we at least know that ogg will be supported by all (standards-compatible) browsers, and as such it can be deployed by those who are opposed to vendor lock-in or monopoly positions. well, I think that ENFORCING is the way the real life works, is the case of windows, it is used because the hardware vendors enforce us to use it installing it by default, is the case of the mp3, is the case of any file format, is the case of swf, and is the case of wma, people use all that crap because they are enforced, I think is very positive that when we create something, if it is pretty useful we have the power to enforce is use, for the good, and is ok, HTML5 should enforce OGG as a supported format, IT IS GOOD FOR EVERYONE, only look at what happened with the PNG, is now wide accepted over GIF. OGG is the choice of freedom, enabling that freedom for all webdevelopers is a must in my opinion, although in the same spirit, it can not be enforced upon anyone, therefor the original text stating it should instead of it must is probably the best way to go. Freedom for those who choose, the alternative for the rest. --
[whatwg] User-Agent: Please !
Accept: application/ogg,audio/ogg,video/ogg,audio/vorbis,video/theora,audio/speex -- Fabien Meghazi Website: http://www.amigrave.com Email: [EMAIL PROTECTED] IM: [EMAIL PROTECTED]
Re: [whatwg] Removal of Ogg is *preposterous*
On 11 Dec 2007, at 20:12, Manuel Amador (Rudd-O) wrote: It was intended as meaning recognized in the sense of browsers recognising them. No currently shipping browser recognises either Ogg Vorbis or FLAC. If I use EMBED on Konqueror pointing to an Ogg Vorbis file, I get a nice player with streaming and everything. Konqueror's shipping, isn't it? There is at least *one* browser that already supports, through GStreamer, Ogg in video tags. I'd give you the link but it apparently fell off the end of Planet GNOME so I can't find it... Now hold on, it's not shipping, but that doesn't mean it won't be shipping tomorrow. What you actually wanted to say (but couldn't/didn't/were unwilling to) is: No currently shipping browser by any of the major proprietary software vendors support Ogg Vorbis or FLAC. Nor any of the minor ones, nor most open source ones. Also, I assume through Konqueror relying on GStreamer that Konqueror doesn't support it itself (or through a required dependancy, which is needed to actually conform to such a clause that existed). WebKit trunk also supports Ogg in video if you have the needed QT component (which is supporting it as much as Konqueror supports it). Opera 9.5 beta has built in support for Ogg/etc. and supports nothing else. There are still large questions about when Fx will support (which I assume from your later post is what you were referring to) video natively, though it may well be in Fx 3.0 in early '08. It's just dollars. Apple does not license Apple Lossless to anyone else AFAIK, OK. So they sell fewer iPods because iPods don't play Ogg Vorbis without Rockbox. Same outcome. Oh, look, they are already losing custom through not supporting WMA. It doesn't look like they particularly care about that, does it? and the only standards that MPEG-LA collects money for that Apple receives any share of whatsoever is MPEG-4 Systems and IEEE 1394 (Firewire). Neither of these have anything to do with audio/video codecs. Saying that Apple has a financial interest in wanting MPEG codecs mandated in HTML 5 is totally untrue. I didn't say Apple wanted MPEG codecs mandated in HTML 5, so don't put words in my mouth or attempt to smoke-and-mirrors us with straw men. This is either a fumble on your part or an attempt to derail the discussion into wreckland. No, it is me trying to understand what you're meaning. I said Apple doesn't want Ogg Vorbis because they don't control the tech, and because they would very much rather have consumers prefer (in the sense of being screwed with no choice) DRM-encumbered AAC (note it's not the codec, but the controlling of the consumer that matters here). AAC doesn't support DRM natively. It's a proprietary extension. iTunes has always ripped CDs by default into non-DRM-encumbered AAC (i.e., an open standard, and compatible with numerous players). Apple has never, anywhere where it has a choice, favoured DRM-encumbered standards. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Removal of Ogg is *preposterous*
Charles, I find Opera's efforts commendable. More organizations should follow Opera's lead in this direction, just as they've followed Opera's lead in several other innovative efforts. I trust your comment in favor of Ogg is not just because Opera already has it (which, by the way, proves technical feasibility beyond a shadow of doubt) but because Ogg in HTML5 is the right thing to do. We're disappointed to see the spec go in this direction. I think it is a backward step. Me too. There is no voting in WHAT-WG, and there is not much in W3C, but there is a reasonable process there that hopefully allows for this stuff to go back into the specification, unless we find a better alternative (i.e. still free). Let's keep hoping. Well, instead of hoping, maybe we can draw more attention to this issue so public pressure helps us do the job. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Don't you wish you had more energy... or less ambition? signature.asc Description: This is a digitally signed message part.
Re: [whatwg] Asynchronous database API feedback
It's clear that most people here feel passionately that this is the wrong thing to do. Perhaps it's best that we table this until something like workerpools are in the spec. Worker pools do not resolve the problem, even if you were to force any synchronous IO to be performed on a worker thread (where by force i mean attempting synchronous io on the main/ui thread would throw an exception or similar). The problem is that once you have multiple threads, and those threads are unable to modify the DOM (allowing the DOM to be modified from a worker thread would cause too much havoc -- there is much to much JS out there to allow JS to become multithreaded), so either you defer the synchronous IO into a async callback model to tell you when the io has completed -- you are now using the synchronous api to implement your own async api -- or you have thread constructs such as a rendezvous, which will eventually end up in the UI thread, thereby reducing any thread synchronous IO back into a blocking operation. --Oliver - a
Re: [whatwg] Removal of Ogg is *preposterous*
On Dec 11, 2007, at 3:46 PM, Manuel Amador (Rudd-O) wrote: Apple and Nokia seem to think that there *are* hamburgers in the moon, and that those hamburgers will cost them billions of dollars in submarine sandwich lawsuits. Of course, that's what they are *saying*. It doesn't take a Feynman or a Chomsky to understand the real reason why they want the Ogg hamburger off HTML5. Maybe you should take some time to read the previous discussions of this issue before making such inflammatory accusations. Fear of submarine patents is only one reason Apple is not interested in Theora. There are several other reasons. H.264 is a technically superior solution to Theora. Ignoring IP issues, there would be no reason to pick Theora over H.264. Everyone wants an open freely implementable codec, but it doesn't follow that Theora should automatically be that codec. About the only argument I've heard in favor of Theora is that it's open, but that is an argument based purely on IP and not on technical merits. If you consider mobile devices that want to browse the Web, then depending on the constraints of the device, a hardware solution may be required to view video with any kind of reasonable performance. A mandate of Theora is effectively dictating to those mobile vendors that they have to create custom hardware that can play back Theora video. Given that such devices may already need a hardware solution for existing video like H.264, it seems unreasonable for HTML5 to mandate what hardware a vendor has to develop just to browse Web video on a mobile device. Or put another way, imagine that GIF was an open format but PNG was IP- encumbered. Would you really want to limit the Web to displaying only GIFs just because it was the only open image format available? Technical arguments are relevant here, so take some time to consider them before accusing people of having shady ulterior motives. dave ([EMAIL PROTECTED])
Re: [whatwg] Video codec requirements changed
On Tuesday 2007-12-11 02:39 +, Ian Hickson wrote: I've temporarily removed the requirements on video codecs from the HTML5 spec, since the current text isn't helping us come to a useful interoperable conclusion. When a codec is found that is mutually acceptable to all major parties I will update the spec to require that instead and then reply to all the pending feedback on video codecs. http://www.whatwg.org/issues/#graphics-video-codec The text you replaced the requirements with [1] includes the requirement that the codec: # is not an additional submarine patent risk for large companies Is this something that can be measured objectively, or is it a loophole that allows any sufficiently large company to veto the choice of codec for any reason it chooses, potentially including not wanting the video element to succeed in creating an open standard for video on the Web? -David [1] In full, the text is: # It would be helpful for interoperability if all browsers could # support the same codecs. However, there are no known codecs that # satisfy all the current players: we need a codec that is known to # not require per-unit or per-distributor licensing, that is # compatible with the open source development model, that is of # sufficient quality as to be usable, and that is not an additional # submarine patent risk for large companies. This is an ongoing # issue and this section will be updated once more information is # available. from http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#video -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] several messages regarding Ogg in HTML5
I think you meant Vorbis, but other than a quick sed s/Theora/Vorbis/g, I see myself agreeing with you. El Mar 11 Dic 2007, Jeff McAdams escribió: Ian Hickson wrote: On Tue, 11 Dec 2007, Maik Merten wrote: If keeping the web free of IP licensing horrors and being interoperable with as many players as possible (commercial and non-commercial entities, open source or not, free software or not) isn't much of a reason things are looking cheerless for the web indeed. Actually those are pretty much the only reasons being taken into account here. Sadly, Ogg doesn't keep the Web free of IP licensing horrors, due to the submarine patent issue -- as Microsoft experienced with MP3 and with the Eolas patent over the past few years, for instance, even things that seem to have well-understood patent landscapes can be unexpectedly attacked by patent trolls. Then you need to stop work on a HTML5 spec right now because *EVERYTHING* has a submarine patent risk to it. Theora was developed, by all accounts, after as exhaustive of a patent search as is possible, and designed to not infringe on any patents. That's as close to being sure that you're patent free as you can get. This is the least risk option going forward. Its also the only option that I see that can hold true to the w3c's ideals of freedom (which I strongly support). Apple and Nokia's stated reasons for objecting to Theora are crap...they don't pass the smell test. Ian, you're being taken for a ride, here. Just revert the text and go back to Theora as the codec of choice and end this charade of trying to look like you're taking everyone's concerns into account because its clear that you aren't. Apple and Nokia are, so far, getting their way, despite the huge public outcry that you're seeing, and that should tell you something, and tell you something loud and clear. Apple and Nokia's reasons for objecting to Theora don't pass the smell test. Nokia even called Ogg proprietary in their white paper I've sure you've read as well. This is so badly wrong as to have become the butt of jokes. What are the real reasons that Nokia and Apple object to Theora? Clearly the reasons that they have stated are a smoke-screen because they don't even withstand the most basic of scrutiny. If you want a baseline codec that everyone supports, revert the text and then s/SHOULD/MUST/ . Apple and Nokia may not like it, but that's the only real option if you want a codec that everyone can support. And, yes, Apple and Nokia *can* support it, the risk is negligible, and technically is not hard to do. I don't exactly see why the web should embrace non-free standards just because the big players made the mistake of licensing definitely-encumbered formats and are unwilling to take further risks. (I am aware this is a pretty hard wording and that things aren't quite that easy.) In the absence of IP constraints, there are strong technical reasons to prefer H.264 over Ogg. For a company like Apple, where the MPEG-LA licensing fee cap for H.264 is easily reached, the technical reasons are very compelling. Except that there are *KNOWN* IP (god how I hate that term) constraints with H.264. At least with Theora we can avoid any known ones. All codecs have a risk of submarine patents (though with extensive having been done for Theora, at least that risk is lowered, if not eliminated completely), so that argument is a wash, its on both sides of the equation, so it cancels out. Is H.264 a better codec technically, yeah, ok, and Nokia and Apple are free to support it if they wish in addition to Theora, or even to implement all of the HTML5 spec except for Theora support and risk being called out as non-conformant. The old wording was a SHOULD requirement. No MUST. If the big players don't want to take the perceived risk (their decision) they'd still be 100% within the spec. Thus I fail to see why there was need for action. The problem is that if the big players don't follow the spec, even the SHOULD requirements, then the spec is basically pointless. What we want isn't that some people support Ogg, what we fundamentally want is that _everyone_ support the same codec, whatever that may be. Then revert the text and make it a MUST. As far as I know, there are no other codecs out there that are not encumbered. This is the whole reason for existence of Theora, at least at the time, and I don't know that this has changed in the few years since it was designed. If you want a baseline that everyone can implement without being encumbered, then the answer is Theora. Small companies aren't targetted by patent trolls. Only big (really big) companies are. It's a big-company concern, just like no per-user licensing is a small-company concern. That's just the reality of the situation, it's not intended to be a bias. Except that it very clearly is biasing the decision making process
Re: [whatwg] HTML 5, OGG, competition, civil rights, and persons with disabilities
At 13:45 -0500 11/12/07, Fernando wrote: Please reconsider the decision to exclude the recommendation of the Theora/OGG Vorbis codec in HTML 5 guidelines. This entire discussion is founded on a major misapprehension: that there has been a decision, and that decision was to exclude. This is simply not true; there is no decision either to include or exclude. There is a recognition that work is needed. I and others have spent a great deal of time on this problem already, working with a number of people, including the W3C staff. Many of us -- maybe all of us -- agree we need to find a solution that enables broad interoperability and is in accord with w3c and web practices. We have not yet reached consensus on having found it. That's all. -- David Singer Apple/QuickTime
Re: [whatwg] Video codec requirements changed
The text you replaced the requirements with [1] includes the requirement that the codec: # is not an additional submarine patent risk for large companies Is this something that can be measured objectively, or is it a loophole that allows any sufficiently large company to veto the choice of codec for any reason it chooses, potentially including not wanting the video element to succeed in creating an open standard for video on the Web? There is no objective measurement possible for that requirement, except the lone yes/no of something being unpatented and really old. We can't make videos play on Web pages using forks, hammers and chairs. And even under those circumstances, patent trolls do get stuff that shouldn't be patentable patented, so living in fear of patent trolls is absurd. Wanna know what happened to the last troll that attacked free software? Ask Darl McBride. Everyone is under the possibility of constant attack from trolls. But, anyway, we've already established that the fear of patents is just an excuse to take Ogg out. Other sensible reasons remain to prefer other technologies, and the standard as it was written before did cater to those technologies as well. -David [1] In full, the text is: # It would be helpful for interoperability if all browsers could # support the same codecs. However, there are no known codecs that # satisfy all the current players: we need a codec that is known to # not require per-unit or per-distributor licensing, that is # compatible with the open source development model, that is of # sufficient quality as to be usable, and that is not an additional # submarine patent risk for large companies. This is an ongoing # issue and this section will be updated once more information is # available. from http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.h tml#video -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Hope that the day after you die is a nice day. signature.asc Description: This is a digitally signed message part.
Re: [whatwg] HTML 5, OGG, competition, civil rights, and persons with disabilities
At 19:04 -0500 11/12/07, Jeff McAdams wrote: Dave Singer wrote: At 13:45 -0500 11/12/07, Fernando wrote: Please reconsider the decision to exclude the recommendation of the Theora/OGG Vorbis codec in HTML 5 guidelines. This entire discussion is founded on a major misapprehension: that there has been a decision, and that decision was to exclude. This is simply not true; there is no decision either to include or exclude. There is a recognition that work is needed. I and others have spent a great deal of time on this problem already, working with a number of people, including the W3C staff. Many of us -- maybe all of us -- agree we need to find a solution that enables broad interoperability and is in accord with w3c and web practices. We have not yet reached consensus on having found it. That's all. A decision was made to move away from using the ogg family of technologies. No. A decision was made to have the text reflect the facts that (a) no-one is happy with a 'should' and (b) that work is ongoing to find a solution (which might be Ogg, or something else). That's all. While not a final decision, it is a threatening decision to those of us that value freedom and openness and don't appreciate being screwed by big companies. Listen to what the people are saying. Oh, I am listening. It's by no means clear that the Ogg crowd is at all. I'm also spending efforts working on finding a solution. I don't count lamenting I want my ogg on this list as spending efforts at all. -- David Singer Apple/QuickTime
Re: [whatwg] Removal of Ogg is *preposterous*
David Hyatt wrote: Fear of submarine patents is only one reason Apple is not interested in Theora. There are several other reasons. H.264 is a technically superior solution to Theora. And absolutely noone has said that you can't use H.264. You are perfectly free to do so. What is offensive to the people is using encumbered technologies as a baseline as you are basically suggesting. This is untenable. Theora is the least unencumbered option, and likely is totally unencumbered. Ignoring IP issues, there would be no reason to pick Theora over H.264. Everyone wants an open freely implementable codec, but it doesn't follow that Theora should automatically be that codec. About the only argument I've heard in favor of Theora is that it's open, but that is an argument based purely on IP and not on technical merits. Perhaps the only argument is IP (again, what a crappy, loaded term that is), but don't underestimate the importance of that argument. If you consider mobile devices that want to browse the Web, then depending on the constraints of the device, a hardware solution may be required to view video with any kind of reasonable performance. A mandate of Theora is effectively dictating to those mobile vendors that they have to create custom hardware that can play back Theora video. Bullshit. How long will it take for HTML5 to have a reasonable penetration? You don't think there will be hardware implementations by then if its part of the spec? That's a completely disingenious argument. Given that such devices may already need a hardware solution for existing video like H.264, it seems unreasonable for HTML5 to mandate what hardware a vendor has to develop just to browse Web video on a mobile device. Cop out. Its completely reasonable. If you have to use hardware to implement it, then that's the price you pay (and then the customers pay, because you're going to pass the cost along), or perhaps you choose not to be HTML5 compliant on that device. To threaten the design of a supposedly open and free spec because of the potential hardware needs to implement is what is unreasonable. That amounts to Apple, et al, holding the community hostage to your commercial desires. I'm sorry, I'm not going to help Apple screw me over. I will not quietly accept the w3c ensconcing a non-free codec into HTML5 and subjecting me and everyone else to another decade or so of being screwed over by avaricious big companies. Or put another way, imagine that GIF was an open format but PNG was IP-encumbered. Would you really want to limit the Web to displaying only GIFs just because it was the only open image format available? Once again you twist the argument to the point of breaking. Noone is saying anything about restricting the formats that are allowed. We're only talking about a baseline requirement. In other words, yeah, I would be fine with requiring GIF as a baseline in that sort of spec (which is de facto what we have anyway), but PNG et al can still be implemented, just as you can still implement H.264 if you like. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
Re: [whatwg] Ogg Vorbis / Theora vote
At 13:20 -0500 11/12/07, John Lianoglou wrote: Apologies to those that are, in fact, irritated by us Ogg-supporting lobbiers; please understand that we are all simply motivated by our interest in a vision to keep the Internet a free, vendor-neutral publishing landscape, to the greatest degree practically feasible. This is a goal we at Apple, at least, share; and I believe also many others do as well. -- David Singer Apple/QuickTime
Re: [whatwg] HTML 5, OGG, competition, civil rights, and persons with disabilities
Dave Singer wrote: At 19:04 -0500 11/12/07, Jeff McAdams wrote: Dave Singer wrote: At 13:45 -0500 11/12/07, Fernando wrote: Please reconsider the decision to exclude the recommendation of the Theora/OGG Vorbis codec in HTML 5 guidelines. This entire discussion is founded on a major misapprehension: that there has been a decision, and that decision was to exclude. This is simply not true; there is no decision either to include or exclude. There is a recognition that work is needed. I and others have spent a great deal of time on this problem already, working with a number of people, including the W3C staff. Many of us -- maybe all of us -- agree we need to find a solution that enables broad interoperability and is in accord with w3c and web practices. We have not yet reached consensus on having found it. That's all. A decision was made to move away from using the ogg family of technologies. No. Yes. A decision was made to have the text reflect the facts that (a) no-one is happy with a 'should' and (b) that work is ongoing to find a solution (which might be Ogg, or something else). That's all. The text was changed from a SHOULD implement Ogg et all to a completely non-descriptive text. If things are up in the air, then why change it? Just leave the text and have the discussion. If a better solution is arrived at, *then* change the text of the spec. What need is there to change the current draft of the spec away from ogg et all? That indicates a move away from ogg et al by this body, and you're surprised why people get up in arms? Sorry, again, doesn't pass the smell test. While not a final decision, it is a threatening decision to those of us that value freedom and openness and don't appreciate being screwed by big companies. Listen to what the people are saying. Oh, I am listening. It's by no means clear that the Ogg crowd is at all. I'm also spending efforts working on finding a solution. I don't count lamenting I want my ogg on this list as spending efforts at all. Maybe you should listen to the meta-argument, then. I'm sick and tired of getting screwed by big companies (including Apple), and I will *not* quietly accept it. If the text is changed to move away from a free and open solution to something that is going to be encumbered, you better believe I'm going to be up in arms about it, and I will not apologize for it. This change is exactly that sort of change. I would much rather Apple not implement HTML5 at all, so I can call Apple out on it in the marketplace, than to let an encumbered technology be ensconced in a standard like HTML5. And, in the past, these exact sorts of maneuvering is exactly the sort of behavior that has led to big companies getting end-user-screwing technologies ensconced into specs and standards. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
Re: [whatwg] Ogg Vorbis / Theora vote
Well, I admit you're at least somewhat right. On a totally unrelated but not so unrelated matter, I'd like to see the efforts to form a single source tree for KHTML/WebKit to march on faster. (Then when George Staikos or another KDE guy implements Theora VIDEO you can offer it for free to your customers :-D ) (Sorry, I couldn't resist the joke. I'm sure you'll be able to patch that functionality out if someone makes a credible threat against Theora.) El Mar 11 Dic 2007, Dave Singer escribió: At 13:20 -0500 11/12/07, John Lianoglou wrote: Apologies to those that are, in fact, irritated by us Ogg-supporting lobbiers; please understand that we are all simply motivated by our interest in a vision to keep the Internet a free, vendor-neutral publishing landscape, to the greatest degree practically feasible. This is a goal we at Apple, at least, share; and I believe also many others do as well. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Don't read any sky-writing for the next two weeks. signature.asc Description: This is a digitally signed message part.
Re: [whatwg] several messages regarding Ogg in HTML5
At 23:20 +0100 11/12/07, alex wrote: I have seen this argument pop up now and again, but I have failed to actually find the URL to this, could someone post it please? Hi. It was a record of a discussion at the HTML WG meeting, but since I wrote it, I guess I can re-post it here (and it doesn't mention names either). * * * Preamble: The HTML5 specification contains new elements to allow the embedding of audio and video, similar to the way that images have historically been embedded in HTML. In contrast to today's behavior, using object, where the behavior can vary based on both the type of the object and the browser, this allows for consistent attributes, DOM behavior, accessibility management, and so on. It also can handle the time-based nature of audio and video in a consistent way. However, interoperability at the markup level does not ensure interoperability for the user, unless there are commonly supported formats for the video and audio encodings, and the file format wrapper. For images there is no mandated format, but the widely deployed solutions (PNG, JPEG/JFIF, GIF) mean that interoperability is, in fact, achieved. Licensing: The problem is complicated by the IPR situation around audio and video coding, combined with the W3C patent policy http://www.w3.org/Consortium/Patent-Policy-20040205/. W3C seeks to issue Recommendations that can be implemented on a Royalty-Free (RF) basis. Note that much of the rest of the policy may not apply (as it concerns the specifications developed at the W3C, not those that are normatively referenced). However, it's clear that at least RF-decode is needed. Candidates: There are, of course, a number of codecs and formats that can be considered. A non-exhaustive list might include a variety of 'public' codecs, as well, of course, as proprietary ones: a) open-source projects: the ogg family (vorbis, theora), and the BBC Dirac video codec project b) Current ISO/IEC (MPEG) standard codecs, notably the MPEG-4 family: AVC (14496-10, jointly published with the ITU as H.264), AAC (part of 14496-3) c) Older MPEG codecs, notably MPEG-2 layer 3 (aka MP3), MPEG-2 layer 1 and 2 audio, and maybe MPEG-4 part 2 video (14496-2) d) Current standard codecs from other bodies; SMPTE VC-1, for example e) Older standards from other bodies: ITU recommendations H.263 (with or without its many enhancement annexes) or even H.261 f) Very old standard codecs, formats, or industry practices; notably the common format for video from digital still cameras (Motion JPEG with uncompressed audio in an AVI wrapper) g) Proprietary codecs, such as Dolby AC-3 audio Candidate concerns: There are concerns or issues with all of these: a) a number of large companies are concerned about the possible unintended entanglements of the open-source codecs; a 'deep pockets' company deploying them may be subject to risk here; b) the current MPEG codecs are currently licensed on a royalty-bearing basis; c) this is also true of the older MPEG codecs; though their age suggests examining the lifetime of the patents; d) and also SMPTE VC-1 e) H.263 and H.261 both have patent declarations at the ITU. However, it is probably worth examining the non-assert status of these, which parts of the specifications they apply to (e.g. H.263 baseline or its enhancement annexes), and the age of the patents and their potential expiry. f) This probably doesn't have significant IPR risk, as its wide deployment in systems should have exposed any risk by now; but it hardly represents competitive compression. g) Most proprietary codecs are licensed for payment, as that is the business of the companies who develop them. Other licensing concerns: It's also possible that there are other issues around licensing: a) variations in licensing depending on filed patents in various geographies b) restrictions on usage, or fees on usage, other than the fees on implementation (e.g. usage fees on content sold for remuneration). It's not entirely clear, also, whether 'implementing' HTML means the ability to decode and display, or whether encoding is also included. Including encoding in the equation might significantly complicate matters. Possible action: The members of the WG are engineers, not IPR experts. There is general consensus that a solution is desirable, but also that engineers are not well placed to find it: a) they are not experts in the IPR and licensing field; b) many of them are discouraged by their employers from reading patents or discussing IPR. It's clear that the December workshop cannot be silent on this subject. There must be recognition of the issue and evidence of at least efforts to solve it, and preferably signs of progress. It is probable that this is best handled in parallel with the technical work, and headed by someone 'technically neutral' and qualified, such as W3C technical and legal staff. A good start would be to: a)
Re: [whatwg] HTML 5, OGG, competition, civil rights, and persons with disabilities
Agreed. Let's just return the text, put a MUST in place of the SHOULD, and continue the discussion. If you find your solution within one year, great, s/Ogg/Yoursolution/g. If not, bite the bullet and go ahead. El Mar 11 Dic 2007, Jeff McAdams escribió: Dave Singer wrote: At 19:04 -0500 11/12/07, Jeff McAdams wrote: Dave Singer wrote: At 13:45 -0500 11/12/07, Fernando wrote: Please reconsider the decision to exclude the recommendation of the Theora/OGG Vorbis codec in HTML 5 guidelines. This entire discussion is founded on a major misapprehension: that there has been a decision, and that decision was to exclude. This is simply not true; there is no decision either to include or exclude. There is a recognition that work is needed. I and others have spent a great deal of time on this problem already, working with a number of people, including the W3C staff. Many of us -- maybe all of us -- agree we need to find a solution that enables broad interoperability and is in accord with w3c and web practices. We have not yet reached consensus on having found it. That's all. A decision was made to move away from using the ogg family of technologies. No. Yes. A decision was made to have the text reflect the facts that (a) no-one is happy with a 'should' and (b) that work is ongoing to find a solution (which might be Ogg, or something else). That's all. The text was changed from a SHOULD implement Ogg et all to a completely non-descriptive text. If things are up in the air, then why change it? Just leave the text and have the discussion. If a better solution is arrived at, *then* change the text of the spec. What need is there to change the current draft of the spec away from ogg et all? That indicates a move away from ogg et al by this body, and you're surprised why people get up in arms? Sorry, again, doesn't pass the smell test. While not a final decision, it is a threatening decision to those of us that value freedom and openness and don't appreciate being screwed by big companies. Listen to what the people are saying. Oh, I am listening. It's by no means clear that the Ogg crowd is at all. I'm also spending efforts working on finding a solution. I don't count lamenting I want my ogg on this list as spending efforts at all. Maybe you should listen to the meta-argument, then. I'm sick and tired of getting screwed by big companies (including Apple), and I will *not* quietly accept it. If the text is changed to move away from a free and open solution to something that is going to be encumbered, you better believe I'm going to be up in arms about it, and I will not apologize for it. This change is exactly that sort of change. I would much rather Apple not implement HTML5 at all, so I can call Apple out on it in the marketplace, than to let an encumbered technology be ensconced in a standard like HTML5. And, in the past, these exact sorts of maneuvering is exactly the sort of behavior that has led to big companies getting end-user-screwing technologies ensconced into specs and standards. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Among the lucky, you are the chosen one. signature.asc Description: This is a digitally signed message part.
Re: [whatwg] HTML 5, OGG, competition, civil rights, and persons with disabilities
Maybe you should listen to the meta-argument, then. I'm sick and tired of getting screwed by big companies (including Apple), and I will *not* quietly accept it. That's not unreasonable, but you have yet to give a solid technical reason for reverting to the old text, so far your only argument is that ogg should be kept because it is FOSS, which on its own is insufficient. My understanding based on the numerous comments from Ian is that a goal of the video and audio specs is that they can be implemented in FOSS, and knowing Ian there is basically no chance of anyone slipping anything that couldn't be passed him. As far as wording goes using the word SHOULD support is far too weak for HTML5, as SHOULD is relatively meaningless, a much better requirement is that the wording be MUST support ...; this is a sensible as having a spec that says SHOULD support ogg/vorbis and ogg/theora is fairly useless -- all that will happen is that browser vendors (Apple, Mozilla, Opera, etc) will once again be in a position where the spec's wording means nothing and we end up with yet another standard which is not tied to whatever becomes the actual de facto standard, as implemented by the majority browser. This is much worse for site compatibility for every other browser as it then becomes necessary to determine what the de facto standard actually *is*. For this reason the old text was insufficient and Ian changed the text to indicate that the final wording had not yet been decided. This is not an indication that ogg transport or that the vorbis or theora codecs are being ignored, it is merely an indication that a decision has not yet been made as to the final wording. Note: I can't really comment on the actual issues involved in the codec or transport selection as that's not a region i specialise in. --Oliver
Re: [whatwg] several messages regarding Ogg in HTML5
At 17:30 -0500 11/12/07, Jeff McAdams wrote: Apple and Nokia's stated reasons for objecting to Theora are crap... I can't speak for Nokia. But you are mis-characterizing Apple. We have expressed concern, and suggested that perhaps someone who can be seen to be independent, and is competent in IPR issues and permitted to read patents and discuss licenses, look into the issue. Folks, engineers are * not patent experts (indeed, many companies don't allow their engineers to read patents unless instructed) * not lawyers * now always seen to be independent or neutral * not generally involved in licenses This is not a recipe for progress. We'd be better off discussing technical issues that would inform a decision; questions like a) what compression ratio/quality is needed? Is h.261 'good enough'? What about audio? b) do we need alpha support? c) what audio compression level is needed? Is IMA 4:1 good enough? Could we live with uncompressed PCM? d) what container format features are needed? Incremental files? Seekability and indexing? (These tend to be in conflict, by the way). e) what audio channel count is needed? f) what access protocols should be supported? One assumes http; what about rtsp/rtp? authentication in rtsp? which rtsp? shoutcast? I am sure there are many other questions... -- David Singer Apple/QuickTime
[whatwg] The truth about Nokias claims
This is an except from an MPEG-LA press release: Owners of patents or patent applications determined by MPEG LA’s patent experts to be essential to the H.264/AVC standard (“standard”) include Columbia University, Electronics and Telecommunications Research Institute of Korea (ETRI), France Télécom, Fujitsu, IBM, Matsushita, Mitsubishi, **Microsoft**, Motorola, **Nokia**, Philips, Polycom, Robert Bosch GmbH, Samsung, Sharp, Sony, Thomson, Toshiba, and Victor Company of Japan (JVC). So lets review the three companies loudly objecting to OGG, misrepresenting its status and continuing to fuel this debate: Apple: Has heavy investment in H.264, AAC and DRM via iTunes. Known for proprietry hardware lock-in. Microsoft: Heavy investment in WMV and DRM. 'Essential patent holder' in H.264. Major shareholder in Apple. Known for proprietry browser and OS lock-in and standards disruption. Nokia: 'Essential patent holder' and heavy invester in H.264. Argued for software patents in EU. Stop believing their lies! Don't you think it's weird that Nokia is complaining about patents while simultaneous holding numerous video related ones? OGG/Vorbis/Theora are open and as safe as codecs can get. Its patent risks are practically non-existent. It has no licensing fees. It is easy to implement across all major (and most minor) platforms. It is the format of choice - unless you're Nokia, Apple or Microsoft. Finally, nobody has mentioned that the licensing terms on H.264/AVC state that in about 8 years from now ALL internet H.264 content and software becomes licensable. Sites will have to pay to use it. It is NOT FREE, just 'on hold' until adoption becomes widespread and enforcement more practical. When that happens guess who makes billions? Nokia and Microsoft. These companies have no right to be distrupting this list and modifying the standard to their whims. Their business interests are of no interest here. This is a PUBLIC standard, not a proprietry one. Put the OGG reference back in the HTML5 draft, exactly as it was, as it was originally agreed, as many have requested - AS IS APPROPRIATE! Shannon [EMAIL PROTECTED]
Re: [whatwg] several messages regarding Ogg in HTML5
Dave Singer wrote: At 17:30 -0500 11/12/07, Jeff McAdams wrote: Apple and Nokia's stated reasons for objecting to Theora are crap... I can't speak for Nokia. But you are mis-characterizing Apple. We have expressed concern, and suggested that perhaps someone who can be seen to be independent, and is competent in IPR issues and permitted to read patents and discuss licenses, look into the issue. Fine, then as a show of good faith, revert the text while this goes on. Yes, I am suspicious of Apple's motives, *EXTREMELY* suspicious. As I mentioned in another email, I've never been disappointed when I assumed the worst of a big company in a standards setting context. Listen to what the people are saying. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
[whatwg] Reasons for moving Ogg to MUST status (was Re: HTML 5, OGG, competition, civil rights, and persons with disabilities)
That's not unreasonable, but you have yet to give a solid technical reason for reverting to the old text, Reasons to put the Ogg tech suite back on the spec: - it's Free (who here hates beer or freedom?) - it's patent-unencumbered (this is a FACT) - it's technically very good (Theora) or even superb (Vorbis and FLAC) - it's widely available and readily installable - it's being integrated in popular Web browsers RIGHT NOW - it enables little guys to produce content at minimal cost COME ON, what other reasons do you need? so far your only argument is that ogg should be kept because it is FOSS, which on its own is insufficient. I just gave you N more reasons. As far as wording goes using the word SHOULD support is far too weak for HTML5, as SHOULD is relatively meaningless, a much better requirement is that the wording be MUST support ...; this is a sensible as having a spec that says SHOULD support ogg/vorbis and ogg/theora is fairly useless -- all that will happen is that browser vendors (Apple, Mozilla, Opera, etc) will once again be in a position where the spec's wording means nothing and we end up with yet another standard which is not tied to whatever becomes the actual de facto standard, as implemented by the majority browser. This is much worse for site compatibility for every other browser as it then becomes necessary to determine what the de facto standard actually *is*. This is not the year 2000. Mozilla and Opera are embedding Theora video. That's a user base large enough to force the rest of the players to get with the program. Solid technical, philosophical and practical reasons to move Ogg to MUST. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ When one burns one's bridges, what a very nice fire it makes. -- Dylan Thomas signature.asc Description: This is a digitally signed message part.
Re: [whatwg] Removal of Ogg is *preposterous*
On Dec 11, 2007, at 9:13 AM, Charles McCathieNevile wrote: On Tue, 11 Dec 2007 17:11:57 +0100, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 11 Dec 2007, at 13:36, Maik Merten wrote: The old wording was a SHOULD requirement. No MUST. If the big players don't want to take the perceived risk (their decision) they'd still be 100% within the spec. Thus I fail to see why there was need for action. There's a question within the W3C Process whether patents that are covered by a SHOULD via a reference are granted a RF license similarly to anything that MUST be implemented. Both Nokia and MS raised concerns about this relating to publishing the spec as a FPWD. And these concerns are total rubbish (as pointed out by Apple and others): FWIW that was my personal opinion based on reading the patent policy, not an official position of Apple Inc. Regards, Maciej
Re: [whatwg] Removal of Ogg is *preposterous*
At 20:21 -0500 11/12/07, Manuel Amador (Rudd-O) wrote: El Mar 11 Dic 2007, Dave Singer escribió: At 13:09 -0500 11/12/07, Manuel Amador (Rudd-O) wrote: Fact: Vorbis is the *only* codec whose patent status has been widely researched, nearly to exhaustion. You are clearly completely unaware of the extensive analysis done of other codecs, including those that are licensed. And all those other analyses have yielded us this stalemate? I am not yet ready to say we are at a stalemate here; I simply believe that it is desirable to get everyone (including Nokia and Microsoft as well as Apple) on board. That's in all our interests, and I continue to work to that end. That is a testament to the value of standards. No one ever said you didn't make standards. I claimed you made *proprietary* standards. That is an oxymoron. Ogg is NOT a standard; it is an open-source effort. H.264 (for example) is NOT proprietary, but a multi-vendor-developed international standard. But you knew this; you're just trying to use emotional terms. Playpens where only the big boys get to play and the rest get to pay. But in all fairness, I should bring up that you also made Zeroconf possible, and that's awesome. Thank you. -- David Singer Apple/QuickTime
Re: [whatwg] Asynchronous database API feedback
On Dec 11, 2007, at 3:02 PM, Oliver Hunt wrote: It's clear that most people here feel passionately that this is the wrong thing to do. Perhaps it's best that we table this until something like workerpools are in the spec. Worker pools do not resolve the problem, even if you were to force any synchronous IO to be performed on a worker thread (where by force i mean attempting synchronous io on the main/ui thread would throw an exception or similar). The problem is that once you have multiple threads, and those threads are unable to modify the DOM (allowing the DOM to be modified from a worker thread would cause too much havoc -- there is much to much JS out there to allow JS to become multithreaded), so either you defer the synchronous IO into a async callback model to tell you when the io has completed -- you are now using the synchronous api to implement your own async api -- or you have thread constructs such as a rendezvous, which will eventually end up in the UI thread, thereby reducing any thread synchronous IO back into a blocking operation. Worker threads + sync IO available only on the worker thread do have one advantage over a pure async API: you can batch multiple requests, handle them using relatively simple code on your worker thread, and get a single notification on the main thread when all of that is done. There are many cases where this would be handy. I think the biggest disadvantage is that it would be more complicated to specify and implement. And in the end it won't hurt to have both. (I assume we are all talking about shared-nothing message-passing threads as in Gears.) Regards, Maciej
Re: [whatwg] Video codec requirements changed
On Dec 11, 2007, at 3:27 PM, L. David Baron wrote: On Tuesday 2007-12-11 02:39 +, Ian Hickson wrote: I've temporarily removed the requirements on video codecs from the HTML5 spec, since the current text isn't helping us come to a useful interoperable conclusion. When a codec is found that is mutually acceptable to all major parties I will update the spec to require that instead and then reply to all the pending feedback on video codecs. http://www.whatwg.org/issues/#graphics-video-codec The text you replaced the requirements with [1] includes the requirement that the codec: # is not an additional submarine patent risk for large companies Is this something that can be measured objectively, or is it a loophole that allows any sufficiently large company to veto the choice of codec for any reason it chooses, potentially including not wanting the video element to succeed in creating an open standard for video on the Web? I think there are some objective criteria that can help determine the scope of risk: 1) Is the codec already in use by deep-pockets vendors? 2) Was the codec developed through an open standards process with strong IP disclosure requirements? 3) Is the codec old enough that any essential patents must be expired? 4) Has an exhaustive patent search been done (this can't be done by most large companies since doing a patent search ironically increases your financial exposure to patent infringement claims)? 5) Is indemnification available? Here are the answers I know of for some well-known video codecs: H.264: 1) yes 2) yes 3) no 4) no (I think) 5) no Theora: 1) no 2) no 3) no 4) no 5) no H.261: 1) yes 2) yes 3) yes 4) no 5) no Here are the answers for some popular audio codecs: MP3: 1) yes 2) yes 3) no (but in a few years, 2 or 3 I think, it will be) 4) no 5) no Vorbis: 1) maybe (I've heard game vendors cited, not sure which ones) 2) no 3) no 4) yes 5) no AAC: 1) yes 2) yes 3) no 4) no 5) no I'm not 100% sure on all of these answers, but I hope these are the kind of criteria applied, and not just purely subjective considerations. Regards, Maciej
Re: [whatwg] Removal of Ogg is *preposterous*
Le 12 déc. 2007 à 03:21, Manuel Amador (Rudd-O) a écrit : Where would we be today if the HTML spec didn't specify jpg, gif, and png as baseline standards for the image tag? FWIW, in fact the HTML 4.01 spec did NOT mandate any image formats. http://www.w3.org/TR/html4/struct/objects.html#edef-IMG This attribute specifies the location of the image resource. Examples of widely recognized image formats include GIF, JPEG, and PNG. Plus the compression algorithm in GIF was covered by patents. Unisys woke up. The Burn All GIFs campaign started. Many shareware and freeware disappeared. http://en.wikipedia.org/wiki/GIF#Unisys_and_LZW_patent_enforcement -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool
Re: [whatwg] several messages regarding Ogg in HTML5
I've tried to pick a representative sample of the e-mails sent since my last e-mail. The ones I didn't reply to have been saved to the outstanding video codec feedback folder, and I'll reply to them once we have a real solution to the problem of finding a common codec. http://www.whatwg.org/issues/#graphics-video-codec (The list is updated daily, so it doesn't yet have all the new e-mail.) I would encourage new participants to read this blog entry from Chris Double, the Mozilla engineer who implemented most of video in Firefox, as it summarises the issues nicely: http://www.bluishcoder.co.nz/2007/12/video-element-and-ogg-theora.html That said: On Tue, 11 Dec 2007, alex wrote: But because of the nature of submarine patents, I don't quite see how you can actually find a codec that fits the requirements? You can't use an encumbered codec obviously, and the rest is up for grabs by people who misuse legislation for their own benefit? So what else is there (excepting codecs that are outdated in every way that is)? That said, my vote still lies with ogg. There are several solutions we might find. For example: * We could convince the MPEG-LA group to provide a royalty free license for one of their codecs, e.g. H.264 Baseline. * We could wait for Ogg to be used by a large fraction of the Web population, as that would provide the business reason for companies like Apple to support Ogg. * We could use an codec old enough that all patents claimed to be essential to its implementation have expired. The discussions to these ends are happening. On Tue, 11 Dec 2007, Jeff McAdams wrote: Then you need to stop work on a HTML5 spec right now because *EVERYTHING* has a submarine patent risk to it. It's a matter of risk management. Some things are worth the risk, others might not be. Video codecs tend to be _extremely_ risky. Apple and Nokia's stated reasons for objecting to Theora are crap...they don't pass the smell test. Ian, you're being taken for a ride, here. To be honest at the end of the day it doesn't actually matter _why_ Apple and Nokia won't implement Ogg Theora. If they don't implement it, we don't have interoperability, and we've failed in our goal. Just revert the text and go back to Theora as the codec of choice and end this charade of trying to look like you're taking everyone's concerns into account because its clear that you aren't. Apple and Nokia are, so far, getting their way, despite the huge public outcry that you're seeing, and that should tell you something, and tell you something loud and clear. Actually, right now _nobody_ is getting their way. The spec doesn't say _what_ codec should be used. Requiring Ogg Theora support would be not taking everyone's needs into account. Right now, the spec just lists everyone's needs, without a solution. In the absence of IP constraints, there are strong technical reasons to prefer H.264 over Ogg. For a company like Apple, where the MPEG-LA licensing fee cap for H.264 is easily reached, the technical reasons are very compelling. Except that there are *KNOWN* IP (god how I hate that term) constraints with H.264. Indeed, H.264 is unacceptable as well. At least with Theora we can avoid any known ones. All codecs have a risk of submarine patents (though with extensive having been done for Theora, at least that risk is lowered, if not eliminated completely), so that argument is a wash, its on both sides of the equation, so it cancels out. Not for companies that have already taken the risk of one of the codecs already. For example, if Opera ships with Ogg Theora, then they'd probably be less interested in also supporting Dirac (another theoretically free video codec), since doing so would increase their potential patent attack surface. (Also, the smaller the company, the less the risk. Companies like Microsoft, Apple, and Google take on huge risks. Just look at Microsoft's track record recently getting sued for patent infringements, or Apple's track record of being sued over patents that the iPhone aledgedly infringes.) The problem is that if the big players don't follow the spec, even the SHOULD requirements, then the spec is basically pointless. What we want isn't that some people support Ogg, what we fundamentally want is that _everyone_ support the same codec, whatever that may be. Then revert the text and make it a MUST. As far as I know, there are no other codecs out there that are not encumbered. This is the whole reason for existence of Theora, at least at the time, and I don't know that this has changed in the few years since it was designed. There's no point putting a MUST in the spec if we _know_ that it won't be followed. We're not writing specs to satisfy a theoretical need, we're trying to get actual interoperability across all browsers. If you want a baseline that everyone can implement without
Re: [whatwg] persistent storage changes
For what it's worth the changes to persistent storage have my vote. As a web author and user it strikes the right balance between functionality and privacy. Just one thing though, since this storage could also be used for 'offline applications' should some mention be made regarding access from a page hosted at 127.0.0.1 or via the file: protocol? Also I was curious about what Firefox was putting in mine but it looks like I need a 3rd-party sqlite app to do it. Should the spec recommend user-agents provide a direct method of access (even though some data may be base64 or obsfucated)? Shannon [EMAIL PROTECTED] Ian Hickson wrote: I just checked in a change to make globalStorage far simpler -- I dropped all the domain manipulation stuff, and made it same-origin instead. I also dropped StorageItem and just made the Storage stuff return strings.
Re: [whatwg] several messages regarding Ogg in HTML5
At 2:19 + 12/12/07, Ian Hickson wrote: I would much rather Apple not implement HTML5 at all, so I can call Apple out on it in the marketplace, than to let an encumbered technology be ensconced in a standard like HTML5. I entirely agree that it would be unacceptable for HTML5 to require encumbered technology. ++ without an appropriate grant of license (I think almost all codecs have some encumbrances -- the BBC owns patents in Dirac, for example; the question is the nature of the license.) -- David Singer Apple/QuickTime
Re: [whatwg] Removal of Ogg is *preposterous*
On Dec 11, 2007 4:46 PM, Manuel Amador (Rudd-O) [EMAIL PROTECTED] wrote: Apple and Nokia seem to think that there *are* hamburgers in the moon, and that those hamburgers will cost them billions of dollars in submarine sandwich lawsuits. Yes, it seems that way. Or, at least, the edits to the specification speak for themselves. Of course, that's what they are *saying*. It doesn't take a Feynman or a Chomsky to understand the real reason why they want the Ogg hamburger off HTML5. That sounds too accusatory to me. I'd be surprised to find malice, immorality, or profiteering at the root. I do think the recent changes to the document are supported by weak pseudo-legal doubletalk from engineers afraid to get in trouble. Don't expect good quality specifications from such a climate. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [whatwg] Video codec requirements changed
On 12/12/2007, Maciej Stachowiak [EMAIL PROTECTED] wrote: I think there are some objective criteria that can help determine the scope of risk: 1) Is the codec already in use by deep-pockets vendors? ... Vorbis: 1) maybe (I've heard game vendors cited, not sure which ones) Microsoft (Bungie): Halo id: Doom 3, Quake 4 RockStar: Grand Theft Auto, San Andreas Activition (Red Octane): Guitar Hero II Blizzard: World of Warcraft The US Army: America's Army many more listed at: http://wiki.xiph.org/index.php/Games_that_use_Vorbis cheers, Conrad.
Re: [whatwg] Removal of Ogg is *preposterous*
On Dec 11, 2007 6:51 PM, David Hyatt [EMAIL PROTECTED] wrote: SHOULD is toothless. Spefications aren't laws. MUSTs are toothless as well. It carries absolutely no weight. I don't think it's appropriate for such weak language to be in the HTML5 spec. It should either be a MUST (which is inappropriate at this juncture for reasons that Dave Singer. Ian Hickson and myself have posted about in previous messages) or just not be mentioned at all. It isn't weak language. It places the blame squarely on the party who fails to meet the requirement. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [whatwg] HTML 5, OGG, competition, civil rights, and persons with disabilities
On Dec 11, 2007 6:26 PM, Jeff McAdams [EMAIL PROTECTED] wrote: I would much rather Apple not implement HTML5 at all, so I can call Apple out on it in the marketplace, than to let an encumbered technology be ensconced in a standard like HTML5. You know, I've been looking at the current HTML5 draft over the course of the day. I've read it pretty thoroughly. And I can't for the life of me find the bit that ensconces an encumbered technology. Would you be so kind as to point me to it? I ask because all I see is a strongly-worded paragraph about the need for an open, interoperable, unencumbered format. Perhaps my eyes are going. -- Bureaucrat Conrad, you are technically correct -- the best kind of correct.
Re: [whatwg] Video codec requirements changed
On 12/11/07, L. David Baron [EMAIL PROTECTED] wrote: # is not an additional submarine patent risk for large companies Is this something that can be measured objectively, or is it a loophole that allows any sufficiently large company to veto the choice of codec for any reason it chooses, potentially including not wanting the video element to succeed in creating an open standard for video on the Web? I agree as well that that sentence is in need of better wording as to avoid what may be an ambiguous statement. -Ivo
Re: [whatwg] whatwg Digest, Vol 45, Issue 16
On Dec 11, 2007 5:30 PM, [EMAIL PROTECTED] wrote: The whole point of the change was to make the point that we need something that will not screw you. Ogg isn't a solution, as it won't be implemented by Apple and Microsoft. If we require Ogg, then what will happen is the big players will support something else, then that will become the de-facto standard, and you will get screwed. What we _want_ is for everyone to support the same codec. We don't get that by having a SHOULD-level requirement for Ogg. And we should implement OOXML support too right, just to make Microsoft happy? I don't think that's the right way to do things. As someone who's trained as a civil engineer, we were taught there was a right way and wrong way to do things. The most correct way is to follow the spec. But this has the premise that the spec is not screwed up. If you give us a screwed up spec, we're doomed. This whole issue about submarine patents is bullshit. The reason is this: If such a patent exists, Apple/Nokia/Microsoft/et all would have found it, and waved it in your face. After all, they've had months to go look for it. Then make it a MUST-level requirement. There is no other solution. If we give in to the big companies trying to screw us during the spec design, then we're surely screwed, by design. At least, if we make the spec MUST-level for Theora, we can bring pressure to bear on Microsoft, Apple, Nokia, and whoever else by shining a spotlight on their non-conformance to the spec. Exactly. Which browsers are acid2 compliant again? Why was that? Theora *is* the baseline for free and open video, full stop. Everything else reasonable is encumbered (at least to my knowledge). Assuming I'm right, discussion over. For anyone to claim this is not so, they will have to pull out patents to show why this is not so. Otherwise, they should shut up about it. Ogg is _a_ choice, which provides freedom for some but not everyone. We need a codec that works for everyone. Then you might as well give up on HTML5 right now. Exactly. You can never please everyone. Do the drug companies like FDA regulations? Hell no. Do we need stringent standards from FDA? Hell yes. spec, and I would say make it a MUST and yell loud and long at Apple, MS, Nokia and others when they claim conformance to HTML5 and don't implement it. Exactly! I think that's what everyone wants. The problem is that Ogg is not such a codec -- Apple, for instance, can't implement Ogg without fear of being sued. Pardon me, but the sanitized version just isn't strong enough, here. Bullshit, bullshit, bullshit. Exactly. Tell Apple to show us the patents they're worried about. They've had time to go look up those damned patents. I assure you that the change was made in good faith; I (sadly) received no money for the change. I really wish I had. Your role here is extremely critical. Surely there's someone that you'd trust, that can do the appropriate research for you, so that you can see if Jeff et all are speaking the truth, or if Apple/Nokia is speaking the truth (patent, legal, etc)? -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=j1G-3laJJP0feature=related
Re: [whatwg] several messages regarding Ogg in HTML5
On Dec 11, 2007 7:47 PM, Dave Singer [EMAIL PROTECTED] wrote: I am sure there are many other questions... One question might concern the value in standardizing a shell API for proprietary codecs. If there are no freely implementable solutions, maybe the spec should drop it. Personally, I think it would be pretty offensive to ship an H.264 playing application and call it standards-based or some nonsense like that. I understand that the WG is a poor place to settle legal issues with codecs. However, it's pretty poor form to endlessly handwave objections while leaving the API in the document, as if there were no target codecs. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [whatwg] Removal of Ogg is *preposterous*
That sounds too accusatory to me. I'd be surprised to find malice, immorality, or profiteering at the root. I do think the recent changes to the document are supported by weak pseudo-legal doubletalk from engineers afraid to get in trouble. Don't expect good quality specifications from such a climate. Look, guys. I don't think I've explained myself well, partly because I've come on too strong. There is no evidence of malice. There's also no evidence of profiteering. There *is* evidence of immorality, if you define spreading falsehoods as immoral (see Ogg is proprietary comment). The rest of the discussion is basically a disagreement on how risky it would be to implement Ogg on browsers. Some of us don't feel it's risky, others feel it's too risky to even consider (I understand -- billions of dollars may be at stake). The spec is also very good, overall. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Things past redress and now with me past care. -- William Shakespeare, Richard II signature.asc Description: This is a digitally signed message part.
Re: [whatwg] Removal of Ogg is *preposterous*
El Mié 12 Dic 2007, Robert Sayre escribió: On Dec 11, 2007 6:51 PM, David Hyatt [EMAIL PROTECTED] wrote: SHOULD is toothless. Spefications aren't laws. MUSTs are toothless as well. It carries absolutely no weight. I don't think it's appropriate for such weak language to be in the HTML5 spec. It should either be a MUST (which is inappropriate at this juncture for reasons that Dave Singer. Ian Hickson and myself have posted about in previous messages) or just not be mentioned at all. It isn't weak language. It places the blame squarely on the party who fails to meet the requirement. Agreed with you, Robert. If SHOULD carries absolutely no weight... then why don't we just leave the paragraph there? Stop eluding this question. Oh, prepare for a barrage of uneducated comments. My article just hit Digg front page and is climbing rapidly in diggs. I edited the text on the article a bit to discourage uneducated participation on the list. -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Q: How many Zen masters does it take to screw in a light bulb? A: None. The Universe spins the bulb, and the Zen master stays out of the way. signature.asc Description: This is a digitally signed message part.
Re: [whatwg] Video codec requirements changed
I'd rephrase it as # Has had traction, time and exposure in the market, enough so patent threats should have arisen already. Which is basically the same meaning, and includes Ogg Vorbis technology. Because if America Online (Winamp) is not a big company, then I don't know the meaning of the word big. I'd also not use a hash to denote a bullet point ;-). El Mar 11 Dic 2007, Ivo Emanuel Gonçalves escribió: On 12/11/07, L. David Baron [EMAIL PROTECTED] wrote: # is not an additional submarine patent risk for large companies Is this something that can be measured objectively, or is it a loophole that allows any sufficiently large company to veto the choice of codec for any reason it chooses, potentially including not wanting the video element to succeed in creating an open standard for video on the Web? I agree as well that that sentence is in need of better wording as to avoid what may be an ambiguous statement. -Ivo -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Abandon the search for Truth; settle for a good fantasy. signature.asc Description: This is a digitally signed message part.
Re: [whatwg] Removal of Ogg is *preposterous*
On Dec 11, 2007 8:31 PM, Dave Singer [EMAIL PROTECTED] wrote: That is an oxymoron. Ogg is NOT a standard; it is an open-source effort. H.264 (for example) is NOT proprietary, but a multi-vendor-developed international standard. A multi-vendor effort does not make the codec non-proprietary. For example, it could be the offering of a cartel. In this case, you have to pay to use it, so it's pretty clear that it is proprietary. At least for those of us that speak English as a first language. http://www.answers.com/proprietaryr=67 -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [whatwg] more discussion regarding codecs (Was: whatwg Digest, Vol 45, Issue 16)
On Tue, 11 Dec 2007, bofh wrote: The whole point of the change was to make the point that we need something that will not screw you. Ogg isn't a solution, as it won't be implemented by Apple and Microsoft. If we require Ogg, then what will happen is the big players will support something else, then that will become the de-facto standard, and you will get screwed. What we _want_ is for everyone to support the same codec. We don't get that by having a SHOULD-level requirement for Ogg. And we should implement OOXML support too right, just to make Microsoft happy? I don't think that's the right way to do things. As someone who's trained as a civil engineer, we were taught there was a right way and wrong way to do things. The most correct way is to follow the spec. But this has the premise that the spec is not screwed up. If you give us a screwed up spec, we're doomed. I think you may have misread what I wrote -- there's no plan to only make Microsoft happy. We have to find a solution that works for _everyone_, not just the open source community, or just Microsoft, or just the small companies, or just the big companies. This whole issue about submarine patents is bullshit. As I noted in an earlier e-mail, it doesn't really matter what the reason is for a vendor not wanting to support a particular codec; just the fact that they won't implement it is enough to prevent interoperability. Now, if we are to find an actual solution, then we have to find the reasons for the disagreements, and there it behooves us to assume people are working in good faith, since otherwise it'll be very difficult to actually figure out how to resolve the issues raised. The reason is this: If such a patent exists, Apple/Nokia/Microsoft/et all would have found it, and waved it in your face. After all, they've had months to go look for it. Actually, for legal reasons that I don't truly understand but which I am assured are true, big companies cannot safely perform patent searches. It (ironically) increases their patent liability. (I'm not a lawyer but if I recall correctly, knowingly infringing a patent results in triple penalities.) So big companies in fact avoid doing patent searches, and would have no idea what patents exist. Exactly. Which browsers are acid2 compliant again? Why was that? Apple's browser was the first to get Acid2 compliance (at least in pre-release builds). I don't understand the relevance. (Disclaimer: I wrote the Acid2 test.) Theora *is* the baseline for free and open video, full stop. Everything else reasonable is encumbered (at least to my knowledge). Assuming I'm right, discussion over. For anyone to claim this is not so, they will have to pull out patents to show why this is not so. Otherwise, they should shut up about it. That, sadly, is not how standards development works. You can never please everyone. Do the drug companies like FDA regulations? Hell no. Do we need stringent standards from FDA? Hell yes. Unfortunately for us, Web standards do not have the strength of law. Would it be so -- it would make our life much easier. Browser vendors can (and do) ignore Web standards they disagree with. Web standards _only_ have power so long as the vendors agree with them. Just look at XHTML2 for an example of this. XHTML2 ignoring the feedback of browser vendors is why we are doing HTML5 in the first place -- it would be silly of us to then just ignore the feedback of browser vendors! :-) Exactly. Tell Apple to show us the patents they're worried about. They've had time to go look up those damned patents. That's not how it works. I assure you that the change was made in good faith; I (sadly) received no money for the change. I really wish I had. Your role here is extremely critical. Surely there's someone that you'd trust, that can do the appropriate research for you, so that you can see if Jeff et all are speaking the truth, or if Apple/Nokia is speaking the truth (patent, legal, etc)? There is no way we can ever guarantee that there are no covering patents. Whether a patent covers a technology or not really has more to do with what the courts say than with what the patents say. If Apple say they don't want to implement Ogg, then we have to find another solution. (Similarly -- Opera, Mozilla, et al, don't want to implement H.264. So we have to find a solution other than H.264.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Editorial: 3.10.18. The |sup| and |sub| elements
On Wed, 1 Nov 2006, Christoph P�per wrote: The second to last example should probably better read: varE/var = varm/var � varcvarsup2/sup or maybe, as the speed of light is a constant, varE/var = varm/var � csup2/sup. If you are suggesting adding the multiplication sign, I disagree; the equation is always just written E=mc^2 in my experience. On Sat, 4 Nov 2006, Matthew Paul Thomas wrote: Is that equation ever legitimately rendered (in physics textbooks etc) with the m in a different style from the c? If not, perhaps the definition of var needs to be expanded to include physical constants. On Mon, 6 Nov 2006, David Walbert wrote: No, constants and variables are presented identically in equations. The student simply is expected to know whether they are constants or not. This requires some context, but the equation makes sense only with context anyway. If I understand the draft standards correctly the var would be defined by a prior dfn element, and that is where one would note (if one believed it necessary) that the speed of light was constant. If that equation is considered only algebraically, then E, m, and c are treated identically anyway -- there is no difference in how you handle them mathematically. Is var really not meant to include constants represented algebraically? That would take semantic markup to a level that seems to me frankly silly. I agree, as does the spec. Constants in physics are variables in mathematics, and the spec explicitly refers to variables in the mathematical sense. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages regarding Ogg in HTML5
On Dec 12, 2007 11:38 AM, Dave Singer [EMAIL PROTECTED] wrote: Possible action: The members of the WG are engineers, not IPR experts. There is general consensus that a solution is desirable, but also that engineers are not well placed to find it: a) they are not experts in the IPR and licensing field; b) many of them are discouraged by their employers from reading patents or discussing IPR. It's clear that the December workshop cannot be silent on this subject. There must be recognition of the issue and evidence of at least efforts to solve it, and preferably signs of progress. It is probable that this is best handled in parallel with the technical work, and headed by someone 'technically neutral' and qualified, such as W3C technical and legal staff. A good start would be to: a) examine the declaration, licensing, and patent expiry situation for various codecs; b) contact the licensing authorities for various codecs to determine their level of interest and flexibility, and possibly invite them to the December workshop. c) analyze the open-source codecs for their risk level, and possibly seek statements from patent owners if that is deemed prudent; What was the consensus on the what to do question? I would be quite interested to get c) undertaken and see how real the submarine patent threats are. Is that a real possibility for the W3C to do (I mean: financially speaking)? Also, if there is any potential that large patent owners could make statements about the applicability of their patents to these open specifications, the let's try it! Regards, Silvia.
Re: [whatwg] Removal of Ogg is *preposterous*
On Tue, 11 Dec 2007, L. David Baron wrote: In this case, most implementors following the SHOULD and implementing Theora might help companies whose concern is submarine patents become more comfortable about shipping Theora, especially if some of the implementors are companies similar in size or wealth to those non-implementors. As it stands, all the vendors who would implement Theora due to the SHOULD in the spec already are implementing Theora. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
