The HTML 5 video and audio tags are coming - it may be a long time before they get here, but when they finally do will there still be a need for Flash or Silverlight? Anything else besides video that they do can be done with Javascript. Will we still need them in five years?
2D/3D graphics... although there are pretty decent graphics libraries implemented using js they all pretty much rely on the canvas tag (not natively supported in IE, but only via 3rd party plugins like excanvas)
The <video> element doesn't feature any codec, which is a lot better than A) specifying the piece-of-shit Theora or B) specifying something worthwhile but 'encumbered'. The point is the DOM api for controlling playback from Javascript, not the codec implementation.
In practice everyone will support h264, because terrific implementations ship with OS X, Windows, and Ubuntu (at least once you check the "I am not gnutarded" box). If the BBC's Dirac project doesn't flame out, that could end up being a specifiable free codec. Theora is not remotely viable.
Windows XP does not ship with an h264 codec. It is actually quite difficult for a user to find an h264 codec for Windows if they want to playback videos.
Another issue with H.264 playback is the licensing costs. According to the mpegla website, after 31st December 2010 content producers will have to pay money just to stream content, let along decode or encode to H.264.
Windows 7 does ship with one, and it'll be a looooong time before <video> goes mainstream and gets supported in IE. Now that MS is dipping their toe into the h264 waters, it's plausible that they'd bundle h264+VC-1 support with the IE$X upgrade for older Windows.
The licensing regime is bound very tightly to the enforceability of software patents. It turns out that distributing source code doesn't constitute patent infringement -- it's a description of the invention, something that should be contained in the freely-distributable patent filing. Even then, you can always distribute binaries from countries where such patents are invalid.
Whether or not its a long time before (if ever) <video> goes mainstream doesn't matter. What matters is that an alternative to formats that require a payment is needed.
For people who want to use non-proprietary formats, or don't want to pay licensing fees for videos they provide. There should be a way for these people to use video on the web. Even if it remains only a niche usage, and at least provides some leverage to reduce the licensing costs of other formats.
According to the mpegla website, after 31st December 2010 content producers will have to pay money just to stream content, let along decode or encode to H.264.
AFAIK, Dec. 2010 is when the current licensing agreement expires and a new one is drawn up. They merely reserve the right to change the agreement to add a fee; they don't say that they will.
The summary of license terms are listed on the mpegla web site.
If you run a website where users pay to view h.264 videos, either by title or by subscription, you need to pays fees per video if you reach a certain number of viewers. Note that these fees are payable now, there is no grace period for this.
For streaming of videos where the end user does not pay (eg. YouTube style services) the terms state:
"In the case of Internet broadcast (AVC video that is delivered via the Worldwide Internet to an end user for which the End User does not pay remuneration for the right to receive or view, i.e., neither title-by-title nor subscription), there will be no royalty during the first term of the License (ending December 31, 2010), and after the first term the royalty shall be no more than the economic equivalent of royalties payable during the same time for free television."
Free internet streaming is therefore covered by the grace period, but lists the payments required after that as being no more than the equivalent of that for free television - the costs of which are listed in the document.
So it seems that in some cases (subscription video) you do in fact have to pay fees now.
And in the free internet streaming cases the wording does suggest there will be a cost. It is certainly possible they could decide to make such usage free. This is far more likely to happen, imho, if there are alternatives to h.264 to enable content producers to negotiate the fees with mpegla.
Currently if you are streaming h.264 on your site, you're taking the gamble that mpegla won't want a cut of your profits post 2010.
The MPEGLA has always been extraordinarily unsuccessful at collecting the license fees they think they're owed. The companies that pay in are generally ones that have patents in the portfolio, and thus get a payout right back again.
Refusing to pay the fee is certainly an option. I don't see it being very popular with people investing money in startups when they ask how the startup intends to handle patent licensing and the reply is something like "Oh, we've decided we'll refuse to pay and hope no legal action is taken, or ship parts of our software from various countries where we think it's not covered."
I doubt the video tag will support DRM or more advanced Flash features like dynamic streaming. Most sites don't need these features, but those that do will keep using Flash.
It's my understanding that the video tag will support arbitrary back-end video processors. There's no reason that the video stream cannot be encrypted with some DRM scheme that's decrypted by the backend. Please correct me if I'm wrong about this.
I think that's correct. The current draft specifies that an implementation (browser) may support any video codec or no codec at all (e.g. lynx). There's a lot going into the determination of which codec to use if more than one might be appropriate. As wmf mentioned about - DRM and dynamic streaming, I'm wondering the same but I think that can be handled by appropriate codecs. (Which may be just moving the plug-in issue to be one involving codecs, but let's hope popular browsers will ship with sufficiently useful ones.)
Bowman: You see several things. You see a high-grade product that's in some form on 99 percent of the browsers. You've got something that's got mass usage. Secondly you see with Adobe a company committed to the customer experience in video with the Flash Player. We see a partner that continues to invest in their product. They have the same desire that we do. They want the Flash Player to be the best thing anybody has ever seen and we want that. When you partner with people like that, it's not a philosophical discussion. We know where we want to be now how do we get there.
So once we filter out all the market-speak it pretty much boils down to that Flash has a better market-penetration.
Maybe. But as a paying MLB.tv customer, the Silverlight implementation was TERRIBLE. Despite having all year to make improvements, the thing never worked even remotely correctly. I scolded myself as I signed up this year, but there really aren't any other options. To my surprise, I started up the first game today (go Tribe), and couldn't believe how much the player improved. Judging by how many more (functioning) features and polish are in the Flash player than were in the Silverlight player, I suspect it wasn't just market penetration.
Adobe has more at stake in seeing Flash succeed than MS does in seeing Silverlight succeed. This may be reflected by the amount of Adobe support and development committed to the Flash platform. I'm sure the Silverlight team is way smaller.
This is a major point in favor of Flash. The adoption and expansion of Flash into the enterprise is critical to the future of Adobe. Thus, Adobe will continue to invest heavily on improving and expanding the Flash player, API, support and development tools.
Microsoft could drop Silverlight with little impact on the company -- it's not critical to the success of Windows at this point.
The single thread model has some serious limitations. For instance maybe you would like to load some images & then popup a component containing them. In a threaded world, you can have synchronous communication where it just waits till the download is complete before loading what depends on it. Right now you have to register callbacks, sure that's not too tough, but chaining like that makes it more difficult than it should be.
download -> componentA > componentB > ComponentC
whereas it might be easier to just go:
CompnentA(file.download());
instead of file.Download (CompACallback, FaultCallback);
Doubt it. My video experiences with the last Olympics and CBS NCAA coverage were pretty good. If the next Olympics and next year's NCAA drops Silverlight in favor of Flash, then you could say that it probably won't take off.
Flash has 5+ years headstart than Silverlight. Flash has also seen its share of technical issues and limitations.
With regards to penetration rate, most PCs come with Silverlight pre-installed so this won't be much of an issue in the future.
