A keyframe interval of 250 frames was used for the Theora encoding.
10 seconds is absurdly short for any kind of codec test. That's almost as long as the buffer would be, and current Thusndela builds don't include full buffer management. Plus he picked a pretty low motion section of the clip. He should the full clip. Current Theora builds are plenty fast; it'd be faster than realtime on a laptop.
In a real codec compare, CBR is often the best way to see differences between codecs and implementations, since that's where rate distortion really shows its stuff. How well a codec can preserve quality with high motion in a fixed buffer is a key differentiatior.
That said, I believe that the Theora+Vorbis results are substantially better than the YouTube 327kbit/sec. Several other people have expressed the same view to me, and I expect you'll also reach the same conclusion. This is unsurprising since we've been telling people that Theora is better than H.263
His primary quality comparison is between Theora and H.263, not H.264. H.263 is even older than VP3 which Theora is based on. As to H.264 he says:
In the case of the 499kbit/sec H.264 I believe that under careful comparison many people would prefer the H.264 video.
Yep. And it would be a huge differential if he'd picked a more challenging section of the source.
And while it doesn't have any impact on the comparison, no compressionist would use those frame sizes. We always try to round to the nearest mod16 value, so that we have macroblock alignment.
Thus 480x272 and 400x224 would be more efficient choices in both cases. 400x226 is particulary egregious, as it means the codec is really encoding at 400x240 internally with 14 lines of padding.
No, the problem is decoding too. Software decode is fine on the desktop, but a non-starter for phones. Good phone video requires and uses ASIC or GPU acceleration. Theora, as a much older and simpler codec will probably decode faster in software than a maxed-out H.264 bitstream, but even if it could get to full-screen on a handset, it'd require a lot more bandwidth, and would run the battery down very quickly.
"Bandwidth is the problem" is also very much Theora's problem. The rather...odd example linked to aside, for any interesting bitrate or quality, Theora will need at least 2x as many bits to hit the same quality level as H.264 High Profile.
The example page is a little confusing. While they compare Theora to H.264 (and admit it wins), their "money" compare is to H.263, which is a VP3 era codec in its own right. If they compared a good H.264 encode to Theora at the 327 Kbps bitrate, H.264 would turn Theora into a thin red paste.
Now I see it can install apps and updates directly to the desktop, and is based on.net/mono - absolutely no way!
It's not running native code apps, sheesh. It's the same managed code sandbox and security model as the browser plugin, but can run without being in a browser proper.
But the (high) security model remains the same. It's just like opening "Default.html" from the desktop.
The story of Microsoft and IE is a good example of why people distrust your company so much. A technically interesting browser, which foreshadowed a lot of the developments on the web now, was deliberately left to stagnate for years after Microsoft imposed it as the dominant browser.
The IE6-IE7 gap wasn't due to some clever plan. IE7 was always meant to ship with Vista, and so with the Vista delays, IE6 remained on the market longer than anyone had imagined. But Microsoft certainly was at least as frustrated by how late Vista and IE7 were as anyone else.
Given that every IE6 user is also an XP user who hasn't upgraded to Vista or (soon) Windows 7, Microsoft has a big business incentive to make IE6 go away. And the very fact that IE7 and IE8 exist and are architected to balance compatibility with IE6-specific sites and standards based sites is exactly what needs to happen, so that businesses don't feel like they have to stay on IE6 forever to retain compatibility with crufty old LOB intranet pages.
HTML 5 support doesn't look like it's coming to IE8 - I wonder why not?
Er, because it shipped:)? HTML5's not coming to Safari 3, is it? I assume you're speaking of the tag; IE8 does have some other HTML5 features. Also, HTML5 is still in draft form, and no one has as full implementation of it. There's no tagged content that works in both Safari and Firefox. It's an interesting technology, but it's not final, no one has a robust implementation of what's in there yet, and the whole "what's the basline codec/format" question remains wide open.
If anything, Silverlight would be a great way to implement HTML5. Silverlgiht already has the compositing and media playback engines browsers lack, supports managed code codec plugins, and can have logic updated as managed code out of band without binary updates.
Silverlight would be a better platform to implement than will be a viable competitor to Silverlight anytime soon.
I'm sure *in theory* Silverlight could have exactly the same functionality on Windows, Mac and Linux, but until I see it actually happen, it's really of no interest.
Well, what have you seen so far? Any sites that work in Silverlight for Windows but not Mac? Any features in Silverlight which Moonlight isn't going to be able to implement? increasing divergence between Silverlight/Moonlight? It seems like things are going in the direction you're saying you want them to go.
With HTML 5 this sort of binary plugin becomes less and less relevant every day.
Why do you think HTML 5 won't be implemented with a binary plugin? Chrome uses ffmpeg. Safari uses QuickTime. Building a robust media pipeline is HARD; it'd take browser developers years to integrate that kind of functionality as a truly native part of the browser model, instead of a "oh, binary over there, you own this rectangle" approach.
And I'm sure it'll remain consistently at least one version behind the Windows one, and still missing features, just as Microsoft would prefer. Moonlight has not even reached parity with Silverlight 2.0 as a final release, let alone 3.0.
Functionally, Moonlight is probably somewhere between Silverlight 2 and 3. It already includes quite a few Silverlight 3 features in its current preview.
And bear in mind that Silverlight 3 isn't out yet.
Silverlight already had Mac/Win parity, and most of the code sits on top of a platform abstraction layer. So it's already proven to have full functionality outside of Windows.
Silverlight 3 also features hardware 3D acceleration. I don't know how far Moonlight has come there. The other parts such as C# 4 and DLR Mono and Moonlight actually seems to be not to far behind.
Moonlight has actually had GPU compositing and scaling via Cairo for the last few previews, in advance of that support in Silverlight 3.
They are providing their own solutions, which are in some cases inferior to competing solutions (performance, acceleration, features, quality)
Citation? Are there issues you're aware of with the built-in Win 7 codecs?
This in place of, for example, better designing their new media architecture (media foundation) to allow easy management of what gets used via API/UI as a solution to the problem.
And what would that even look like? It's hard to imagine users with codec problems beign able to take good advantage of that kind of control.
YouTube and DailyMotion use progressive download, not streaming.
The experience is similar as long as you have a lot of bandwidth and shorter content. But doing progressive download of a 2 hour 4 Mbps HD movie is not a good experience.
These are also unconstrained VBR; real world encoding would use a peak bitrate, and if streaming would even be CBR, which would make xvid even less competitive.
Maybe for a next step you cold define your scenario in some more detail?
Heck, just whipped out some short 320x240p30 400 Kbps encodes for WMV, x264, and xvid. To avoid arguments about tuning, I pretty much just turned on ever expensive feature that might improve quality; these are all much slower settings than you'd use in production, but shows what the best current implementations are generally capble of.
Looking at the VC-1, I recall we've been much more focused on higher bitrates and resolutions than this in the last few years. But even still it outperforms xvid.
Send me to some demo videos then, and also links to all the settings used.
We researched it quite heavily a year or so back. All the "superior" h.264 examples were superior because they lied about their bitrates. In one example a clip was supposed to be 512kbit, but when we encoded it ourselves with x264 at ~800kbit, it came out smaller than the video that was supposedly 512kbit. (and still larger than it should've been)
The xvid was smaller than it, and superior in quality to our x264 encode. But if you have some examples to link to that are newer than roughly one year, send me the links and I'll look into them and pass them along.
Even a year ago x264 would have been dramatically superior. Odd.
Anyway, sure. What's your frame size? CBR or VBR? Any other notable constraints?
The Thusnelda encoder has already fixed some of the problems that Theora inherited from On2's VP3, thanks in part to the flexibility that Xiph added to the Theora bitstream format. Sure, it's still inferior to x264 (50% bigger rate for same distortion as of about a month ago), but it's improving.
Actually, 100%. And using a very non-representative clip (~10 seconds, no edits, low motion, no buffer constraint). No doubt Xiph and Monty have done heroic work with the bitstream and encoder they were given. But x264 and other H.264 and VC-1 implementations have improved a whole lot in the same timeframe, and keep on improving.
Theora is great for embedded devices like cell phones since it is "cheap" when it comes to cpu cycles.
Reference?
Anyway, it's actually not a good choice there becuse devices like cell phones tend to have ASICs for video decoding that support MPEG-4 part 2, VC-1, and H.264 Baseline, but not Theora. Trying to play back video on a phone in software is painful for battery life.
For top quality video, Dirac should be used. I wonder when Firefox, Opera or Konqueror will have native support for Dirac.
Direc has never been shown to be any better than Theora for content distribution bitrates. As an I-frame only production format, could be interesting (SMPTE VC-2). But no one has ever coupled wavelets to interframe coding efficiently.
Nothing beats Xvid for low bitrates. (The bitrates which create ~350MB videos)
x264 pounds xvid into dust at low bitrates.
h.264 gets quite blocky well before Xvid does
Er, no it doesn't. H.264 has a strong in-loop deblocking filter which leads it to degrade into softness well before it loses detail. If you're thinking of a metric like "no annoying artifacts" x264 can go down to half xvid bitrates at the same quality level. Codecs converge as quality goes up, but it's exactly low bitrate non-blocking video where H.264 excels, and what it was designed to do. And designed to do so specifically after the failure of MPEG-4 part 2 (xvid/divx) to be a competitive low bitrate codec.
A presentation with slides occasionally changing works wonderfully in VP7. It'll use a couple hundred kilobytes on the first frame, plus any frame where it suddenly changes, but aside from that it won't use much/any bandwidth. The result is a video that looks like a 32bit gif animation(perfect quality).
All non-pathological codecs will do the exact same thing.
Really, Theora may get to MPEG-4 part 2 Simple Profile quality with a lot of work, but no way will it ever be competitive with H.264 or VC-1.
The delay from IE6 to IE7 was really due to the delay of Vista (which IE7 shipped with), which itself was caused by the huge security effort behind XP SP2, and that was in large part about saving the internet from botnets.
Also, since IE7 and IE8 have since been released, stagnation isn't the issue now. Currenet versiosn of Windows ship with much more standards complaint browsers now, so the problem of legacy browsers won't be addressed by changing what ships on new computers.
Plus I'm not sure the Firefox servicing model really would work for a market where people just don't update their software for years on end. One of the reasons IE doesn't get updated that often is that each release needs to be able to stand on its own for years. Firefox can innocate more rapidly when users update rapidly, but that's not a safe assumption for other markets.
Come back after you've spent a week making a really nice, easy to use, easy on the eyes website to standards, then spent another week making it work in IE7, then another 3 weeks making it work in IE6 (yes lots of people still use that P.OS.)
It sounds like a more straightforward solution for you then would be to require Microsoft to bundle IE8:).
IE6 came out before Mozilla 1.0. Is it really that much less standards compatible than Mozilla 0.9 was?
Vista came with the much better IE7, and Windows 7 will come with the better yet IE8.
If the problem is people don't bother to update their browsers, worrying about what's bundled with new machines doesn't seem that fruitful. It's the old machines that are the problem, and the solution is getting those replaced or upgraded.
At this point, I imagine that most of the IE6 installs are behind corporate firewalls, requiring IT to update them. And those are exactly the installs where the actual user will never get a choice of a browser; it'll be preconfigured on the standard corporate image. And Firefox doesn't even try to be enterprise deployable.
Adobe has no grounds to sue gnash/swfdecode, its an implementation based on an open standards.
Microsoft has a stockpile of software patents and are known to threaten people with them (although I'm yet to see them go after anybody that could defend themselves).
I think Adobe's been at least as litigous a company as Microsoft. The whole suing Macromedai over UI elements, DMCA lawsuits over Acrobat and now Flash streaming implementatiosns. And Silverlight itself takes big advantage of published standards and specifications, as dicussed upthread.
I'm not sure why you think Microsoft would have more grounds to sue over Moonlight than Adobe would over Gnash, but IANAL. I understand you're more worried that Microsoft would be inclined to do so, but that's a very different matter than having grounds to do so.
While it may not set a legal president, it has the clear ramification that they have patents and the implicit ramification that these patents are valid (much like the outcome recent tomtom case).
IANAL, and neither are you:). But if you ask one, you may find that there's much less implied than you might think by that kind of covenant. Legal documents are pretty specifically about what they're about. And in the case of this particular covenant, it's aimed at addressing the specific question of "how do I know I won't be sued." But it makes no implications as to whether or not you would or could have been sued without the covenant.
I could give you a covenant right now that I'm not going to sue you for libel for this discussion here on Slashdot. In fact, I will. "I, Ben Waggoner, owner of this Slashdot account, do hereby waive any claim for libel stemming from any posts made by the user posting as 'RiotingPacifist,' made chronologically before the post containing this waiver, in the Slashdot thread this post was originally posted in." And as far as I know, that should be legally binding. I said it, I meant it, and I am leading you to believe I meant it.
But that in no way suggests that you've actually said anything libelous (you haven't), or that I'm going to sue you for anything you say in the future or in another thread. I'm incredibly unlikely to do so of course, or to have grounds to do so, but I haven't waived any rights to do so outside of the scope of what I said above. So, what's happened is I've given you protection from being sued for something in particular (being sued for libel for your posts here prior to this one), but there has been no change in status about anything else. And in fact the waiver is pretty much meaningless for you since I couldn't have successfully sued you for libel anyway since you hadn't done it. Make sense?
Now, you feel you should hold Microsoft to a higher standard than Adobe. And that's fine. We understand that will be true we engage with the open source community. And so we proactively do things like this covenant, the Open Specification Promise, etcetera, to specifically address issues with open source interoperabilty. And there certainly could be additional things we do to address concerns around Moonlight/Silverlight as well as in other areas.
I would ask that you note that these are substantive real measures we're taking with real value to the open source community. Asking for more is perfectly fine, but I hope we can agree Microsoft has already done more than nothing here.
But compare to Adobe's covenant not to sue users of Gnash...
Perhaps it's better to think of this as the answer to the "how do I know you won't sue me if I use this?" question. Thus a binding document waiving that right, so now you know you won't be sued for using Moonlight. It doesn't have any ramifications one way or another for any part not listed.
YouTube does clips under 12 minutes, and pioneered the "pause and play" experience to get around playback pausing. And users have to manaully pick the bitrate/quality level they want.
Smooth Streaming can do instant start, fast random access over a full-length movie, giving the use the best version of the contetn they can have at that moment.
YouTube can do YouTube, but that's no way to watch content you actually want to lean back and enjoy. We're aiming to have Smooth Streaming be a "PVR in the cloud." And with Silverlight 3, it'll be able to do 1080p on a Core 2 Duo.
While Moonlight is a Novell product based on Mono, GPL'ed and all that, it also gets support from Microsoft in providing unit tests and that kind of thing.
And for media formats, Silverlight 3 supports: WMV (VC-1 is a SMPTE standard, other components under RAND licensing) MPEG-4 with H.264 and AAC-LC (ISO spec) MP3 (ISO spec) Generic extensibility via Raw AV MediaStreamSource
There's even a royalty-paid codec pack for Moonlight provided by Microsoft.
If you've got practical suggestions for how we could be more open than this, I'd love to hear them, but I think there has already been a lot of traction in that direction. It certainly goes well beyond what Adobe does for Gnash, and Moonlight is already capable of handling many more high-profile Silverlight sites than any non-Adobe Flash player is. Even:
Slashdot Mirror
Reread Shaver's methadology:
A keyframe interval of 250 frames was used for the Theora encoding.
10 seconds is absurdly short for any kind of codec test. That's almost as long as the buffer would be, and current Thusndela builds don't include full buffer management. Plus he picked a pretty low motion section of the clip. He should the full clip. Current Theora builds are plenty fast; it'd be faster than realtime on a laptop.
In a real codec compare, CBR is often the best way to see differences between codecs and implementations, since that's where rate distortion really shows its stuff. How well a codec can preserve quality with high motion in a fixed buffer is a key differentiatior.
That said, I believe that the Theora+Vorbis results are substantially better than the YouTube 327kbit/sec. Several other people have expressed the same view to me, and I expect you'll also reach the same conclusion. This is unsurprising since we've been telling people that Theora is better than H.263
His primary quality comparison is between Theora and H.263, not H.264. H.263 is even older than VP3 which Theora is based on. As to H.264 he says:
In the case of the 499kbit/sec H.264 I believe that under careful comparison many people would prefer the H.264 video.
Yep. And it would be a huge differential if he'd picked a more challenging section of the source.
And while it doesn't have any impact on the comparison, no compressionist would use those frame sizes. We always try to round to the nearest mod16 value, so that we have macroblock alignment.
Thus 480x272 and 400x224 would be more efficient choices in both cases. 400x226 is particulary egregious, as it means the codec is really encoding at 400x240 internally with 14 lines of padding.
No, the problem is decoding too. Software decode is fine on the desktop, but a non-starter for phones. Good phone video requires and uses ASIC or GPU acceleration. Theora, as a much older and simpler codec will probably decode faster in software than a maxed-out H.264 bitstream, but even if it could get to full-screen on a handset, it'd require a lot more bandwidth, and would run the battery down very quickly.
"Bandwidth is the problem" is also very much Theora's problem. The rather...odd example linked to aside, for any interesting bitrate or quality, Theora will need at least 2x as many bits to hit the same quality level as H.264 High Profile.
The example page is a little confusing. While they compare Theora to H.264 (and admit it wins), their "money" compare is to H.263, which is a VP3 era codec in its own right. If they compared a good H.264 encode to Theora at the 327 Kbps bitrate, H.264 would turn Theora into a thin red paste.
Now I see it can install apps and updates directly to the desktop, and is based on .net/mono - absolutely no way!
It's not running native code apps, sheesh. It's the same managed code sandbox and security model as the browser plugin, but can run without being in a browser proper.
But the (high) security model remains the same. It's just like opening "Default.html" from the desktop.
The story of Microsoft and IE is a good example of why people distrust your company so much. A technically interesting browser, which foreshadowed a lot of the developments on the web now, was deliberately left to stagnate for years after Microsoft imposed it as the dominant browser.
The IE6-IE7 gap wasn't due to some clever plan. IE7 was always meant to ship with Vista, and so with the Vista delays, IE6 remained on the market longer than anyone had imagined. But Microsoft certainly was at least as frustrated by how late Vista and IE7 were as anyone else.
Given that every IE6 user is also an XP user who hasn't upgraded to Vista or (soon) Windows 7, Microsoft has a big business incentive to make IE6 go away. And the very fact that IE7 and IE8 exist and are architected to balance compatibility with IE6-specific sites and standards based sites is exactly what needs to happen, so that businesses don't feel like they have to stay on IE6 forever to retain compatibility with crufty old LOB intranet pages.
HTML 5 support doesn't look like it's coming to IE8 - I wonder why not?
Er, because it shipped :)? HTML5's not coming to Safari 3, is it? I assume you're speaking of the tag; IE8 does have some other HTML5 features. Also, HTML5 is still in draft form, and no one has as full implementation of it. There's no tagged content that works in both Safari and Firefox. It's an interesting technology, but it's not final, no one has a robust implementation of what's in there yet, and the whole "what's the basline codec/format" question remains wide open.
If anything, Silverlight would be a great way to implement HTML5. Silverlgiht already has the compositing and media playback engines browsers lack, supports managed code codec plugins, and can have logic updated as managed code out of band without binary updates.
Silverlight would be a better platform to implement than will be a viable competitor to Silverlight anytime soon.
I'm sure *in theory* Silverlight could have exactly the same functionality on Windows, Mac and Linux, but until I see it actually happen, it's really of no interest.
Well, what have you seen so far? Any sites that work in Silverlight for Windows but not Mac? Any features in Silverlight which Moonlight isn't going to be able to implement? increasing divergence between Silverlight/Moonlight? It seems like things are going in the direction you're saying you want them to go.
With HTML 5 this sort of binary plugin becomes less and less relevant every day.
Why do you think HTML 5 won't be implemented with a binary plugin? Chrome uses ffmpeg. Safari uses QuickTime. Building a robust media pipeline is HARD; it'd take browser developers years to integrate that kind of functionality as a truly native part of the browser model, instead of a "oh, binary over there, you own this rectangle" approach.
only about 35% of desktop users had Silverlight installed.
Which is more than the combined marketshare of Mac OS X, Linux, Firefox, Safari, Opera, and the iPhone.
And I'm sure it'll remain consistently at least one version behind the Windows one, and still missing features, just as Microsoft would prefer. Moonlight has not even reached parity with Silverlight 2.0 as a final release, let alone 3.0.
Functionally, Moonlight is probably somewhere between Silverlight 2 and 3. It already includes quite a few Silverlight 3 features in its current preview.
And bear in mind that Silverlight 3 isn't out yet.
Silverlight already had Mac/Win parity, and most of the code sits on top of a platform abstraction layer. So it's already proven to have full functionality outside of Windows.
Silverlight 3 also features hardware 3D acceleration. I don't know how far Moonlight has come there. The other parts such as C# 4 and DLR Mono and Moonlight actually seems to be not to far behind.
Moonlight has actually had GPU compositing and scaling via Cairo for the last few previews, in advance of that support in Silverlight 3.
Silverlight is essentially .NET bytecode + XAML markup + media .NET ECMA spec: http://www.ecma-international.org/publications/standards/Ecma-335.htm
Silverlight XAML spec (under Open Specification Promise):
http://blogs.windowsclient.net/rob_relyea/archive/2008/10/14/ms-slxv-silverlight-xaml-vocabulary-2008-specification-v0-9-published.aspx
Media is MPEG-4 or MP3 (ISO), Windows Media (VC-1 is a SMPTE spec), and the Raw AV pipeline for extensitbilty to aribtrary codecs.
As for interoperabilty and portability, how about a GPL'ed clean room implementation?
http://www.mono-project.com/Moonlight
They are providing their own solutions, which are in some cases inferior to competing solutions (performance, acceleration, features, quality)
Citation? Are there issues you're aware of with the built-in Win 7 codecs?
This in place of, for example, better designing their new media architecture (media foundation) to allow easy management of what gets used via API/UI as a solution to the problem.
And what would that even look like? It's hard to imagine users with codec problems beign able to take good advantage of that kind of control.
YouTube and DailyMotion use progressive download, not streaming.
The experience is similar as long as you have a lot of bandwidth and shorter content. But doing progressive download of a 2 hour 4 Mbps HD movie is not a good experience.
I intentionally picked some hard video.
These are also unconstrained VBR; real world encoding would use a peak bitrate, and if streaming would even be CBR, which would make xvid even less competitive.
Maybe for a next step you cold define your scenario in some more detail?
5.1 for 800x600? 8 ME range? I'm guessing you had some kind of configuration issue.
Did you check out the samples I posted?
Heck, just whipped out some short 320x240p30 400 Kbps encodes for WMV, x264, and xvid. To avoid arguments about tuning, I pretty much just turned on ever expensive feature that might improve quality; these are all much slower settings than you'd use in production, but shows what the best current implementations are generally capble of.
Looking at the VC-1, I recall we've been much more focused on higher bitrates and resolutions than this in the last few years. But even still it outperforms xvid.
http://cid-bee3c9ac9541c85b.skydrive.live.com/embedrowdetail.aspx/.Public/SMPTE%7C_320x240%7C_400Kbps
Send me to some demo videos then, and also links to all the settings used.
We researched it quite heavily a year or so back. All the "superior" h.264 examples were superior because they lied about their bitrates. In one example a clip was supposed to be 512kbit, but when we encoded it ourselves with x264 at ~800kbit, it came out smaller than the video that was supposedly 512kbit. (and still larger than it should've been)
The xvid was smaller than it, and superior in quality to our x264 encode. But if you have some examples to link to that are newer than roughly one year, send me the links and I'll look into them and pass them along.
Even a year ago x264 would have been dramatically superior. Odd.
Anyway, sure. What's your frame size? CBR or VBR? Any other notable constraints?
Sure, but they could just license the patenets for $2.5M/year and be good to go.
The Thusnelda encoder has already fixed some of the problems that Theora inherited from On2's VP3, thanks in part to the flexibility that Xiph added to the Theora bitstream format. Sure, it's still inferior to x264 (50% bigger rate for same distortion as of about a month ago), but it's improving.
Actually, 100%. And using a very non-representative clip (~10 seconds, no edits, low motion, no buffer constraint). No doubt Xiph and Monty have done heroic work with the bitstream and encoder they were given. But x264 and other H.264 and VC-1 implementations have improved a whole lot in the same timeframe, and keep on improving.
Theora is great for embedded devices like cell phones since it is "cheap" when it comes to cpu cycles.
Reference?
Anyway, it's actually not a good choice there becuse devices like cell phones tend to have ASICs for video decoding that support MPEG-4 part 2, VC-1, and H.264 Baseline, but not Theora. Trying to play back video on a phone in software is painful for battery life.
For top quality video, Dirac should be used. I wonder when Firefox, Opera or Konqueror will have native support for Dirac.
Direc has never been shown to be any better than Theora for content distribution bitrates. As an I-frame only production format, could be interesting (SMPTE VC-2). But no one has ever coupled wavelets to interframe coding efficiently.
Nothing beats Xvid for low bitrates. (The bitrates which create ~350MB videos)
x264 pounds xvid into dust at low bitrates.
h.264 gets quite blocky well before Xvid does
Er, no it doesn't. H.264 has a strong in-loop deblocking filter which leads it to degrade into softness well before it loses detail. If you're thinking of a metric like "no annoying artifacts" x264 can go down to half xvid bitrates at the same quality level. Codecs converge as quality goes up, but it's exactly low bitrate non-blocking video where H.264 excels, and what it was designed to do. And designed to do so specifically after the failure of MPEG-4 part 2 (xvid/divx) to be a competitive low bitrate codec.
A presentation with slides occasionally changing works wonderfully in VP7. It'll use a couple hundred kilobytes on the first frame, plus any frame where it suddenly changes, but aside from that it won't use much/any bandwidth. The result is a video that looks like a 32bit gif animation(perfect quality).
All non-pathological codecs will do the exact same thing.
Really, Theora may get to MPEG-4 part 2 Simple Profile quality with a lot of work, but no way will it ever be competitive with H.264 or VC-1.
Read this:
http://forum.doom9.org/showthread.php?t=146893
The delay from IE6 to IE7 was really due to the delay of Vista (which IE7 shipped with), which itself was caused by the huge security effort behind XP SP2, and that was in large part about saving the internet from botnets.
Also, since IE7 and IE8 have since been released, stagnation isn't the issue now. Currenet versiosn of Windows ship with much more standards complaint browsers now, so the problem of legacy browsers won't be addressed by changing what ships on new computers.
Plus I'm not sure the Firefox servicing model really would work for a market where people just don't update their software for years on end. One of the reasons IE doesn't get updated that often is that each release needs to be able to stand on its own for years. Firefox can innocate more rapidly when users update rapidly, but that's not a safe assumption for other markets.
Come back after you've spent a week making a really nice, easy to use, easy on the eyes website to standards, then spent another week making it work in IE7, then another 3 weeks making it work in IE6 (yes lots of people still use that P.OS.)
It sounds like a more straightforward solution for you then would be to require Microsoft to bundle IE8 :).
IE6 came out before Mozilla 1.0. Is it really that much less standards compatible than Mozilla 0.9 was?
http://en.wikipedia.org/wiki/Timeline_of_web_browsers
Vista came with the much better IE7, and Windows 7 will come with the better yet IE8.
If the problem is people don't bother to update their browsers, worrying about what's bundled with new machines doesn't seem that fruitful. It's the old machines that are the problem, and the solution is getting those replaced or upgraded.
At this point, I imagine that most of the IE6 installs are behind corporate firewalls, requiring IT to update them. And those are exactly the installs where the actual user will never get a choice of a browser; it'll be preconfigured on the standard corporate image. And Firefox doesn't even try to be enterprise deployable.
Adobe has no grounds to sue gnash/swfdecode, its an implementation based on an open standards.
Microsoft has a stockpile of software patents and are known to threaten people with them (although I'm yet to see them go after anybody that could defend themselves).
I think Adobe's been at least as litigous a company as Microsoft. The whole suing Macromedai over UI elements, DMCA lawsuits over Acrobat and now Flash streaming implementatiosns. And Silverlight itself takes big advantage of published standards and specifications, as dicussed upthread.
I'm not sure why you think Microsoft would have more grounds to sue over Moonlight than Adobe would over Gnash, but IANAL. I understand you're more worried that Microsoft would be inclined to do so, but that's a very different matter than having grounds to do so.
While it may not set a legal president, it has the clear ramification that they have patents and the implicit ramification that these patents are valid (much like the outcome recent tomtom case).
IANAL, and neither are you :). But if you ask one, you may find that there's much less implied than you might think by that kind of covenant. Legal documents are pretty specifically about what they're about. And in the case of this particular covenant, it's aimed at addressing the specific question of "how do I know I won't be sued." But it makes no implications as to whether or not you would or could have been sued without the covenant.
I could give you a covenant right now that I'm not going to sue you for libel for this discussion here on Slashdot. In fact, I will. "I, Ben Waggoner, owner of this Slashdot account, do hereby waive any claim for libel stemming from any posts made by the user posting as 'RiotingPacifist,' made chronologically before the post containing this waiver, in the Slashdot thread this post was originally posted in." And as far as I know, that should be legally binding. I said it, I meant it, and I am leading you to believe I meant it.
But that in no way suggests that you've actually said anything libelous (you haven't), or that I'm going to sue you for anything you say in the future or in another thread. I'm incredibly unlikely to do so of course, or to have grounds to do so, but I haven't waived any rights to do so outside of the scope of what I said above. So, what's happened is I've given you protection from being sued for something in particular (being sued for libel for your posts here prior to this one), but there has been no change in status about anything else. And in fact the waiver is pretty much meaningless for you since I couldn't have successfully sued you for libel anyway since you hadn't done it. Make sense?
Now, you feel you should hold Microsoft to a higher standard than Adobe. And that's fine. We understand that will be true we engage with the open source community. And so we proactively do things like this covenant, the Open Specification Promise, etcetera, to specifically address issues with open source interoperabilty. And there certainly could be additional things we do to address concerns around Moonlight/Silverlight as well as in other areas.
I would ask that you note that these are substantive real measures we're taking with real value to the open source community. Asking for more is perfectly fine, but I hope we can agree Microsoft has already done more than nothing here.
But compare to Adobe's covenant not to sue users of Gnash...
Perhaps it's better to think of this as the answer to the "how do I know you won't sue me if I use this?" question. Thus a binding document waiving that right, so now you know you won't be sued for using Moonlight. It doesn't have any ramifications one way or another for any part not listed.
YouTube does clips under 12 minutes, and pioneered the "pause and play" experience to get around playback pausing. And users have to manaully pick the bitrate/quality level they want.
Smooth Streaming can do instant start, fast random access over a full-length movie, giving the use the best version of the contetn they can have at that moment.
YouTube can do YouTube, but that's no way to watch content you actually want to lean back and enjoy. We're aiming to have Smooth Streaming be a "PVR in the cloud." And with Silverlight 3, it'll be able to do 1080p on a Core 2 Duo.
Er, no?
While Moonlight is a Novell product based on Mono, GPL'ed and all that, it also gets support from Microsoft in providing unit tests and that kind of thing.
And there's this agreement explicitly waiving the right to sue users of Moonlight getting it from Novell:
http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx
I think of Silverlight as having three pillars: .NET runtime, XAML, and media.
C# and the .NET CLI are both ECMA specs:
http://www.ecma-international.org/publications/standards/Ecma-335.htm
http://www.ecma-international.org/publications/standards/Ecma-334.htm
The specification for XAML has been published under the Open Specification Promise:
http://www.betanews.com/article/XAML-specification-published-added-to-Microsofts-open-promise/1206482161
And for media formats, Silverlight 3 supports:
WMV (VC-1 is a SMPTE standard, other components under RAND licensing)
MPEG-4 with H.264 and AAC-LC (ISO spec)
MP3 (ISO spec)
Generic extensibility via Raw AV MediaStreamSource
There's even a royalty-paid codec pack for Moonlight provided by Microsoft.
If you've got practical suggestions for how we could be more open than this, I'd love to hear them, but I think there has already been a lot of traction in that direction. It certainly goes well beyond what Adobe does for Gnash, and Moonlight is already capable of handling many more high-profile Silverlight sites than any non-Adobe Flash player is. Even:
http://www.smoothhd.com/
If you want to see what HTML5 can do, look at this:
And Firefox 3.0.10 tells me
Then crashed my browser :).
and this:
Is an embedded Flash player.