It is, however, a Windows only platform. Moonlight is still vaporware, last I heard. Silverlight is and always has been released day and date Mac/Windows. Moonlight is in development, and there's plenty of stuff there to mess around with if you like.
But YouTube is only like 315 Kbps per Wikipedia http://en.wikipedia.org/wiki/Youtube#Video_format. Are there any suggestions that bitrate is being throttled down THAT much? Also, it's progressive download via http, not any kind of streaming protocol.
Ah, 300 Kbps H.263 + mono 22 KHz MP3. Just like web video I was making a decade ago:).
Like I said above, that particular problem is actually pretty easy to fix, like we're doing in IIS 7 Media Pack. I'm sure other web servers will do the same thing eventually.
And streaming is inefficient. You not only require a continuous throughput at a reasonably high bitrate, but after you've finished downloading your 20 megabytes of content for that 2-minute video clip, your client does you the favor of immediately deleting it. So the next time you want to watch the video, you get the joy of re-downloading it. WTF? In an age of $200 terabyte hard drives, that's ridiculous. It doesn't have to be that way. In Windows Media, for example, we have the Fast Cache option, which allows the client to buffer the streamed assets so that you can watch the same part of the stream again without having to resend.
Now, in the big picture, the usage models between progressive download over http and streaming over UDP are going away pretty quickly. With byterange seek, you can do random access in progressive download now, and with server-side bitrate throttling you can avoid the problem of a user on a fast connection pulling down bits at 20x real time.
Now the one thing that's only possible with streaming is live broadcasting.
That said, I think the original article is rather misguided; nearly all streaming today is 3 Mbps or less, and most of it is less than 1000 Kbps. They could be doing a LOT of bandwidth capping and streaming would still work pretty well. The big limit for streaming is really all those people with 1.5 Mbps DSL lines, especially since in a modern household, that 1.5 Mbps can be split between lots of people and applications.
Really, that Ruby on Rails works in Silverlight is more a nice testament to the flexibility of the Dynamic Language Runtime in Silverlight than any big strategy on our part. Silverlight is an extremely flexible platform, and people can do all kinds of interesting things with it that we never thought of. I expect that the bulk of code written for Silverlight 2 and later will be in C#. But I'm always happy to see the new stuff people are coming up with inside Silverlight.
I think a lot of people start out thinking of it as "just another media player plugin" but the power of fast runtime is opening up a whole lot of neat stuff. I can't wait for 8/8/8 and NBC's Olympics coverage to start. I think it'll really raise the bar for what video on the web should be from both a quality and an interactivity perspective.
So why the need for "compression algorithms" to be patented?
MPEG4 enables better quality video to be compressed much more, making the movie advertisement much cheaper and making HD video a possibility. So without this, a loss to the companies. Eminently sufficient inducement for MPEG4 to be created without patents. Because lots of companies that aren't big CE vendors have a lot of very useful IP for codecs. Plus the CE vendors are perfectly happy to continue to get patent licensing revenue. As the DVD market has moved to about 95% "made in China" the patent licensing has provided substantial ongoing revenue for the companies who originally created the DVD market, but have since been priced out of it. Blu-ray can be very much viewed as an attempt to both reset the patent clock on high-volume CE to keep that revenue going as the MPEG-2 and DVD patents expire, and to provide something with a high barrier to entry for the Chinese companies to manufacture. Of course, the latter means prices stay high, so while it might help the big Japanese electronics companies, it isn't doing anything for Hollywood.
Anyway, that's another rant:).
To flip it around another way, yes, the CE vendors could have built a royalty free codec in partnership. But that would be a big expensive effort, and excluding patents from companies who would insist on being paid would make for a weaker codec. The codec licensing fees are pretty reasonable, and it made more financial sense to work with the big standardized codecs of MPEG-2, H.264, and VC-1.
Because Silverlight is self contained, and has no way to call external native code. It has no idea what if any version of.NET is installed. Same with codecs; those are all baked into the runtime, with no dependency on the native codecs available on the system.
Windows Media Audio 10 Pro and HE AAC both outperform Vorbis dramatically at lower bitrates. You can get quite good audio fidelity at 48 Kbps with either.
The object of Moonlight is to essentially be a "feature-complete" implementation of Silverlight, minus those pesky, patented, DRM-laced multimedia codecs.
The question is, then: "Does your Silverlight-based business application really need to use these pesky, patented, DRM-laced multimedia codecs?"
Which, in the vast majority of cases, is "probably not." Much of this kind of functionality can be had via calls to external (and FOSS) libraries A library can be FOSS, but that doesn't mean that there aren't patents involved.
Really, the sheer breadth and number of patents around video and audio codecs are pretty staggering. It's hard to imagine a competitive codec that was truly patent free; there certainly aren't any that exist. The current leading standardized codecs (with patent pools) outperform the best "patent free" codecs by at least a factor of 2. For video, we're talking about, what, H.263 and Theora, and Vorbis for audio? Those are mid-90's caliber.
A Silverlight app can be purely XAML (XML markup language) and JScript. That's all Silverlight 1.0 apps are. With Silverlight 2.0 you can use bytecode, but that's not required.
Then it's essentially useless because the reference implementation that is first to market is Microsoft's Silverlight, and you can bet your bottom dollar Microsoft's tools will be creating Silverlight content with Windows Media and other components right, left and centre. What comes down in practice is what you have to support. There's already a huge number of tools that can make Silverlight-compatible media content. Some of these are on Mac, including Telestream's Episode and Flip4Mac. Main Concept is selling a Mac/Win/Linux SDK for encoding WMV content. For audio only applications, Silverlight has native MP3 support.
You don't get a choice. You have to deal with whatever comes down, and what comes down will have pretty much all been created on Windows systems. The key thing to remember hear is that people are not writing content for Moonlight. They are writing it for Silverlight. If it stops working on Moonlight they're simply not going to care when it boils down to it. One of the things we're cooperating with Novell on with Moonlight is providing them test and validation suites that are used to test Silverlight internally. So, yes, we're absolutely doing work to make sure it's interoperable.
Silverlight runs in a sandbox, and sits on top of a platform abstraction layer; it doesn't provide direcct access to any native code APIs that would cause a concern like you describe.
For example, when in full screen mode there isn't full keyboard support, so there's no way to spoof a login dialog to grab a password.
Also, it's not the full.NET framework. It's mainly a portable subset, although it has some features beyond.NET 3.5, like the Media Element.
My only complaint is that I don't want tons of different boxes. That is part of the reason I stayed away from Tivo and waited for my cable provider to offer DVR in my cable box. I already have on demand movies and TV through my cable box.
I'm not sure why I should purchase a second box to add functionality I already have, despite the fact that this box would presumably offer a much larger library of content. This is the exact same library and the exact same encodes as their PC streaming service, so if you have a PC already hooked up to your display, you don't need another box. I don't know if that'd help in your case, but this isn't about NetFlix pushing another box; it's about them making a box available for those that the HTPC didn't work for.
'quality' (another semi-subjective term that could make someone go crazy and drive motorcycles across the country for the rest of their lives). And High Kudos for a germane "Zen and the Art of Motorcycle Maintenance" reference on Slashdot!
A book everyone should read, less than for the stated ideas of the author, but for the very useful parable about thinking too hard about unanswerable theoretical questions instead of just getting stuff done.
[blockquoteFixed. This isn't 1998, no modern web site should depend on a plugin for basic functionality.[/blockquote] Note that MLB.com is a video streaming service.
Unless you were expecting Animated GIF or something:).
...when I talk to people about adopting Silverlight, they always make the comment, "I already have so much Flash built into my web site, I don't know where to start with Silverlight." Well, the good news is you don't have to throw out the baby with the bath water. The fact of the matter is that you can begin to implement Silverlight where it makes sense in your web site without modifying or removing any of the Flash assets you already have in place. Silverlight will run just fine in a web page with Flash, so you can iteratively begin the process if implementing Silverlight and, if prudent, replacing Flash to take advantage of XAML, developer/designer collaboration, developing in managed code and all the other benefits Silverlight has to offer. No expensive and painful "big bang" replacement is necessary. Find a requirement for which Silverlight is a good fit and implement it. It's as simple as that.
The truth is, while the rest of the world would hold Microsoft to a higher standard than any other company, at the end of the day Microsoft works very much like the IT shops you probably work in. Each Microsoft product and web site has a team of developers and product managers that have a finite budget, timeline and resource pool in which to work. Believe me, if Silverlight could be deployed as a replacement to Flash across all Microsoft web sites next week, it would certainly make my job a hell of a lot easier, but that's not possible and difficult decisions have to be made in order to deliver a multitude of solutions currently underway on time and on budget.
I can all but guarantee you that there are roadmaps in place to adopt Silverlight across most or all of the Microsoft web assets. That adoption will be rolled-out in a manner that delivers value to the business and as it makes sense. You're seeing that adoption begin on Microsoft.com and MSDN, and should see it on more Microsoft sites in the coming months and years, a very timely example being the new Expression Suite web site, all built in Silverlight...
VP6 and VP7 don't even have B-frames. I'd say most of their interesting features are in the decoder size (aggressive deblocking, noise synthesis to hide artifact and add perceptual sharpness). Turn off the postprocessing features in VP6/7's DirectShow decoder, and it's quickly revealed as nothing special. And the encoder is SLOW; it's the last single-threaded codec of any significant use.
Sorenson Spark is the ancient H.263 codec, and so a predecessor to the still-ancient MPEG-4 Simple Profile. It's about as high end (and old) as MP3.
Sorenson Media has always shipped cross-platform Mac/Win products.
RealVideo 10 isn't bad for anime, but not really of much interest or use beyond that these days.
Yeah, fair point. I guess thinking in binary helps keep us to our assembly roots, but it really doesn't matter all that much anymore. I can't say why it's useful for file sizes at all.
Modern OS "Properties" dialogs almost all show the actual file size in byts for this reason.
Except "computing" isn't a clear-cut domain. For example, in my field of compression. Does that count as "computing" (power of 2) or telecommunications (power of 10)? Unclear?
So, we had a problem where different tools and formats defined it different ways. For a number of years, QuickTime used K=1024, while Windows Media and RealMedia used K=1000. Unless you were using Sorenson Squeeze, which "corrected" its Windows Media and RealMedia values by 1.024 so they matched the QuickTime files sizes!
Horrible.
Fortunately, the compression world has standardized on power-of-10 numbers, since that's what the MPEG standards and, well, all the professionals use.
So, now we have to do with complainsts about the mismatch between encoding a file that should be "4 GB" but doesn't fill up "4 GB" of drive space...
Sorry, 1024's got to be a KiB. No other feasible solution at this point, unless we decide to stop having computers talk to each other...
We shouldn't forget the welcome side-effects of accessibility requirements; they can often offer positive benefits well beyond their original target audience.
Take the Americans with Disabilities Act. Among other things, stuff gets wheelchair accessible. Which also makes them stroller accessible! Traveling with a young kid in Europe is much, much harder than it is here, since all the work to make things work for wheelchairs also works with strollers. Moving equipment around on carts is also a lot easier.
We can get similar effects with metadata. In SIlverlight, we're doing a lot of work for it to support accessibility, both for screen readers and for captioning of audio assets. It turns out that infrastructure metadata is enormously useful for searchability and indexing. Getting a nicely transcribed text stream into media assets enables a whole lot of cool stuff, like being able to automatically build menus and transcripts. And being able to search for, and seek to, keywords.
Well, I think we're in agreement that the current semi-private insurance model isn't doing a good real-world job of reducing costs. I guess it's becuase we're not going to have a real liquid market, since drugs aren't really commiditized until they're generic.
Given the uniqueness of health-care, a fully market-based solution seems implausible. So the question is what's the right way to run it.
Well, I was just making a joke, but you're making some interesting points there I'll respond to.
Certainly, there are huge costs to providing high quality medical care no matter the delivery mechanism. But we also see a big differential between the cost of delivering medical care in the USA and single payer countries.
You suggest this is because a much bigger portion of our medical costs goes to R&D for drugs and other stuff. Could be true, but it seems like we could be able to quantify it, and better yet, fund them differently. We already know how to fund medical research in this country as a seperate budget item; no reason we couldn't fund each sepertely to track the real cost of health care delivery.
The cost differential between our system and other countries comparied to the differential in outcomes is so huge I can't imagine it wouldn't be cheaper to just fund R&D directly than indirectly through higher costs.
Slashdot Mirror
But YouTube is only like 315 Kbps per Wikipedia http://en.wikipedia.org/wiki/Youtube#Video_format. Are there any suggestions that bitrate is being throttled down THAT much? Also, it's progressive download via http, not any kind of streaming protocol.
:).
Ah, 300 Kbps H.263 + mono 22 KHz MP3. Just like web video I was making a decade ago
Like I said above, that particular problem is actually pretty easy to fix, like we're doing in IIS 7 Media Pack. I'm sure other web servers will do the same thing eventually.
Now, in the big picture, the usage models between progressive download over http and streaming over UDP are going away pretty quickly. With byterange seek, you can do random access in progressive download now, and with server-side bitrate throttling you can avoid the problem of a user on a fast connection pulling down bits at 20x real time.
By example, the IIS Media Pack: http://www.iis.net/default.aspx?tabid=22
Now the one thing that's only possible with streaming is live broadcasting.
That said, I think the original article is rather misguided; nearly all streaming today is 3 Mbps or less, and most of it is less than 1000 Kbps. They could be doing a LOT of bandwidth capping and streaming would still work pretty well. The big limit for streaming is really all those people with 1.5 Mbps DSL lines, especially since in a modern household, that 1.5 Mbps can be split between lots of people and applications.
I work on the SIlverlight team (on the media side): on10.net/blogs/benwagg/
Really, that Ruby on Rails works in Silverlight is more a nice testament to the flexibility of the Dynamic Language Runtime in Silverlight than any big strategy on our part. Silverlight is an extremely flexible platform, and people can do all kinds of interesting things with it that we never thought of. I expect that the bulk of code written for Silverlight 2 and later will be in C#. But I'm always happy to see the new stuff people are coming up with inside Silverlight.
I think a lot of people start out thinking of it as "just another media player plugin" but the power of fast runtime is opening up a whole lot of neat stuff. I can't wait for 8/8/8 and NBC's Olympics coverage to start. I think it'll really raise the bar for what video on the web should be from both a quality and an interactivity perspective.
Anyway, Silverlight 2 Beta 2 and its associated SDK just launched today as well, for anyone interesting in playing around with it. https://www.microsoft.com/downloads/details.aspx?FamilyID=ba7b510d-0646-4d06-9834-cb82d669872a&displaylang=en
Hmm. URL didn't work. Trying again.
http://slashdot.org/article.pl?sid=05/08/02/2219208
Which is supposed to come out as: http://slashdot.org/article.pl?sid=05/08/02/2219208
Well, if you're willing to believe what you read on Slashdot:
MPEG4 enables better quality video to be compressed much more, making the movie advertisement much cheaper and making HD video a possibility. So without this, a loss to the companies. Eminently sufficient inducement for MPEG4 to be created without patents. Because lots of companies that aren't big CE vendors have a lot of very useful IP for codecs. Plus the CE vendors are perfectly happy to continue to get patent licensing revenue. As the DVD market has moved to about 95% "made in China" the patent licensing has provided substantial ongoing revenue for the companies who originally created the DVD market, but have since been priced out of it. Blu-ray can be very much viewed as an attempt to both reset the patent clock on high-volume CE to keep that revenue going as the MPEG-2 and DVD patents expire, and to provide something with a high barrier to entry for the Chinese companies to manufacture. Of course, the latter means prices stay high, so while it might help the big Japanese electronics companies, it isn't doing anything for Hollywood.
Anyway, that's another rant
To flip it around another way, yes, the CE vendors could have built a royalty free codec in partnership. But that would be a big expensive effort, and excluding patents from companies who would insist on being paid would make for a weaker codec. The codec licensing fees are pretty reasonable, and it made more financial sense to work with the big standardized codecs of MPEG-2, H.264, and VC-1.
Because Silverlight is self contained, and has no way to call external native code. It has no idea what if any version of .NET is installed. Same with codecs; those are all baked into the runtime, with no dependency on the native codecs available on the system.
Windows Media Audio 10 Pro and HE AAC both outperform Vorbis dramatically at lower bitrates. You can get quite good audio fidelity at 48 Kbps with either.
The question is, then: "Does your Silverlight-based business application really need to use these pesky, patented, DRM-laced multimedia codecs?"
Which, in the vast majority of cases, is "probably not." Much of this kind of functionality can be had via calls to external (and FOSS) libraries A library can be FOSS, but that doesn't mean that there aren't patents involved.
Really, the sheer breadth and number of patents around video and audio codecs are pretty staggering. It's hard to imagine a competitive codec that was truly patent free; there certainly aren't any that exist. The current leading standardized codecs (with patent pools) outperform the best "patent free" codecs by at least a factor of 2. For video, we're talking about, what, H.263 and Theora, and Vorbis for audio? Those are mid-90's caliber.
A Silverlight app can be purely XAML (XML markup language) and JScript. That's all Silverlight 1.0 apps are. With Silverlight 2.0 you can use bytecode, but that's not required.
Silverlight runs in a sandbox, and sits on top of a platform abstraction layer; it doesn't provide direcct access to any native code APIs that would cause a concern like you describe.
.NET framework. It's mainly a portable subset, although it has some features beyond .NET 3.5, like the Media Element.
For example, when in full screen mode there isn't full keyboard support, so there's no way to spoof a login dialog to grab a password.
Also, it's not the full
I'm not sure why I should purchase a second box to add functionality I already have, despite the fact that this box would presumably offer a much larger library of content. This is the exact same library and the exact same encodes as their PC streaming service, so if you have a PC already hooked up to your display, you don't need another box. I don't know if that'd help in your case, but this isn't about NetFlix pushing another box; it's about them making a box available for those that the HTPC didn't work for.
A book everyone should read, less than for the stated ideas of the author, but for the very useful parable about thinking too hard about unanswerable theoretical questions instead of just getting stuff done.
For real designer-style design of WPF/Silverlight apps, you want to be using the Expression Studio instead (particularly Design and Blend).
[blockquoteFixed. This isn't 1998, no modern web site should depend on a plugin for basic functionality.[/blockquote]
:).
Note that MLB.com is a video streaming service.
Unless you were expecting Animated GIF or something
http://blog.dennyboynton.com/post/Why-is-Microsoft-So-Slow-to-Adopt-Silverlight.aspx
VP6 and VP7 don't even have B-frames. I'd say most of their interesting features are in the decoder size (aggressive deblocking, noise synthesis to hide artifact and add perceptual sharpness). Turn off the postprocessing features in VP6/7's DirectShow decoder, and it's quickly revealed as nothing special. And the encoder is SLOW; it's the last single-threaded codec of any significant use.
Sorenson Spark is the ancient H.263 codec, and so a predecessor to the still-ancient MPEG-4 Simple Profile. It's about as high end (and old) as MP3.
Sorenson Media has always shipped cross-platform Mac/Win products.
RealVideo 10 isn't bad for anime, but not really of much interest or use beyond that these days.
Yeah, fair point. I guess thinking in binary helps keep us to our assembly roots, but it really doesn't matter all that much anymore. I can't say why it's useful for file sizes at all.
Modern OS "Properties" dialogs almost all show the actual file size in byts for this reason.
Except "computing" isn't a clear-cut domain. For example, in my field of compression. Does that count as "computing" (power of 2) or telecommunications (power of 10)? Unclear?
So, we had a problem where different tools and formats defined it different ways. For a number of years, QuickTime used K=1024, while Windows Media and RealMedia used K=1000. Unless you were using Sorenson Squeeze, which "corrected" its Windows Media and RealMedia values by 1.024 so they matched the QuickTime files sizes!
Horrible.
Fortunately, the compression world has standardized on power-of-10 numbers, since that's what the MPEG standards and, well, all the professionals use.
So, now we have to do with complainsts about the mismatch between encoding a file that should be "4 GB" but doesn't fill up "4 GB" of drive space...
Sorry, 1024's got to be a KiB. No other feasible solution at this point, unless we decide to stop having computers talk to each other...
We shouldn't forget the welcome side-effects of accessibility requirements; they can often offer positive benefits well beyond their original target audience.
Take the Americans with Disabilities Act. Among other things, stuff gets wheelchair accessible. Which also makes them stroller accessible! Traveling with a young kid in Europe is much, much harder than it is here, since all the work to make things work for wheelchairs also works with strollers. Moving equipment around on carts is also a lot easier.
We can get similar effects with metadata. In SIlverlight, we're doing a lot of work for it to support accessibility, both for screen readers and for captioning of audio assets. It turns out that infrastructure metadata is enormously useful for searchability and indexing. Getting a nicely transcribed text stream into media assets enables a whole lot of cool stuff, like being able to automatically build menus and transcripts. And being able to search for, and seek to, keywords.
Well, I think we're in agreement that the current semi-private insurance model isn't doing a good real-world job of reducing costs. I guess it's becuase we're not going to have a real liquid market, since drugs aren't really commiditized until they're generic.
Given the uniqueness of health-care, a fully market-based solution seems implausible. So the question is what's the right way to run it.
Well, I was just making a joke, but you're making some interesting points there I'll respond to.
Certainly, there are huge costs to providing high quality medical care no matter the delivery mechanism. But we also see a big differential between the cost of delivering medical care in the USA and single payer countries.
You suggest this is because a much bigger portion of our medical costs goes to R&D for drugs and other stuff. Could be true, but it seems like we could be able to quantify it, and better yet, fund them differently. We already know how to fund medical research in this country as a seperate budget item; no reason we couldn't fund each sepertely to track the real cost of health care delivery.
The cost differential between our system and other countries comparied to the differential in outcomes is so huge I can't imagine it wouldn't be cheaper to just fund R&D directly than indirectly through higher costs.