Re: [whatwg] getImageData/putImageData comments
On Sat, Jun 13, 2009 at 6:39 AM, Ian Hickson i...@hixie.ch wrote: The long and short of this is that if we solve this problem today, the solution will be abused as much as the current API, and we'll have to introduce yet another solution when high-res backing stores are common. So instead I'm hoping that (a) authors won't screw this up, and (b) high-res backing stores will be implemented sooner rather than later. If we fail with (a), which is more likely if (b) is delayed, then we'll just introduce a higher-res API later, and designate this one a lost cause. Whether high-resolution backing stores are implemented or not is irrelevant as long as most authors are testing their scripts on systems configured with a 1:1 ratio of CSS pixels to device pixels. So in practice you're also relying on (c) rapid deployment of high-dpi screens to canvas-using Web developers. That's why I think you hope in vain. Altering the current API so that it always uses one image-data pixel per CSS pixel would not make it useless. Everything people are currently using it for will continue to work just fine and the visual results will be just as good as what people are currently seeing. It's just that we'll need a new API in the future to take maximum advantage of hardware. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] getImageData/putImageData comments
On Sat, 13 Jun 2009, Robert O'Callahan wrote: On Sat, Jun 13, 2009 at 6:39 AM, Ian Hickson i...@hixie.ch wrote: The long and short of this is that if we solve this problem today, the solution will be abused as much as the current API, and we'll have to introduce yet another solution when high-res backing stores are common. So instead I'm hoping that (a) authors won't screw this up, and (b) high-res backing stores will be implemented sooner rather than later. If we fail with (a), which is more likely if (b) is delayed, then we'll just introduce a higher-res API later, and designate this one a lost cause. Whether high-resolution backing stores are implemented or not is irrelevant as long as most authors are testing their scripts on systems configured with a 1:1 ratio of CSS pixels to device pixels. So in practice you're also relying on (c) rapid deployment of high-dpi screens to canvas-using Web developers. That's why I think you hope in vain. Altering the current API so that it always uses one image-data pixel per CSS pixel would not make it useless. Everything people are currently using it for will continue to work just fine and the visual results will be just as good as what people are currently seeing. It's just that we'll need a new API in the future to take maximum advantage of hardware. Right, but that would be less optimal than if we could just re-use today's API, hence the hope. There's no practical difference as far as I can tell between hoping that we can reuse the API, and then finding we can't, and introducing a second API for high-res screens; and just giving up now and saying that it's a low-res API, and then adding a second API later when we have high-res screens. The effect is more or less the same. Given that, I think it's worth at least trying to see if we get away with it and can in fact use this API in high-res situations later. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getImageData/putImageData comments
On Sat, Jun 13, 2009 at 6:57 PM, Ian Hickson i...@hixie.ch wrote: There's no practical difference as far as I can tell between hoping that we can reuse the API, and then finding we can't, and introducing a second API for high-res screens; and just giving up now and saying that it's a low-res API, and then adding a second API later when we have high-res screens. The effect is more or less the same. Given that, I think it's worth at least trying to see if we get away with it and can in fact use this API in high-res situations later. The difference to me as an implementor is that as the spec stands, I have to choose between 1) Implement high-resolution canvas backing store and implementing image data per spec, breaking most of the current scripts that are using image-data for all the users who can actually take advantage of that high-resolution backing store 2) Implement high-resolution canvas backing store and quietly violate the spec so that the current generation of image-data-using scripts continue to work 3) Don't implement high-resolution backing store, which at least means I don't have to choose between violating the spec and breaking content Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Vulgar fractions
Actually aligning vulgar fractions is not even a CSS thing, it is an OpenType thing. Chris
Re: [whatwg] H.264-in-video vs plugin APIs
Comparing Daily Motion to Youtube is disingenuous. If yt were to switch to theora and maintain even a semblance of the current youtube quality it would take up most available bandwidth across the internet. The most recent public number was just over 1 billion video streams a day, and I've seen what we've had to do to make that happen, and it is a staggering amount of bandwidth. Dailymotion is a fine site, but they're just not Youtube. Considering this 'argument' came out of the larger issue that we're actually shipping with Theora (also on android, too), and as we showed at Google I/O, are sampling it on some pages at Youtube, this thread is pretty surreal to me. I will say that the best thing that can happen to Theora recently was firefox's support of it, though, but even better would be substantive codec improvements or some great advance in Dirac encoding efficiency. . Chris On Fri, Jun 12, 2009 at 10:02 AM, Mike Shavermike.sha...@gmail.com wrote: Apologies for the poor threading, I wasn't subscribed when the message here was sent. In http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020237.html Chris DiBona wrote: The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. I think that reprehensible is excessive, and not helpful, but I think you're very much missing the point here. It's true that plugin support is necessary for competitiveness on the desktop web, because there is a lot of content out there that requires those plugins, for better or for worse. And because each plugin has different API (and often markup requirements), in addition to codec differences, migration cost is a pain. This is definitely a problem for people on iPhones and the Pre and various mobile Linux devices and platforms, and I gather for Android users as well. That's not the case for video, as far as I can tell. There is still proportionately little content on the web that uses it, and as far as H.264-in-video is concerned, basically *all* the content on the web is Google's! What legacy-content-compatibility requirement there is comes from services in the same company! Anyone else moving to video now from their legacy setups will have much more to worry about with respect to API changes than a simple transcoding, and the experiences of DailyMotion and others indicate that the transcoding works quite well. (We want it to work better, of course, which is why we're investing in tools and library development.) I do not like the situation on the web today, where to use all the content you need to have a license to Flash, and I'm saddened that Google is choosing to use its considerable leverage -- especially in the web video space, where they could be a king-maker if ever there was one -- to create a _future_ in which one needs an H.264 patent license to view much of the video content on the web. Firefox won't likely have native H.264 support, since we simply can't operate under those patent restrictions, so by your analogy I suppose we won't last long in the market -- I very much hope you're wrong about that aspect as well. And I hope that those who would follow Google's footsteps in joining the web browser market don't have to get such a license as well; that would be an unfortunate blow to the competitiveness of the current environment, to which Google has contributed and from which it has benefited. Mike -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 8:00 AM, Chris DiBonacdib...@gmail.com wrote: Comparing Daily Motion to Youtube is disingenuous. Much less so than comparing promotion of H.264-in-video via Google's sites and client to support for legacy proprietary content via plugin APIs, I would say. But also, I didn't compare DailyMotion to YouTube! I used it as an example of converting content at scale, to speak to the relative impact of a codec change vs. API changes in terms of effort. If yt were to switch to theora and maintain even a semblance of the current youtube quality it would take up most available bandwidth across the internet. The most recent public number was just over 1 billion video streams a day, and I've seen what we've had to do to make that happen, and it is a staggering amount of bandwidth. Dailymotion is a fine site, but they're just not Youtube. I don't think the bandwidth delta is very much with recent (and format-compatible) improvements to the Theora encoders, if it's even in H.264's favour any more, but I'd rather get data than share suppositions. Can you send me a link to raw video for the clip at http://www.youtube.com/demo/google_main.mp4?2 so I can get it converted with the state of the art encoder and we can compare numbers? Considering this 'argument' came out of the larger issue that we're actually shipping with Theora (also on android, too), and as we showed at Google I/O, are sampling it on some pages at Youtube, That's great news -- I wasn't able to be at Google I/O, and I can't find any mention of Youtube providing Theora for consumption anywhere. Can you clue me in with a link? (It does seem that Youtube accepts Theora at upload, but it seems like it gets transcoded to Flash or whatever at that point, so it's converting from unencumbered to encumbered! http://www.youtube.com/watch?v=roE4bmOSURk is one example that I'm pretty sure was uploaded in Theora format.) I will say that the best thing that can happen to Theora recently was firefox's support of it, though, but even better would be substantive codec improvements That's indeed a big part of what we've been funding, and the results have been great already. I'd like to demonstate them to you, because I suspect that you'd be a better-armed advocate within Google for unencumbered video if you could see what it's really capable of now. (Separate from the Wikimedia grant we also just started funding work to port Theora to some DSPs, so that we will be able to do off-CPU decode/yuv2rbg/scale on some devices.) Mike
Re: [whatwg] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 9:37 AM, Chris DiBonacdib...@gmail.com wrote: I tried funding dirac a while back, to some good end, and we provide students, but here's the challenge: Can theora move forward without infringing on the other video compression patents? We certainly believe so, but I'm certainly not qualified to evaluate the different techniques. Would Theora inherently be any less able to than any other codec system, though? I hope you're not saying that it has to be H.264 forever, given the spectre of the streaming license changes at the end of 2010. If Youtube is held back by client compatibility, they should be glad that we're working hard to move ~25% of the web to having Theora support in the near future! Google could help that cause a lot by putting (well-encoded, ahem) Theora up there, even if it's just in the experimental /html5 area. It wouldn't hurt to use the reference libraries rather than ffmpeg for the client either, since we've found significant differences in quality of experience there. Mike
Re: [whatwg] H.264-in-video vs plugin APIs
We certainly believe so, but I'm certainly not qualified to evaluate the different techniques. Would Theora inherently be any less able to than any other codec system, though? I hope you're not saying that it has to be H.264 forever, given the spectre of the streaming license changes at the end of 2010. 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. If Youtube is held back by client compatibility, they should be glad that we're working hard to move ~25% of the web to having Theora support in the near future! Google could help that cause a lot by putting (well-encoded, ahem) Theora up there, even if it's just in the experimental /html5 area. It wouldn't hurt to use the reference libraries rather than ffmpeg for the client either, since we've found significant differences in quality of experience there. It is client compatibility first, and global/edge bandwidth restricted as well. I'd prefer to ship with the reference libraries and have told the team as much. Mike -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] H.264-in-video vs plugin APIs
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. It is client compatibility first, and global/edge bandwidth restricted as well. I'd prefer to ship with the reference libraries and have told the team as much. I would certainly like to understand the reasons for Chrome shipping with H.264 support, but this thread has confused me a little. As I understand it, you have to have it because, per your analogy with plugins, there is a lot of legacy content with H.264 that will be made available via the video tag so you're forced to provide support or risk market irrelevance... ...but that legacy content is virtually *all* from Google properties... ...but Google can't provide Theora video because of... a) client compatibility limits (circular with the above, though Firefox will provide ~25% of the web with Theora support, vastly larger than I think even the most optimistic projections of Chrome+Safari with H.264 when Chrome ships video, so maybe we can out-egg that chicken) b) bandwidth concerns (but even if Theora took _double_ the bandwidth, and _all_ the content was converted overnight, that's still only a 25% increase in bandwidth, plus a few percent for Chrome when it ships video as well) So if we can remove the bandwidth spectre -- and I really believe we can do that, if it hasn't already been done with the state of the art encoders -- it sounds like it unwinds to client compatibility, which happily Mozilla and Google have some significant influence over! Mike
Re: [whatwg] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 8:00 AM, Chris DiBonacdib...@gmail.com wrote: actually shipping with Theora (also on android, too) I was looking for a reference to this, but haven't found anything yet. http://developer.android.com/guide/appendix/media-formats.html lists Vorbis, but not Theora, and I can't find any announcements about it elsewhere either. Any leads? :) Mike
Re: [whatwg] H.264-in-video vs plugin APIs
Let me ask David Sparks and see where it went, I remember we had it in the inital drops, or thought we did. On Sat, Jun 13, 2009 at 10:35 AM, Mike Shavermike.sha...@gmail.com wrote: On Sat, Jun 13, 2009 at 8:00 AM, Chris DiBonacdib...@gmail.com wrote: actually shipping with Theora (also on android, too) I was looking for a reference to this, but haven't found anything yet. http://developer.android.com/guide/appendix/media-formats.html lists Vorbis, but not Theora, and I can't find any announcements about it elsewhere either. Any leads? :) Mike -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 10:39 AM, Chris DiBonacdib...@gmail.com wrote: Let me ask David Sparks and see where it went, I remember we had it in the inital drops, or thought we did. That'd be great -- all I can find reference to is Vorbis, as used for the ringtones and system sounds (righteous!) Mike
Re: [whatwg] H.264-in-video vs plugin APIs
Also sprach Chris DiBona: I don't think the bandwidth delta is very much with recent (and format-compatible) improvements to the Theora encoders, if it's even in H.264's favour any more, but I'd rather get data than share suppositions. Can you send me a link to raw video for the clip at http://www.youtube.com/demo/google_main.mp4?2 so I can get it converted with the state of the art encoder and we can compare numbers? I'll see if I can get the numbers/video for you on that (and I'll do it off list, for th sake of the whatwg mailing list :-) It's great if you can find information on this. I believe many people on this list would be interested, so I suggest you send it to the list. Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] H.264-in-video vs plugin APIs
Mike Shaver wrote: b) bandwidth concerns (but even if Theora took _double_ the bandwidth, and _all_ the content was converted overnight, that's still only a 25% increase in bandwidth, plus a few percent for Chrome when it ships video as well) Actually, looking at http://en.wikipedia.org/wiki/Youtube#Format_and_quality_comparison_table I'm pretty confident that Theora (once Theora 1.1 with encoder-improvements has landed) can deliver usable quality at the resolution/bitrate combinations YouTube uses (e.g. 320x240 at 200 kbit/s or 480x360 at 512 kbit/s). It may not touch H.264's quality, but it'll for sure give more pleasing results than the Sorenson-flavor H.263 FLV content YouTube grew big with. In doubt one can also dedicate some bits otherwise spent on audio to video (128 kbit/s audio for Medium/High quality is plenty given how well Vorbis performs). It appears quite possible to come up with encoding parameters to get the job done with good enough quality that don't require additional combined bitrate. I of course cannot comment on what resources Google/YouTube have available, but I feel compelled to point out that freeing ~25% of users (Firefox and Opera being Ogg-only) from the need of using Flash on YouTube may very well have a strategic value to Google to enhance the effect of their open-web strategy. Anyway, that's of course something Google will have to discuss internally. bye, Maik Merten
Re: [whatwg] H.264-in-video vs plugin APIs
It'll take a little while, I'm travelling a bit this month (brazil , new york, etc..) Chris On Sat, Jun 13, 2009 at 10:55 AM, Håkon Wium Liehowc...@opera.com wrote: Also sprach Chris DiBona: I don't think the bandwidth delta is very much with recent (and format-compatible) improvements to the Theora encoders, if it's even in H.264's favour any more, but I'd rather get data than share suppositions. Can you send me a link to raw video for the clip at http://www.youtube.com/demo/google_main.mp4?2 so I can get it converted with the state of the art encoder and we can compare numbers? I'll see if I can get the numbers/video for you on that (and I'll do it off list, for th sake of the whatwg mailing list :-) It's great if you can find information on this. I believe many people on this list would be interested, so I suggest you send it to the list. Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] H.264-in-video vs plugin APIs
Gregory Maxwell wrote: Perhaps then you wouldn't mind sharing the rough breakdown of how many YouTube distributed videos are the 'high quality' files which are encoded in H.264 and only provided on user-request vs the normal quality, which is provided by default, and which doesn't use H.264. I think that by now also standard quality uses H.264 (at least according to the Wikipedia article on YouTube). This of course doesn't change the fact that YouTube flourished despite using a vastly outdated codec (that most likely is clearly outperformed by Theora) for years. Maik
Re: [whatwg] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 11:25 AM, Chris DiBonacdib...@gmail.com wrote: It'll take a little while, I'm travelling a bit this month (brazil , new york, etc..) Yep, I'll reach out to the o3d guys directly as well, see if they have the source video for that clip. More than happy to do the measurements on this side, I know what a pain travel can be... Mike
Re: [whatwg] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 10:58 AM, Maik Merten maikmer...@googlemail.comwrote: Mike Shaver wrote: Yep, I'll reach out to the o3d guys directly as well, see if they have the source video for that clip. More than happy to do the measurements on this side, I know what a pain travel can be... I'll happily provide encoding-assistance if wanted :-) Maik I would be willing to as well, if wanted :)
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] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 3:06 PM, Frank Hellenkampjo...@depagecms.net wrote: [snip] Well, the thing is (perhabs unfortunately because of patents and liscensing) that you can use h264 with the video tag (in safari and chrome), but at the same time you can send the same video to every old browser with the flash player 9 or 10, because it also supports h264, which means IE 6/7/8, old Safari, Firefox, Opera etc. And there is the iPhone and Android. With Theora, you cannot do this. All in all it looks like, it's very hard to beat h246 at the moment. Although you *can* use the Theora file in every browser that has a working JVM and a little surplus of cpu cycles. For example: http://www.celt-codec.org/presentations/A small bit of easily added JS automatically replaces the video tag with an alternative Theora player when video will not work. It's also theoretically possible to also serve modern systems with Flash 10 in this manner, but no one has written the software yet. (The Vorbis support is done, the Theora support has not yet been done) Unfortunately, though perhaps not surprisingly, the intersection of people who care about open video standards and competent low level flash applet developers appears to be the empty set. Even old versions Safari, IE, firefox, etc also gain the ability gain the ability to play Ogg/Theora if the user downloads and installs a plugin (i.e. VLC; or a JVM for the above mentioned java approach). Far from ideal— but the user installing a plugin is exactly how those older systems got flash, so we have an existence proof. I don't disagree that the current solution set for Theora has gaps, but it's not as simple as it can't do that as you make it sound. Cheers
Re: [whatwg] H.264-in-video vs plugin APIs
Frank Hellenkamp wrote: Well, the thing is (perhabs unfortunately because of patents and liscensing) that you can use h264 with the video tag (in safari and chrome), but at the same time you can send the same video to every old browser with the flash player 9 or 10, because it also supports h264, which means IE 6/7/8, old Safari, Firefox, Opera etc. And there is the iPhone and Android. I think nobody seriously proposes YouTube should stop providing H.264 versions :-) With Theora, you cannot do this. Theora, however, can reach the majority of browsers implementing video out-of-the-box while H.264 can't (for both exist solutions building on widespread plugins - Flash for H.264 and Java for Theora). If Google sees any value in making video a first-class citizen in an open web (and I have no doubt in that) it may make sense to *additionally* provide versions in Theora so they can benefit from HTML5-media features they helped define. All in all it looks like, it's very hard to beat h246 at the moment. Well, depending on circumstances one can also say it's very hard to use H.264 ;-) bye, Maik
Re: [whatwg] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 11:45 PM, Mike Shavermike.sha...@gmail.com wrote: On Sat, Jun 13, 2009 at 9:37 AM, Chris DiBonacdib...@gmail.com wrote: If Youtube is held back by client compatibility, they should be glad that we're working hard to move ~25% of the web to having Theora support in the near future! Google could help that cause a lot by putting (well-encoded, ahem) Theora up there, even if it's just in the experimental /html5 area. It wouldn't hurt to use the reference libraries rather than ffmpeg for the client either, since we've found significant differences in quality of experience there. I'm also very excited to see Ogg Theora/Vorbis support being included into Chrome, which will even further increase the percentage of coverage. As for Safari and any other software on the Mac that is using the QuickTime framework, there is XiphQT to provide support. It's a QuickTime component and therefore no different to installing a Flash plugin, thus you can also count Safari as a browser that has support for Ogg Theora/Vorbis, even if I'm sure people from Apple would not like to see it this way. Opera have experimented with Ogg Theora/Vorbis and the latest test builds seem to include support for Ogg Theora/vorbis, even if I'm going by anecdotal evidence here. So, the only real problem that we have with coverage is Internet Explorer. Now, if somebody was to sponsor the development of an ActiveX control for Ogg Theora/Vorbis support, we would solve this in a flash. Most of the implementation work for it is done: in about 2004 at the CSIRO we developed oggcodecs, which are DirectShow filters for Xiph codecs. We also had an experimental ActiveX control, but it would need to be rewritten largely. Just like Adobe (or at the time Macromedia) didn't expect Apple or Microsoft to develop support for their video players, we don't have to wait for that either. I don't see coverage as a fundamental problem that should hold back Ogg Theora/Vorbis support. Instead, I see it as a financial problem - somebody has to just put the money towards it. Best Regards, Silvia.
Re: [whatwg] getImageData/putImageData comments
Boris Zbarsky wrote: It's not that hard, it's an extra four or five lines of code to fill in multiple pixels in a square (two nested for-loops and an expression or two to work out what the limit is). Compared to the maths such code would be doing anyway, this is trivial stuff. The hard part is realizing you have to do it... And in particular, the fact that it's not just filling in multiple pixels in a square... For another example, consider an algorithm that wants to reduce the size of the image by 1px horizontally (e.g. content-aware image resizing as demoed using canvas at http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/). If we're shrinking by one device pixel, then suddenly we can't even create a canvas of the right size for the new image, because canvas size is specified in integer CSS pixels. Note that the algorithm used here, basically off-the-shelf, would in fact want to work on device pixels the way the spec is written right now; in general it would want to work on whatever pixels imagedata is in. If we want to shrink by one CSS pixel, so we can actually draw the canvas, then each shrink step needs to apply the algorithm N times, right? But what if N is, say, 2.5, as it can be in Safari? It's been pointed out before that 1 css pixel can map to a fractional number of device pixels there... That algorithm can't very well be applied 2.5 times. Of course my Julia set example would also need to do something a lot more interesting than just fill in multiple pixels in a square when the css-to-device pixel ratio is non-integral. Note that I don't have a proposed solution here; I'm just pointing out that the authoring pitfalls here are a lot more complicated than you seem to give them credit for. -Boris
Re: [whatwg] H.264-in-video vs plugin APIs
On Sat, Jun 13, 2009 at 8:00 AM, Chris DiBonacdib...@gmail.com wrote: Comparing Daily Motion to Youtube is disingenuous. If yt were to switch to theora and maintain even a semblance of the current youtube quality it would take up most available bandwidth across the internet. [snip] I'm not sure what mixture of misinformation and hyperbole inspired this remark, but I believe that it is misleading and to leave it stand without comment would be a disservice to this working group. I have prepared a detailed response: http://people.xiph.org/~greg/video/ytcompare/comparison.html I understand that the selection and implementation of video, especially at the scale of YouTube, is worlds apart from such a simplistic comparison. But you didn't claim that Theora support would be inconvenient, that it would require yet-unjustified expenditure, or that the total cost would simply be somewhat higher than the H.264 solution. You basically claimed that Theora on YouTube would destroy the internet. I'd consider that too silly to respond to if I didn't know that many would take it as the literal truth. Even though I wish Google were doing more to promote open video, I appreciate all that it has done so far. I hope that I'll soon be able to add a retraction or amendment of that claim to the list. Cheers, Greg Maxwell
