Re: [whatwg] More YouTube response
On 5 July 2010 07:51, Mikko Rantalainen mikko.rantalai...@peda.net wrote: So, you're arguing that DRM is not required, right? I'm arguing that it can't possibly make sense. And that standardising a DRM is not something anyone sensible should touch. Especially, the content distributors should immediately stop pretending that DRM allows for any kind of protection. It's mathematically impossible. It's like trying to send an encrypted message to Bob with a requirement that Bob cannot have access to the message. That problem cannot be solved. For that problem, a decision needs to be made: (1) Bob is allowed to get access to the message, or (2) Bob is not allowed to get access to the message (never send it!) Notice how this is similar to the DRM case above? Introducing a DRM system is about *trying to not do the decision* if you really *want to distribute the content or not*. Such system should not ever be standardized because it really cannot ever work, by definition. Yes, precisely. Law can contain absurdities - in the BBC case above, streaming and downloading are legally different things, even though technically they're identical - but putting such absurdities into a technical spec is nonsensical. - d.
Re: [whatwg] More YouTube response
On 4 July 2010 13:57, bjartur svartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. It's all very complicated when real money is at stake. (c.f. The Innovator's Dilemma.) That said: DRM is a provably broken concept. Anyone who demands it be incorporated into a standard is fundamentally, deeply wrong and can work around it with some sort of proprietary plugin, because that way they won't be requiring anyone else to pretend mathematics doesn't work. - d.
Re: [whatwg] forwarded: Google opens VP8 video codec
On 20 May 2010 00:38, David Gerard dger...@gmail.com wrote: x264 don't think much of VP8, they think it's just not ready: http://x264dev.multimedia.cx/?p=377 OTOH, that may not end up mattering. Greg Maxwell thinks it's only about as much of a car crash as VP3 was when it was released: http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html You should have seen what VP3 was like when it was handed over to Xiph.Org. The software was horribly buggy, slow, and the quality was fairly poor (at least compared to the current status). What it needs, of course, is a plugin for *current* browsers, more than the Chrome/Chromium dev channel. In any case - interesting times :-D - d.
Re: [whatwg] forwarded: Google opens VP8 video codec
2010/5/20 Peter Beverloo pe...@lvp-media.com: Microsoft has announced playback support for VP8 in Internet Explorer 9[1] under the condition that one has to install a VP8 codec manually, albeit via inclusion in another program: In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows. I think that's fairly significant. I don't. They're trying to make if you install it yourself, it'll work look like they're actually doing anything at all. But they're not, because the same applies already to Vorbis and Theora. If anything, they're just offering not to deliberately stop it from working. - d.
Re: [whatwg] forwarded: Google opens VP8 video codec
On 20 May 2010 11:03, Philip Jägenstedt phil...@opera.com wrote: On Thu, 20 May 2010 17:55:42 +0800, David Gerard dger...@gmail.com wrote: I don't. They're trying to make if you install it yourself, it'll work look like they're actually doing anything at all. But they're not, because the same applies already to Vorbis and Theora. If anything, they're just offering not to deliberately stop it from working. That is unfair. While I don't know precisely what the IE team is doing, hooking up things like canPlayType to give the correct reply depending on what is installed doesn't happen automatically. hmm, OK. I suppose they have to actually check it won't break anything. - d.
Re: [whatwg] forwarded: Google opens VP8 video codec
On 20 May 2010 00:34, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: James Salsman jsals...@talknicer.com schrieb am Wed, 19 May 2010 14:58:38 -0700: Container will be .webm, a modified version of Matroshka. Audio is Ogg Vorbis. You mean Vorbis. /pedantic ;) *cough* x264 don't think much of VP8, they think it's just not ready: http://x264dev.multimedia.cx/?p=377 OTOH, that may not end up mattering. - d.
Re: [whatwg] Video Tag Proposal
On 31 March 2010 02:07, Richard Watts r...@kynesim.co.uk wrote: Given what I've seen of the utter incomprehension the computing strategy people in general have of video, I suspect the actual reason for resistance is some form of pure political idiocy centering on the mobile companies lobbying to restrict video to things they already (think they have) silicon to accelerate. Nokia neglected to mention, at the time of their strident objection to Theora, that they get money from the H.264 patent pool. - d.
Re: [whatwg] Video Tag Proposal
My statement was completely wrong. Nokia isn't in the H.264 pool. Here's the full list (PDF linked from this page): http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx My sincere apologies to Nokia for this claim. - d. On 31 March 2010 08:48, Aaron Franco aa...@ngrinder.com wrote: David, Could you provide some links to substantiate that comment? I'd love to read about it. Nokia neglected to mention, at the time of their strident objection to Theora, that they get money from the H.264 patent pool.
Re: [whatwg] Video Tag Proposal
On 29 March 2010 00:03, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Mon, Mar 29, 2010 at 7:14 AM, David Gerard dger...@gmail.com wrote: The catch with Vorbis is that if you support it, whoever owns the MP3 patents charges you a lot more. (That's why I have an MP3 player that does Ogg Vorbis but does not mention the fact in the packaging, documentation or advertising in any manner whatsoever.) That would be crazy, cause no MP3 patents apply to Vorbis. You are able to use Vorbis without an MP3 license and the MPEG-LA should not be able to charge you more just because your want to support both codecs in your product. I believe that would not be legal. Do you have a concrete example, like a quote or something, that confirms this? It's from speaking to people at companies who've been bitten by this. (It works something like you will be ineligible for this substantial discount if you implement Vorbis.) No quotable citation, sorry. - d.
Re: [whatwg] Video Tag Proposal
On 29 March 2010 09:41, Kit Grose k...@iqmultimedia.com.au wrote: Apple is at heart a hardware company. My understanding of their objections to OGG have been also largely due to a lack of hardware decoder support in their iPods/iPhones. No, they claimed submarine patents as their actual objection to Theora. (I'm not aware of them making an express claim of this sort regarding Vorbis.) - d.
Re: [whatwg] Video Tag Proposal
2010/3/28 Remco remc...@gmail.com: This is what I don't understand either. It's not like H.264 won't be successful if another baseline format is specified in the recommendation. So, all this PR about submarine patents to scare people away from unencumbered formats is not necessary. Recommending an unencumbered format like MPEG 1 or H.263 or Dirac or Theora (the last one having the best quality of the bunch) will help tremendously with the standardization of the Internet, and if Apple wants to use a different format for their higher-quality videos, that's fine too. One editor works for Apple, the other works for Google. - d.
Re: [whatwg] Video Tag Proposal
On 28 March 2010 21:11, Kelly Clowers kelly.clow...@gmail.com wrote: For Theora. They haven't really said much about Vorbis AFAIK. And I think an audio codec is less likely to have patent issues than a video codec (especially since Vorbis has a lot of high profile use that should have drawn out any patent trolls) , and that is what Apple supposedly is worried about. The catch with Vorbis is that if you support it, whoever owns the MP3 patents charges you a lot more. (That's why I have an MP3 player that does Ogg Vorbis but does not mention the fact in the packaging, documentation or advertising in any manner whatsoever.) - d.
Re: [whatwg] Suddenly, ~40% of IE users get HTML5 Theora with no effort
On 7 February 2010 02:12, Kornel Lesinski kor...@geekhood.net wrote: There's also Cortado Theora player which can work for those who don't have Silverlight, but have Java. I've tested it - it's good enough for small videos (too slow for HD unfortunately) and can be used to implement basic video interface. Yeah, Wikimedia uses it for people without HTML5 Theora. I've always found the Java startup time horrible and was very happy when Firefox 3.5 made this stuff Just Work. - d.
[whatwg] Suddenly, ~40% of IE users get HTML5 Theora with no effort
http://www.atoker.com/blog/2010/02/04/html5-theora-video-codec-for-silverlight/ http://arstechnica.com/open-source/news/2010/02/nuanti-brings-html5-and-ogg-theora-video-to-silverlight.ars The 40% is from the blog post at the top. - d.
[whatwg] fyi: Flash in JavaScript and SVG
Now, this is interesting. A bit of a dancing bear (i.e. not quite as good as Gnash) ... but he's achieved Flash on the iPhone to some degree! Code: http://github.com/tobeytailor/gordon/ Demos: http://paulirish.com/work/gordon/demos/ iPhone screenshot: http://twitpic.com/xxmi2 Browser support matrix: http://wiki.github.com/tobeytailor/gordon/browser-support-table Supported SWF tags: http://wiki.github.com/tobeytailor/gordon/swf-tag-support-table The author: http://www.xing.com/profile/Tobias_Schneider14 HTML5. Is there anything it can't do? - d.
[whatwg] Unbiased browser stats (semi-OT)
... or as unbiased as you're likely to get, anyway, from a top 10 website of very mainstream interest whose direct interest is serving the readers: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm The first shows HTML5-aspiring browsers (places 2 to 5 on the list) at just over 40%. The work here is having excellent real-world significance :-D - d.
Re: [whatwg] Unbiased browser stats (semi-OT)
2009/11/8 Aryeh Gregor simetrical+...@gmail.com: On Sun, Nov 8, 2009 at 10:54 AM, David Gerard dger...@gmail.com wrote: ... or as unbiased as you're likely to get, anyway, from a top 10 website of very mainstream interest whose direct interest is serving the readers: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm The first shows HTML5-aspiring browsers (places 2 to 5 on the list) at Microsoft has indicated that they intend to support HTML5 in Internet Explorer as well, so I don't know why it's not HTML5-aspiring. I heartily support their statements, but I'm afraid I'll count them when I see action. YMMV, absolutely. Also, Wikipedia *editors* are probably represented very disproportionately in those figures, and they would certainly tend to use IE a lot less than the general population. Actually, no - readers have *way* outstripped editors since about 2006. It's not even the tech-savvy or web-savvy audience - Wikipedia is standard fare for people who can't work computers to look stuff up on. Wikipedia is stupidly mainstream and it's sometimes hard for those of us on the inside (you and me) to realise just how mainstream. But when I see a poster in Kings Cross train station advertising some pop culture museum exhibition as The Wikipedia of ... (whatever it was), it reminds me ... So I feel quite confident in stating that this is indicative of the actual Internet user base. - d.
Re: [whatwg] Comments on the definition of a valid e-mail address
2009/8/23 Aryeh Gregor simetrical+...@gmail.com: Or just don't ban anything at all, like with type=tel. type=email differs from most of the other types with validity constraints (like month, number, etc.) in that the difference between valid and invalid values is a purely pragmatic question (what will actually work?) that the user can often answer better than the application. It doesn't seem like a good idea for the standard to tell users that the e-mail addresses they've actually been using are invalid. +1 The quoted portion above strikes to the heart of the matter. I suppose the spec wants to obviate defective email validation JavaScript, but any restriction will (a) break stuff the user thinks should work (b) not stop bad web coders for a second. - d.
Re: [whatwg] Codecs for audio and video
2009/8/11 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net: Am Dienstag, den 11.08.2009, 00:44 +0100 schrieb Sam Kuper: In recent news, Google may be about to open source On2 codecs, perhaps creating a route out of the HTML 5 video codec deadlock: http://www.theregister.co.uk/2009/08/06/google_vp6_open_source/ At this point, this seems to be pure speculation. Maybe Google representatives can chime in on this issue ? I think it would be entirely reasonable to let Google get on with what they're doing on their schedule and count our chickens precisely when they hatch ;-) But with the results the Xiph/Mozilla/Wikimedia team have managed to get with the Thusnelda encoder for Theora - comparable results to H.264 - a released open unencumbered codec with a big company defending its freedom could get very good indeed in reasonable order. - d.
Re: [whatwg] Vorbis in audio
2009/7/17 timeless timel...@gmail.com: I believe, but can not speak for Nokia, that Nokia would not implement it. As to the why, it's something beyond my abilities to understand, and it's certainly beyond my paygrade to explain. But not entirely unlinked to Nokia being a beneficiary of the AAC patent pool, as I understand it. (I was surprised this wasn't mentioned by them when they produced that paper against Ogg Vorbis. Probably a completely unintentional oversight.) If it's beyond your paygrade, can you find someone whose paygrade it is? - d.
Re: [whatwg] Make Vorbis a baseline codec for audio
2009/7/16 Keryx Web webmas...@keryx.se: Of course Apple and microsoft, both being hellbent upon using proprietary technologies and taking every single opportunity they have to leverage any monopoly they have attained[1] will object to Vorbis. Now, now. Let's assume good faith. I will assume Apple have no objections to Vorbis as a baseline codec for audio, unless and until someone speaking for Apple per se expressly says they do. - d.
Re: [whatwg] Make Vorbis a baseline codec for audio
2009/7/16 Adam Shannon ashannon1...@gmail.com: It has been tried but Apple will not implement it due to hardware limitations. Hardware limitations or patent limitations? Either seems ill-matched to evidence-based reasoning. What was Apple's issue with Vorbis audio? I'd like to hear from Apple on this. (Someone who is actually speaking for Apple, not someone who appears to be speaking for Apple then claims oh I was just speaking as myself when called on something unacceptable.) - d.
Re: [whatwg] Make Vorbis a baseline codec for audio
2009/7/16 Remco remc...@gmail.com: Cowon/iAudio, iRiver, LG, Samsung, SanDisk, Creative, Google. Those are a few of the companies that support Vorbis: http://wiki.xiph.org/PortablePlayers Also everything using the Actions S1 MP3 chipset - almost *all* Chinese MP3/MP4 players. Basically, just not iPod. (Even Microsoft use Vorbis in some of their games.) - d.
Re: [whatwg] HTML 5 video tag questions
2009/7/13 Jeff Walden jwalden+wha...@mit.edu: On 12.7.09 23:20, Ian Hickson wrote: If people really want to push Apple into supporting Theora, the best way to do it would be to just keep using it as if it was the common codec, and _not_ provide another fallback forvideo-supporting UAs -- then things would work fine it non-video- supporting UAs like IE (through fallback flash support insidevideo), and would work fine in Theora-supporting UAs, but Safari would be left in the cold. I'm fine doing this for myself: partly because it's pressure on Apple; perhaps mostly because I choose to make embedding videos that I can watch in-browser easy for myself, and because I don't particularly care if some portions of my audience are unable to see such videos and also choose not to download a browser that will display them (fallback content provides a download link -- I haven't made the effort to handle Safari4-sans-XiphQT yet, see supra). That said, my position will be uncommon, and I'm not particularly interested in making use of video right now harder for those who don't share it -- even if it comes at the expense of added pressure on Apple. In Wikimedia's case, we do care about the user experience, *but* will only be using Theora for the foreseeable future - H.264 is not an option. So browsers with Theora in video should Just Work, browsers without video will get the Java player or an in-browser plugin (and a note suggesting a browser that does Theora in video) and Safari is a nuisance because it's the exception and it *might* work but it *might* not and we have to reliably detect whether it does. (Presumably Apple would be happier with us suggesting XiphQT rather than suggesting Firefox!) iPhone Safari users (does iPhone Safari support video yet?) are, unfortunately, out in the cold until someone writes a Wikimedia client app that does Theora for them. That won't be us unless a volunteer steps up. Other phone users are likely out in the cold too (I don't know of any phones that support arbitrary Java applets in the browser). - d.
Re: [whatwg] Serving up Theora video in the real world
2009/7/13 Robert O'Callahan rob...@ocallahan.org: On Mon, Jul 13, 2009 at 10:00 AM, Robert O'Callahan rob...@ocallahan.org wrote: It's not hard to implement this right, these issues reflect sloppy development more than a fundamental problem IMHO. That sounded mean, I apologize. What I want to say is that sometimes, a pattern of bugs indicates that a feature is very hard to implement correctly. This is not one of those times. Should clarified wording be written up for the spec? - d.
[whatwg] Serving up Theora video in the real world
(this is not quite about the standard itself, but it is about how to use shiny new bits of it in real world practice) Wikimedia is preparing to use video (and quite likely HTML5 all through) for serving up Ogg Theora video in MediaWiki. Desktop is easy: * In the one released browser that supports video and Theora, Firefox 3.5, this will Just Work. * In Safari with XiphQT, we can *probably* detect Theora's MIME type as being supported and it will Just Work (more or less). * Everyone else gets the Cortado player (written in Java), with a link suggesting FF 3.5 for a better video experience. The question is what to do for platforms such as the iPhone, which doesn't even run Java. Is there any way to install an additional codec in the iPhone browser? Is it (even theoretically) possible to put a free app on the AppStore just to play Ogg Theora video for our users? (There are many AppStore apps that support Ogg Vorbis, don't know if any support Theora - so presumably AppStore stuff doesn't give Apple the feared submarine patent exposure.) Our goal is to have happy end users who don't have to think about this rubbish. - d.
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 David Gerard dger...@gmail.com: * Everyone else gets the Cortado player (written in Java), with a link suggesting FF 3.5 for a better video experience. I should note, by the way, that this isn't a great option - second and subsequent videos in Cortado are just fine, but the thirty seconds waiting for Java to start up the first time you play a video *really sucks*. - d.
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 Benjamin M. Schwartz bmsch...@fas.harvard.edu: It seems you're rightish. Google, as usual, is having lots of fun with their stable/beta/release distinctions. See if you can decipher http://googlechromereleases.blogspot.com/ . At any rate, video is not supported in Chrome Stable, which is currently 2.0.x. Yep. For these purposes we're only considering release stuff. Anyone got ideas on the iPhone problem? - d.
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 Benjamin M. Schwartz bmsch...@fas.harvard.edu: David Gerard wrote: * In the one released browser that supports video and Theora, Firefox 3.5, this will Just Work. Two! Firefox and Chrome. Really? I thought that was next Chrome, not this Chrome. What's ETA on the next Chrome? - d.
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 Ian Fette (イアンフェッティ) ife...@google.com: As Peter said, please don't just block Chrome flat out -- if you must, just block Chrome under version 3. Note that when we push 3 to stable, everyone will be automatically updated. As version 3 is easily detectable, presumably we'd just detect it. The Java interface takes 30 seconds to start, the first 10 of which your browser or computer appears to have hung. It's really horrible. Which is a pity, as Cortado is otherwise really cool. So avoiding having to drop back to that is really really good, and so giving the native Theora in video experience to Chrome 3 users is just the thing :-) So let's hope Safari with XiphQT remains detectable ... - d.
Re: [whatwg] Codecs for audio and video -- informative note?
2009/7/6 Jim Jewett jimjjew...@gmail.com: As of 2009, there is no single efficient codec which works on all modern browsers. Content producers are encouraged to supply the video in both Theora and H.264 formats, as per the following example A spec that makes an encumbered format a SHOULD is unlikely to be workable for those content providers, e.g. Wikimedia, who don't have the money, and won't under principle, to put up stuff in a format rendered radioactive by known enforced patents. Your wording presumes a paid Web all the way through. - d.
[whatwg] Chipset support is a good argument
[to list as well, oops] -- Forwarded message -- From: David Gerard dger...@gmail.com Date: 2009/7/6 Subject: Re: [whatwg] Chipset support is a good argument To: Ian Hickson i...@hixie.ch 2009/7/6 Ian Hickson i...@hixie.ch: Given the volume of support Theora has gotten without it being in the spec, I don't see why putting it in HTML5 would have any effect on author demand. The demand already exists, and the customer pressure on Apple will rise as more and more sites make use of Theora. I don't see that the spec saying must...Theora would have any effect. This doesn't address the power of a should. If anything, I think it would be a negative effect, since it would mean that at least one thing in the spec was there despite it being known that one vendor is actively refusing to implement it (as opposed to just not having gotten to it yet). And then there's IE, of course. But if you were considering them, most of HTML5 wouldn't exist. - d.
Re: [whatwg] Codecs for audio and video
2009/6/30 Robert O'Callahan rob...@ocallahan.org: If we are going to allow individual vendors to exert veto power, at least lets make them accountable. Let's require them to make public statements with justifications instead of passing secret notes to Hixie. +1 Particularly when (e.g. Google's YouTube claim) the reason for the claim is then firmly proven not to be factually based. - d.
Re: [whatwg] Codecs for audio and video
2009/7/1 Ian Fette (イアンフェッティ) ife...@google.com: all of Google to suddenly release all of its information that has legitimate business reasons for staying company-internal. We've made what statements we can make, and I don't honestly think it reasonable to expect more. I think it is reasonable to expect Google to address their statements of reasons being demonstrated false, however. They have notably failed to do so. Is Chris DiBona still reading? Oh sorry, I was completely wrong or you're wrong and here's why would go a long way to restore any trust in Google on this matter. - d.
[whatwg] Another Theora vs H.264 comparison
(please excuse the faint odour of dead horse around this subject) http://www-cs-faculty.stanford.edu/~nick/theora-soccer/ The test files are actually from xiph.org, which strikes me as less than ideal even if they're entirely fair. - d.
Re: [whatwg] H.264-in-video vs plugin APIs
2009/6/14 Chris DiBona cdib...@gmail.com: I'll pass this on, it's a good post. Have you considered other kinds of video tests as well? (something cell shaded, more movement/action, etc...) as it stands, it's useful, with more examples, it might be more convincing as an argument for Theora. An important thing will be for you to internally speak up against such vast misconceptions as you voiced in your original posting whenever they spring up. H.264 just isn't so vastly superior and Theora just isn't so vastly awful, and Google is the content king in this area. - d.
Re: [whatwg] H.264-in-video vs plugin APIs
2009/6/13 Mike Shaver mike.sha...@gmail.com: On Sat, Jun 13, 2009 at 10:08 AM, Chris DiBonacdib...@gmail.com wrote: No, but it is what I worry about. How agressive will mpeg.la be in their interpretation of the direction that theora is going? I don't think that is a reason to stop the current development direction (or the funding of it) but I thought that Dirac, with the BBC connection, might make a better opponent politically than Theora. I have reason to hope that Mozilla would be a good opponent politically as well; that was certainly one piece that we were glad to bring to the table. Not that I have anything against Dirac, and would love to see support for it as well, but I think it's farther from being web-practical due to bandwidth minimums than Theora is. I'd also point out that Wikimedia has vast publicity abilities in this direction. We're just very, very cautious in how and when we apply them, for obvious reasons (we love everybody and want to stay their friend, of course). And we're watching the progress of Theora and Dirac on a day-by-day basis, for obvious reasons. So if you need large charitable organisations to help you with making this the obvious publicity choice for a happy Internet with cute fluffy kitties, I can tell you we'll be right there! - d.
Re: [whatwg] on bibtex-in-html5
2009/6/3 Bruce D'Arcus bdar...@gmail.com: Newspaper articles are cited a LOT; they're all over the place on wikipedia. And this doesn't even get into patents, or hearing transcripts, or legal opinions, or films. We need to be able to represent all of these, and bibtex is of little help here. I was about to mention Wikipedia! The citation templates there would be an excellent set of examples of what a citation format would need to cover in practical use. See: http://en.wikipedia.org/wiki/Category:Citation_templates There's a lot there, but many aren't that heavily used. You can see how many uses there are of a template, or if there are any at all, by going to the template page and clicking on What links here in the sidebar. The ones whose name starts Template:Cite ... include the biggies. These constitute a bunch of special cases, but you'll be pleased to know that similar templates tend to get combined with time. I certainly wouldn't suggest a set of special cases in a spec for this. But these will be useful for ideas and examples of what sort of citations are in demand on the web. - d.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
2009/6/7 Daniel Berlin dan...@google.com: On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com wrote: I do appreciate your willingness not discuss these matters, though. Thanks. As I said, it's clear we won't convince everyone, I question the relevance to HTML5 of someone from a completely proprietary software company closely questioning a direct competitor on their conformance to the GPL. - d.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
2009/6/7 King InuYasha ngomp...@gmail.com: And where the heck would reluctant to learn come from? This isn't a programming language, it is a codec! All they have to do is change the selection of codecs on the output of their video. As for not knowing it, there is already some publicity on Ogg Theora videos from the Mozilla team. And Dailymotion has converted a portion of their library for the purpose of experimenting with it. Wikipedia/Wikimedia uses it already. The Internet Archive also uses it. There is no doubt that people already know it. Wikimedia is blatantly encouraging the use of Firefogg: http://firefogg.org/ It's an encoding extension for Firefox. Ideal for processing videos pre-upload. (No, I don't know why Wikimedia doesn't have its own on-site re-encoder for videos uploaded in encumbered formats. Presumably considered to have some vague legal risk before the Supreme Court uses in re Bilski to drive the software patents into the ocean, cross fingers.) - d.
Re: [whatwg] Codec mess with video and audio tags
2009/6/7 jjcogliati-wha...@yahoo.com: 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. Google and other companies have announced plans to ship Ogg Vorbis and Theora or are shipping Ogg Vorbis and Theora, so this may not be considered a problem in the future. Indeed. There are no *credible* claims of submarine patent problems with the Ogg codecs that would not apply precisely as much to *any other codec whatsoever*. In fact, there are less, because the Ogg codecs have in fact been thoroughly researched. This claimed objection to Ogg is purest odious FUD, and should be described as such at every mention of it. It is not credible, it is a blatant and knowing lie. - d.
Re: [whatwg] Codec mess with video and audio tags
2009/6/7 Geoffrey Sneddon foolist...@googlemail.com: How is it incredible? Who has looked at the submarine patents? They by definition are unpublished! Yes, certainly, published patents are well researched, but this is not the objection that anyone has made to it. It is not credible to claim that any other codec whatsoever does not have the same problems - and paying Thomson or the MPEG-LA does *not* protect one from submarine claims from others, as Microsoft found out to its cost with MP3 - nor is it credible to claim that Ogg formats have more such problems. - d.
[whatwg] Fwd: Codec mess with video and audio tags
2009/6/7 jjcogliati-wha...@yahoo.com: I have looked for evidence of that there has been any patent research on the Ogg codecs. I assume that Google, Redhat and others have at least done some research, but I have yet to find any public research information. I probably am just missing the pointers to this, so could you please tell me where I can find results of this research? I refer you back to this very list: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg08442.html http://theora.org/faq/#24 I'm sure that won't be enough for you. But beyond that, your homework is yours. - d.
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
2009/5/31 jjcogliati-wha...@yahoo.com: The next question is why not just wait until the complete MPEG-1 can be decoded? If there is still no decision on a suitable codec for HTML5 when MPEG-1 becomes royalty free and MPEG-1 decoding starts showing up in things like gstreamer's good set of plugins then the full MPEG-1 might be worth considering then. Despite the blatant FUD from Apple and Nokia on the topic, Ogg Theora looks like (a) going into the browsers (Firefox, Chrome) and the websites (Wikimedia, Dailymotion), leaving them to play catchup. At that point the standard could be updated to reflect actual practice. - d.
[whatwg] Suitable video codec
H.264 was advocated here for the video element as higher quality than competing codecs such as Theora could ever manage. The Thusnelda coder is outdoing H.,264 in current tests: http://web.mit.edu/xiphmont/Public/theora/demo7.html This is of course developmental work. I'm sure the advocates of H. 264 can also tune its encoders to keep up, and not make Theora the only reasonable candidate for the video element. - d.
[whatwg] Security attacks on local storage
http://research.zscaler.com/2009/02/practical-example-of-cssqli-using.html http://it.slashdot.org/article.pl?sid=09/02/19/2055210 - d.
Re: [whatwg] Fwd: [html5] Semantic elements and spec complexity
2009/2/11 Ian Hickson i...@hixie.ch: On Wed, 11 Feb 2009, David Gerard wrote: Think of tag-soupness as a feature, not a bug. Shudder in horror at what this implies. I don't think that's a particularly controversial position here. People in other mailing lists involved in the development of HTML5 might disagree. :-) It's definitely a feature, not a bug, in Wikitext - Wikipedia has many contributors who write great articles but basically can't work a computer otherwise. If it wasn't, Wikipedia would be written in immaculately nested XML ... and XML was expressly *not* designed for humans to write, but for machines to talk to each other. Whether it's a feature for HTML, well, I suspect the people who write parsers have a few choice words on the matter ;-) - d.
[whatwg] Fwd: [html5] Semantic elements and spec complexity
(to list as well) -- Forwarded message -- From: David Gerard dger...@gmail.com Date: 2009/2/11 Subject: Re: [whatwg] [html5] Semantic elements and spec complexity To: Ian Hickson i...@hixie.ch 2009/2/10 Ian Hickson i...@hixie.ch: On Thu, 11 Nov 2004, Matthew Thomas wrote: 1. Most authors Just Don't Care about semantic markup. They'll only use it if it's the easiest way of getting the visual effect or behavior they want in their own favorite browser, or if they can use it to game search engines. (That's why authors use ul and li, for example, but not address.) I don't know if the thrust of this argument is true, but I am pretty sure the parenthetical isn't. If authors don't use address I think it's because of a variety of reasons including its poor name, and its lack of particularly useful purpose. I think there is a wide range of authoring styles, ranging from the author who really hasn't any idea that there is such a thing as semantics, and just thinks visually, to the author who just wants to get stuff done but understands that there are elements for specific purposes like lists, to the author who has bought the semantics religion but doesn't really understand it, leading to all kinds of innovative (and wrong) uses of HTML's less well known elements. This debate has come up on the Wikipedia tech lists concerning markup. HTML was intended to be a markup language usable by humans. However, the humans it was written for just happened to be Ph.D nuclear physicists. Lesser humans have a propensity to write tag soup. However, in human-writing circumstances, this is a feature rather than a bug - if it weren't, wikitext would be perfectly-formed XML rather than tag soup. So the tricky one is to write a language definition that does something meaningful with tag soup. Because tag soup is what human languages are too, and they're learned in a similar fashion (try stuff and see if it works). Think of tag-soupness as a feature, not a bug. Shudder in horror at what this implies. - d.
Re: [whatwg] [html5] Semantic elements and spec complexity
2009/2/11 David Gerard dger...@gmail.com: So the tricky one is to write a language definition that does something meaningful with tag soup. Because tag soup is what human languages are too, and they're learned in a similar fashion (try stuff and see if it works). Oh - and the way MediaWiki (the engine Wikipedia uses) deals with this is: there *is* no language definition - it's a series of PHP regular expressions. The parser is the actual definition of wikitext. This is horrifying in both big and small detail, of course. Also, the language is provably impossible to put into EBNF form. Argh. - d.
[whatwg] video element now working in Firefox nightlies
The current version of Minefield (the pre-3.1 nightlies) has Ogg Vorbis and Ogg Theora support. You can try these out using Wikimedia Commons video: http://commons.wikimedia.org/wiki/Category:Video The current MediaWiki video code defaults to everything else first, but load the video then select More ... and you should see the option to try it out, report bugs, etc. Is the video tag doing Ogg Theora in Opera yet? I'm sure Apple and Nokia can join the party at their leisure. - d.
Re: [whatwg] video element now working in Firefox nightlies
2008/7/31 Maik Merten [EMAIL PROTECTED]: David Gerard schrieb: I'm sure Apple and Nokia can join the party at their leisure. I assume the latest move by Mozilla (which I think is great, obviously) won't do anything to address the IP concerns of mentioned players. The IP concerns are blatant FUD and it's ridiculous to describe them in any other terms. - d.
Re: [whatwg] video element now working in Firefox nightlies
2008/7/31 Maik Merten [EMAIL PROTECTED]: David Gerard schrieb: The IP concerns are blatant FUD and it's ridiculous to describe them in any other terms. While I do agree that the IP concerns may actually be blown out of proportion (after all the current state of being in a limbo, leaving the field completely to proprietary technology like Flash video, may backfire more than taking the unspecified risk of IP troubles inherent to any technology) yelling at Apple and Nokia most likely won't resolve the situation by itself. Ignoring IE, Firefox 3.1 will have this Just Work. So, as I said, it'll be a process of them deciding whether there are business reasons to come along at their leisure. Perhaps it makes sense to discuss ways to make installation of 3rd party media components as easy as one simple click to ensure a reasonably user-friendly cross-platform media experience. A common baseline codec built into user agents would of course be a nicer solution, but from what I understand little progress has been made on that topic. So perhaps let's make progress on a nearly-just-as-good solution. That's an implementation detail on their end, really. - d.
Re: [whatwg] Is EBCDIC support needed for not breaking the Web?
[just to whatwg] 2008/6/1 Henri Sivonen [EMAIL PROTECTED]: Philip Taylor made a test case: http://philip.html5.org/demos/charset/ebcdic/charsets.html It shows that browsers that use general-purpose decoder libraries (IE and Safari) support some EBCDIC flavors but browsers that roll their own decoders (Firefox and Opera) don't. I just loaded that test page in Firefox 3 on Linux (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008052604 Minefield/3.0pre) and the accented characters appear to work in the EBCDIC encodings ... - d.
Re: [whatwg] Proposal for a link attribute to replace a href
Realistically, are people ever going to stop using a href= in the next twenty years? Even if it's marked deprecated? - d.
Re: [whatwg] Web Documents off the Web (was Web Archives)
2008/5/13 Ian Hickson [EMAIL PROTECTED]: MHTML with a gzip transfer encoding seems like it would do this pretty nicely already, no? Indeed, this would belong in another specification. Yeah, sounds like something for the HTTP layer - what the user-agent will accept. - d.
[whatwg] Fwd: Expanding datetime
to list as well -- Forwarded message -- From: David Gerard [EMAIL PROTECTED] Date: 2008/4/24 Subject: Re: [whatwg] Expanding datetime To: WeBMartians [EMAIL PROTECTED] 2008/4/24 WeBMartians [EMAIL PROTECTED]: Whether or not providing a means to specify dates before the Gregorian Reform or before the beginning of the first millennium will have a business effect is difficult to determine. One thing that can be said is that the applications which would be enabled certainly won't exist if the facilities are not present. Currently, the extreme datetime values (as opposed to the strings) can be specified in Javascript. Producing the corresponding datetime strings from such values should be mandatory. That argues in favor of proper round trip handling: the conversion of extreme datetime strings should be available too. What's ODF do? They've dealt with this problem, surely. - d.
Re: [whatwg] Question about the PICS label in HTML5
On 16/04/2008, Marco [EMAIL PROTECTED] wrote: I've been looking through the HTML5 working draft and I've been trying to find a reference for the use of the current PICS labels. I may have missed it, but does anyone, anywhere, actually use PICS? I don't think I've even heard the name uttered in a few years - I assumed it had died of neglect and lack of interest. - d.
Re: [whatwg] Some video questions
On 07/04/2008, Charles [EMAIL PROTECTED] wrote: And just to repeat the facts as I understand them: - video will universally support a base video/audio format (linear media format) defined by the final HTML 5 specification, assuming a suitable combination of container and bitstream formats can be found. - video will not universally support any other format. Is that correct? As I understand it. Perhaps if someone writes a codec for H.120 ... - d.
Re: [whatwg] Semantic markup for buzzwords
On 01/04/2008, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Tue, 01 Apr 2008 18:08:20 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: Just my 2 cents for what they are worth. Also - it is very possible that I don't understand, if so could you expand? Taking into account the very special date on which this discussion is happening should clarify matters. I thought that was the one advocating H.264. - d.
Re: [whatwg] Video
On 01/04/2008, Gervase Markham [EMAIL PROTECTED] wrote: Robert J Crisler wrote: From my perspective, and for what it's worth, I doubt that the ideals of the W3C as expressed in 3.12.7.1 http://3.12.7.1 would result in a situation that would be superior to simply letting the international standards body for audio and video codecs deal with these technological areas. Your plan would, at least, prevent the standard codec being supported on Free operating systems. Meeting 3.12.7.1 as it stands would not prevent this. Therefore, it would be a superior situation. The actual solution is a large amount of compelling content in Theora or similar. Wikimedia is working on this, though we're presently hampered by a severe lack of money for infrastructure and are unlikely to have enough in time for FF3/Webkit/HTML5. - d.
Re: [whatwg] Usemap and ismap for canvas tag
On 05/03/2008, Greg Houston [EMAIL PROTECTED] wrote: I really didn't mean to shift the emphasis to SVG at all. I don't think anyone is going to try running a Gaussian blur of a dynamically generated mouse-driven turbulence displacement of a bitmap [via] JavaScript on a canvas image. *cough* I think history demonstrates that people will try to do anything they possibly can if the results promise to be cool enough eventually. If something can be done at all with promising results on the highest-end available PC, it would be safe enough to assume it will be common a couple of years later. Fortunately, Hixie is highly aware of the history of the benighted X11 Image extension - which to implement properly would have required the equivalent of an embedded copy of ImageMagick :-) - d.
Re: [whatwg] several messages about the HTML syntax
On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. But how will we read the asides on xkcd.com ?! (i.e.: If people can do something, they will, and this needs to be allowed for. ASCII art in tooltips hits my wrong button, but it's out there. OTOH I've never seen a tooltip in a monospaced font. User-agents treating all whitespace as spaces and reformatting as nicely as they can would be fine to me. I'm sure others will come up with real-life use cases for ridiculously long tooltips.) - d.
Re: [whatwg] postMessage: event.source allows navigation of sender
On 07/02/2008, Hallvord R M Steen [EMAIL PROTECTED] wrote: That is of course a possibility. I don't have Firefox 3 handy so I'd appreciate somebody explaining how it is implemented there. By the way, I recommend Minefield (the Firefox 3 nightlies) to anyone. I now use it as my default browser on Windows. There are occasional bad builds, but mostly it's just better in every way than Firefox 2. Lots of nice incremental improvements to the interface, less memory-hogging, more responsive, better at handling 200 tabs open, and so on. The only minus point is that most of my favourite extensions haven't been updated yet. - d.
[whatwg] Fwd: [ORG-discuss] BBC video codec to become an international standard
-- Forwarded message -- From: Glyn Wintle [EMAIL PROTECTED] Date: 25 Jan 2008 01:15 Subject: [ORG-discuss] BBC video codec to become an international standard To: Open Rights Group open discussion list [EMAIL PROTECTED] First linked to by groklaw http://sonofid.blogspot.com/2008/01/on-road-to-dirac-standard-at-last.html Ok, so I know that people think that Dirac disappeared into a black hole some while ago but we're still hanging in there and getting it done. We're just coming up to some really major milestones and things are looking really exciting. First, Dirac (or part of it) is going to be an international standard. Yay! We made a cut-down version doing intra coding only and this has only just been submitted to the SMPTE. If it goes through it will become VC-2 (Windows Media 9 became VC-1 when they standardised it). After a lot of hard work fighting SMPTE's preferred Word format (yuk) it went in just before Christmas and is being voted on as a Committee Draft as I write this. At the same time we've been updating the full spec and that's been published today. Version 1.0 covers the professional VC-2 stuff, whilst version 2.0 covers the whole system. If VC-2 is well-received we'll propose an extension so that it covers the whole of Dirac. Then at last there'll be a royalty-free video compression standard ... Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ ORG-discuss mailing list [EMAIL PROTECTED] http://lists.openrightsgroup.org/mailman/listinfo/org-discuss
Re: [whatwg] How to use SVG in HTML5?
On 24/01/2008, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: I hereby grant you the right to use in-line SVG provided the only element used inside is solid filled path. (No gradients, transformations, mitres, text and such). I remember using VML in this spirit myself. Thanks for the redirection, the pictures are very nice! This is a good example of why people will want to use SVGs just like any other sort of image: * vector drawing is the right way to do lots of sorts of image * SVG is a standard and increasingly widely-used vector format * Inkscape's a reasonably usable and free vector drawing application that saves in SVG (of a sort) That it's arguably problematic won't stop people from wanting to do it, any more than tag soup being a parsing nightmare will stop people from doing the tagsoup-render-tagsoup-render-looks-ok method of HTML writing. And on a hostile Internet, user agents have to be able to cope well with arbitrary rubbish which may well be malicious, not just badly-formed; I don't see that safely parsing SVG is an intrinsically trickier problem than criminal spammers throwing every piece of toxic waste they can come up with at your user agent. [Inkscape is so prevalent for SVG drawing that Wikimedia has seriously considered using Inkscape in command-line mode as the default SVG renderer rather than rsvg, even if it is half the speed and uses a bucketload more memory. A user agent that handles SVG will likely need to be able to cope with almost anything Inkscape throws at it.] - d.
[whatwg] How to use SVG in HTML5?
Forgive me if this is a simple and obvious question. I note that all current browsers (except IE, of course) implement SVG rendering (to a better or worse degree). I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? - d.
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, James Graham [EMAIL PROTECTED] wrote: In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). img src=foo.svg is just what I was hoping for, thank you :-) Doesn't yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield (Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers it currently does work in? - d.
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, Anne van Kesteren [EMAIL PROTECTED] wrote: On Wed, 23 Jan 2008 15:55:27 +0100, David Gerard [EMAIL PROTECTED] wrote: img src=foo.svg is just what I was hoping for, thank you :-) Doesn't yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield (Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers it currently does work in? Should work in Opera 9.5 (beta though). If you use object data=foo.svg/object it probably works in more browsers. Works somewhat in SeaMonkey (gives default specified rendering size of image in a small object box with scroll bars) and Safari (gives default size in small box with no scroll bars, i.e. top left corner only) and best in Minefield (scales image to size of object box, scales properly with WIDTH= or HEIGHT=). (Minefield uses 100% CPU just displaying my test image, but also renders the SVG most accurately of any of them - this image was drawn in Omnigraffle but is known to misrender in Firefox, SeaMonkey, Safari, ImageMagick, Inkscape and rsvg - proprietary, or I'd link a copy. I expect I should create a test case and file a lot of bugs ...) Thank you all! - d.
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, David Gerard [EMAIL PROTECTED] wrote: Works somewhat in SeaMonkey (gives default specified rendering size of image in a small object box with scroll bars) and Safari (gives default size in small box with no scroll bars, i.e. top left corner only) and best in Minefield (scales image to size of object box, scales properly with WIDTH= or HEIGHT=). Oh, and Opera 9.50 beta build 9745 for Win32 renders it in a box with scroll bars, and does by far the worst rendering of the original SVG I've seen ... (Minefield uses 100% CPU just displaying my test image, but also renders the SVG most accurately of any of them - this image was drawn in Omnigraffle but is known to misrender in Firefox, SeaMonkey, Safari, ImageMagick, Inkscape and rsvg - proprietary, or I'd link a copy. I expect I should create a test case and file a lot of bugs ...) I shall definitely create a public test case, so as to help Firefox 3 and Opera 9.5 do a good job! - d.
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, Charles McCathieNevile [EMAIL PROTECTED] wrote: An image is not a replacement for text in the real world, only in Ian's current drafts. And where it is, SVG is ideal for having beautifully styled selectable interactive text that is lightweight and easy to create (or heavyweight and bloated if you use something like inkscape, but still easy to create and easy to automagically optimise to something lightweight). Which is why I disagree thoroughly with Chris' assertion here. FWIW, my use case is to be able to create images in SVG and just use them as ... images, just like I do PNGs or JPEGs. It was also somewhat inspired by setting up rsvg for MediaWiki on our work intranet and wanting to hit it repeatedly with a hammer ... but relying on client-side SVG rendering will have to wait until Firefox 3 renders it not only correctly, but without pegging the processor just displaying ;-) I think Chris is incorrect in his assertion because clients can be presumed to have increasing amounts of rendering power available just to make pretty pictures. Every browser (except IE) *has* SVG rendering. Firefox 3 will have *accurate* SVG rendering. SVG is the Right Thing for so many situations. It's all looking promising to me so far. - d.
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, timeless [EMAIL PROTECTED] wrote: Every browser (except IE) *has* SVG rendering. That's not true. MicroB as shipped w/ OS 2008 on the N810 (and in OS Sorry, you're right. I was thinking only of the desktop. Bad move. Firefox 3 will have *accurate* SVG rendering. who's promising this? Read up the thread. I noted that Minefield's rendering is notably better than FF2's. (I've been exploring the world of SVG in far too much depth lately. All SVG renderers suck, but Minefield's suck is on the CPU-pegging side, not the rendering side.) - d.
Re: [whatwg] Video codec requirements changed
On 07/01/2008, Dave Singer [EMAIL PROTECTED] wrote: At 19:29 +0100 7/01/08, Federico Bianco Prevot wrote: Has anyone considered Bink video as a viable option? http://www.radgametools.com/bnkmain.htm I get the impression that this is not an openly-specified codec, which I rather think is a problem. That is, there is neither a publicly available spec. nor publicly-available source, which means that it is controlled by one company. Am I misreading the situation? I have a suggestion: Nokia, Apple: you want H.264, you free H.264. Make it irrevocably perpetually royalty-free, it goes in. Do that with any other codec that's technically better than Ogg Theora, it goes in. You can't do that, we name Ogg Theora as a SHOULD. OK with you? Anyone see anything unacceptable in that approach? Find someone from Apple and Nokia who can actually say Yes or No to this, perhaps the fellow from Nokia who wrote that darling little paper claiming Ogg was too proprietary. You're from Apple, you'd know who can say yes or no to this. (I realise you've already stated Apple is okay with a SHOULD for Ogg, perhaps you can explain Apple's earlier objections without appearing to contradict that.) - d.
Re: [whatwg] Possible alternative to specifying a codec for the video tag
On 24/12/2007, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 23-12-2007, N o godzinie 13:08 +, David Gerard pisze: On 23/12/2007, Robert (Jamie) Munro [EMAIL PROTECTED] wrote: How could we do that? The codec is usually a relatively small download download compared to the video itself. If we could suggest a way for Arbitrary executable downloads didn't work out well with ActiveX, and Download codec to view this! is already a vector for malware. That would not be an arbitrary download; it would be a download of _the_ codec. The executable code must not be enclosed in the content envelope (unless the envelope is generated on the fly by the server depending on the user agent; I think it would be a cumbersome thing to do). Arbitrary active extensions can request services from the operating system; the code to be executed should not be allowed to. It could be allowed to request services from the browser only; if that is set up correctly, the decoder will be as safe as the browser is, even if it is a piece of broken malware. Thus we would need the browser to be a direct show* engine provider for the decoder and the decoder would be allowed to access its own memory only and call its own functions and the functions explicitly provided by the browser. Is this feasible? It still sounds to me a bit like a layer violation ... the content in question is a bit active. Mind you, HTML these days is generally riddled with (or only a delivery mechanism for, e.g. in interactive television) JavaScript. And codecs are a bit virtual-machine-like anyway (with playback engines needing sandboxing to protect against codecs that are unsecure against malicious files). And, last but not least: can we expect the opposing browser vendors to offer the direct show engine and allow the decoder to run without much user intervention? Because if not, this solution would be very weak. What do you think? It strikes me as more trouble than it would be simply to remember that in claiming Ogg was proprietary, Nokia told a lie big enough to crack and break the assumption of good faith; and if Apple could really live with SHOULD in the spec, put back the baseline recommendation of Ogg Theora and Ogg Vorbis. - d.
Re: [whatwg] Possible alternative to specifying a codec for the video tag
On 23/12/2007, Robert (Jamie) Munro [EMAIL PROTECTED] wrote: How could we do that? The codec is usually a relatively small download download compared to the video itself. If we could suggest a way for codecs to be provided alongside the videos by the content providers, this /may/ be a way forward. Hypothetically, you could do video by adding better binary file handling to Javascript, and painting on the canvas, but good performance is unlikely. Arbitrary executable downloads didn't work out well with ActiveX, and Download codec to view this! is already a vector for malware. However, now that Java is free, Java applets could provide a solution. There is already a free Ogg Vorbis/Theora java applet here: http://www.flumotion.net/cortado/ Java is available for all the major browsers and already installed on many small devices. Wikimedia sites use this now. It's not a great solution (click, wait a minute with a hung browser application while Java loads), but it's a kludge we consider slightly better than nothing. As soon as Firefox 3 is out I strongly suspect we'll be putting Ogg Theora in a VIDEO element, with JavaScript trickery to allow stick-in-the-mud browsers like Safari to tell the reader how much they suck. Nokia and Apple can then decide whether they want to support the content or not. - s.
Re: [whatwg] Reasons for moving Ogg to MUST status (was Re: HTML 5, OGG, competition, civil rights, and persons with disabilities)
On 13/12/2007, Andrew Sidwell [EMAIL PROTECTED] wrote: Manuel Amador (Rudd-O) wrote: 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. I very much doubt it. IE at least would have to support it before a majority of authors would use it seriously. IE can't really be a serious consideration here - if HTML standards had to wait on IE adopting them, this list might as well shut down now. - d.
[whatwg] Ogg content on the Web
FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. wikipedia.org is something like #8 in the world at present, so this is set to be a significant content repository actually used by people. A video tag which can be relied upon to support the format in at least Firefox would be enormously helpful to us and our readers. So far we have had zero patent trolls come calling. I wonder why that is. [note: There was a recent press release about Ogg support in HTML5 which we didn't get it together to be mentioned in. Any further on these, please cc me directly at [EMAIL PROTECTED] and I'll make sure it happens myself.] - d.
Re: [whatwg] Ogg content on the Web
On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 14:23, David Gerard wrote: FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. Why must video just one of many unencumbered formats? Er, what are the others? - d.
Re: [whatwg] Ogg content on the Web
On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 17:44, David Gerard wrote: On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 14:23, David Gerard wrote: FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. Why must video just one of many unencumbered formats? Er, what are the others? Technically speaking, Theora is actually unencumbered (it just has a RF license covering the patents from On2). Dirac is in a similar situation. Apart from those two, the others I can think of are those that are in excess of twenty years old (and therefore their patents have expired), such as H.260. Dirac is not finished, H.120 has no extant codecs. I may as well call motion PNM an unencumbered video format. In any case, the point remains: Theora is the only practical option for video on Wikimedia sites at present, so that's one top-10 source of video that will greatly be enabled for the end user by HTML5 having a video tag with Ogg Theora as the default (even as a SHOULD). Claims that there are no sources of content are simply factually incorrect. - d.
Re: [whatwg] Ogg content on the Web
On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 14:23, David Gerard wrote: So far we have had zero patent trolls come calling. I wonder why that is. Do you have enough money to pay a fine a similar size to what MS got last year? If you don't have enough money, they won't sue you. It isn't worth their time. Not to mention Patent Troll Sues Wikipedia would be second only to Patent Troll Eats Cute Fluffy Kittens for mediapathy. Mind you, the people who hate Wikipedia *really hate* Wikipedia, and I'm amazed none of them have even made noises in this direction, given the ridiculously broad and vague software and business method patents that exist in the US. That said, we do actually go to considerable effort to do the right thing because it's the right thing - we don't allow patent-encumbered formats because they would severely reduce the reusability of our content, and deliberately flouting assumed-valid US patents (as odious as software patents are) would be unseemly. - d.
Re: [whatwg] Ogg content on the Web
On 12/12/2007, Smylers [EMAIL PROTECTED] wrote: Not quite. That's one top-10 source of video that will greatly be enabled by browsers supporting Theora. Your claim (that it would benefit from the spec saying browsers SHOULD support Theora) is only true if there are browsers which would only support Theora because of the spec saying that. Technically this is true :-) But in practice, I can't tell you how happy we were when we heard Ogg Theora would be in HTML5 (even as a SHOULD). Video is important as educational material, and video support in the MediaWiki software has been a major pain in the backside. Current support is a kludgy pile of stuff that degrades somewhat gracefully through a sequence of free-software and not-quite-free-software (VLC plugin, QuickTime plugin, there's JavaScript, there's a bit of Java, there's Flash that sorta works in Gnash, etc - I'm not absolutely clear on the details and I'm sure someone will be along to correct me shortly, but they're pretty murky details ;-). A VIDEO tag that can be reasonably assumed to support Ogg Theora and Ogg Vorbis would make our lives and our readers' browsing significantly happier. Some browser creators have made it clear they woudln't support Theora, even with a SHOULD. Other browsers will Theora anyway, because they want to, regardless of whether the spec even mentions it -- and the more that Wikipedia uses it, the more that browsers are going to want to support it simply in order to be Wikipedia-compatible (regardless of whether the spec says browsers should be Wikipedia-compatible). Including, I suspect, Safari - which has a Wikipedia link in the default bookmark bar - and Nokia - what use is a phone that can't show you the video on Wikipedia that explains your point precisely when you're arguing over something in the pub? What sorta rubbishy phone is that? Tch! Shoulda got an iPhone! *cough* We're only one site that would significantly benefit from a VIDEO tag that can reasonably be assumed to do Ogg Theora, but we're a reasonably significant one I think. - d.
