Re: [whatwg] H.264-in-video vs plugin APIs
Hi Chris, I provide an additional comparison at http://people.xiph.org/~maikmerten/youtube/ using different content. This doesn't qualify as more movement/action (it's hard to get free HD samples of such content in good quality), but content like the one I used is common nonetheless on community video streaming platforms. bye, Maik Chris DiBona wrote: Hi greg; 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. Chris On Sun, Jun 14, 2009 at 1:15 AM, Gregory Maxwellgmaxw...@gmail.com wrote: 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
Re: [whatwg] H.264-in-video vs plugin APIs
On Mon, Jun 15, 2009 at 12:49 AM, Michael Dale d...@ucsc.edu wrote: I have requested that a few times as well... Some went so far to even make a mock up page: http://people.xiph.org/~j/apple/preview/ It would or course be much more ideal if we could get the component into quicktime codec lookup system. Is there any criteria or process that has been made publicly available? Are there any guidelines or special request mechanisms that we have missed? Eric or anyone at apple reading this list: if you have _any_ information as to how a codec component gets into the quicktime codec lookup system; it would be great if you could inform us. --Michael Dale Silvia Pfeiffer wrote: I'm sorry, but there is quite a bit of frustration from the past hidden in my paragraph. For the last 4 years we have been trying to get XiphQT added to the list of QuickTime components on Apple's external components webpage at http://www.apple.com/quicktime/resources/components.html . We have seen proprietary codecs added one after the other but Xiph codecs continuously being ignored even though we requested addition multiple times and through different people. I'm sorry to say but that has indeed caused a feeling of being rejected on purpose. We would love to see this situation rectified. Regards, Silvia. On Mon, Jun 15, 2009 at 2:48 AM, Eric Carlsoneric.carl...@apple.com wrote: Silvia - On Jun 13, 2009, at 7:02 PM, Silvia Pfeiffer wrote: 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. Speaking of misinformation and hyperbole, what makes you say people from Apple want to hide the fact that Safari supports third party QuickTime codecs? We *could* have limited WebKit to only support QuickTime's built-in formats, but did not specifically so customers can add other formats as they choose. We have never tried to hide this, it is ridiculous to imply otherwise. eric I don't even think QuickTime has a codec lookup system. For codecs that are unavailable, it just points me to the page, even if the codec doesn't exist on that page. I remember that either QuickTime 4 or 5 had a codec lookup and download system... Not sure about QuickTime 6. Definitely not QuickTime 7. Maybe QuickTime X will have one again?
Re: [whatwg] H.264-in-video vs plugin APIs
On Sun, Jun 14, 2009 at 12:08 AM, Chris DiBonacdib...@gmail.com wrote: 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. I wonder if you've actually talked to a video-specialised IP lawyer about a comparison of Theora and Dirac toward their patent infringement risk. I have had many conversations around this and the arguments I heard are the following: * Theora is based on DCT compression technologies that have been around for a long time; most of the technologies are well understood, and their related patents are clearly beyond current claims; some other techniques that have been built on top are newer and there may be submarine patents, but they are few and have come out of a community that understands the space well. * Dirac is based on the much newer Wavelet compression technologies, which have only been around for a relatively short time; therefore there are still many new patents - probably even patents that have not been seen by the community at large; while the BBC lawyers and developers certainly did all they could to try and avoid known patents, the share of known versus unknown patents in this new space is likely much smaller than in the DCT space and therefore the risk of submarine patent is higher.. Therefore, as was explained to me, the patent infringement risk is actually larger with Dirac than with Theora. I personally believe that neither of these codecs infringe on any patents, because a lot of thought has gone into both to make sure this not the case. But - like any other codec - the threat of submarine patents is always around. Best Regards, Silvia.
Re: [whatwg] H.264-in-video vs plugin APIs
Hi greg; 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. Chris On Sun, Jun 14, 2009 at 1:15 AM, Gregory Maxwellgmaxw...@gmail.com wrote: 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 -- 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
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
On Sun, Jun 14, 2009 at 12:27 PM, Simon Spiegel si...@simifilm.ch wrote: On 14.06.2009, at 04:02, Silvia Pfeiffer wrote: 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. It's actually quite different, on a technical level and for the user. Flash is a browser plugin and XiphQT is an additional Quicktime codec. Quicktime has supported third party codec for years; the whole point of this is that any app which uses Quicktime can make use of these third party codecs – like Safari does. A browser plugin like Flash OTOH is useless outside the browser. So like I said: these are quite different things on several level. Simon -- Simon Spiegel Steinhaldenstr. 50 8002 Zürich Telephon: ++41 44 451 5334 Mobophon: ++41 76 459 60 39 http://www.simifilm.ch „Was soll aus mir mal werden, wenn ich mal nicht mehr bin?“ Robert Gernhardt It's all well and good that XiphQT can be used to support video and audio tags in Apple's build of WebKit for Safari, which I have tested and see to be truth, but a problem I see is that people won't KNOW where to get the codecs. I remember that QuickTime used to be able to grab codecs and install them from the internet like RealPlayer does now. For future versions of QuickTime, like the rumored QuickTime X, will that be brought back? It makes sense that QuickTime should be able to search and grab the XiphQT codecs if they are needed.
Re: [whatwg] H.264-in-video vs plugin APIs
I have requested that a few times as well... Some went so far to even make a mock up page: http://people.xiph.org/~j/apple/preview/ It would or course be much more ideal if we could get the component into quicktime codec lookup system. Is there any criteria or process that has been made publicly available? Are there any guidelines or special request mechanisms that we have missed? Eric or anyone at apple reading this list: if you have _any_ information as to how a codec component gets into the quicktime codec lookup system; it would be great if you could inform us. --Michael Dale Silvia Pfeiffer wrote: I'm sorry, but there is quite a bit of frustration from the past hidden in my paragraph. For the last 4 years we have been trying to get XiphQT added to the list of QuickTime components on Apple's external components webpage at http://www.apple.com/quicktime/resources/components.html . We have seen proprietary codecs added one after the other but Xiph codecs continuously being ignored even though we requested addition multiple times and through different people. I'm sorry to say but that has indeed caused a feeling of being rejected on purpose. We would love to see this situation rectified. Regards, Silvia. On Mon, Jun 15, 2009 at 2:48 AM, Eric Carlsoneric.carl...@apple.com wrote: Silvia - On Jun 13, 2009, at 7:02 PM, Silvia Pfeiffer wrote: 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. Speaking of misinformation and hyperbole, what makes you say people from Apple want to hide the fact that Safari supports third party QuickTime codecs? We *could* have limited WebKit to only support QuickTime's built-in formats, but did not specifically so customers can add other formats as they choose. We have never tried to hide this, it is ridiculous to imply otherwise. eric
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] 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
[whatwg] H.264-in-video vs plugin APIs
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
