Silverlight for screencasters

I’ve been doing some experiments to find out how the Silverlight plug-in will work as a player for screencasts. On this test page you’ll find four different versions of a 23-second clip. There’s one for Quicktime, one for Windows Media, one for Flash, and one for Silverlight.

Some important variables, from a screencaster’s perspective, are: legibility, file size, and convenience of production, deployment, and viewing.

That legibility matters seems obvious, but I see an awful lot of screencasts delivered at squinty resolutions. This puzzles me. The purpose of a screencast is to show and describe on-screen action. If you can’t read the screen, what’s the point?

All four of these examples are legible. The Quicktime version achieves the best clarity, but there’s a tradeoff: it’s also the largest file.

That size matters is perhaps less obvious to those of us living in the developed world. But as I’ve been recently reminded by both Beth Kanter and Barbara Aronson, much of the world remains bandwidth-challenged. Videos that don’t squeeze themselves down will not be seen in many places where they should be.

Among these four examples, Windows Media weighs in lightest at under half a megabyte. That works out to about a megabyte per minute, which is the target I like to shoot for. If it’s possible to deliver a legible screencast at a data rate significantly less then that, I’d like to know how.

The sizes of the other versions in this example, in ascending order: Flash 1.2MB, Silverlight 1.5MB, Quicktime 2MB.

Of course these sizes depend on which encoder is used, and on which settings are applied. For these tests, I produced all of the screencasts in Camtasia. For Quicktime and Windows Media, Camtasia uses the encoders that come with those platforms. For Flash, it supplies an encoder. For Silverlight, it doesn’t yet supply an encoder so I produced an uncompressed AVI and then used Expression Encoder to create a Silverlight-compatible WMV file.

I should add here that, despite all the work I’ve done in this area, I’m still a bit vague on the concept of a screen encoder — that is, a video encoder that’s tuned for the kinds of low-motion but text-rich content that’s typical of screencasts. In beta versions of Silverlight and Expression Encoder, for example, there wasn’t a screen video option, so the only way to produce a legible screencast was to crank up a motion-video encoder to the maximum data rate, which produced a massive file. Now Expression Encoder provides a screen encoding option, which I used for this test and which Silverlight 1.0 can obviously play back.

It seems to me that Camtasia should be able to use that encoder directly, but until I figure out how, it will be less convenient to produce Silverlight screencasts from Camtasia than to produce the other formats. Rendering to AVI as an intermediate step is doable, but time-consuming.

In terms of deployment convenience, one measure is the number of supporting HTML, JavaScript, configuration, and other files required in order to play a screencast. I’m a minimalist, so when I deploy Camtasia screencasts I throw away the wrappers that Camtasia generates and go with the Simplest Thing That Could Possibly Work. From my perspective, that winds up being an OBJECT tag (and, sigh, also an EMBED tag) for Quicktime or Windows Media, plus a reference to a minimal player in the case of Flash. By comparison, my Expression-generated Silverlight example has lots of moving parts — an HTML file, a XAML file, a flock of JavaScript files, and the WMV file.

The Silverlight example could of course be simplified by coalescing the JavaScript support, but that alone won’t solve another issue of deployment convenience. It’s nice to be able to embed a screencast in any arbitrary web host. From the perspective of my WordPress.com blog, that’s an issue for all four of these approaches. WordPress is always coming up with new ways to embed video from various services, but the reason that’s necessary is that WordPress.com — quite rationally — strips out most of the advanced HTML tags and JavaScript support that you might want to include in your blog postings. In general, embedded video seems to be a game of point solutions. In order to embed video flavor X in web host Y you need a specific X+Y adapter. I understand the reasons why, but it’s frustrating.

One of those adapters, by the way, will be needed for WordPress.com and Silverlight Streaming, which is the Microsoft hosting service announced at the MIX conference earlier this year. I’ve hosted another version of my Silverlight example there. It’s the same set of files as this example, minus the HTML wrapper and the core Silverlight JavaScript code, plus an XML manifest, all packaged up in a zip file. I’m not expecting my little test to attract millions of viewers, but if I were, this hosting service would be one way to handle the load.

In terms of viewing convenience, the Silverlight example exhibits a nice property that I wasn’t expecting. When you resize the window containing the player, the player scales to fit. I’m pretty sure the embeddable Quicktime and Windows Media players can’t do that. Flash-based media players are more customizable, and can respond to container resize events, but I don’t think I’ve ever seen the technique applied to a screencast. It’s a nice idea. A screencast at 1:1 resolution is guaranteed to be legible, but will also consume a lot of screen real estate. So it’s tempting to shrink its width and height in production. But by how much? Any fixed resolution will work well for some people and not others. Resizable screencasts would be great for accessibility.

Of course you can resize any standalone player. So this issue boils down to what’s possible when the player is embedded in a web page. And as we’ve seen, embedding can be problematic. In general, we need to work toward a smoother transition between embedded and standalone viewing experiences.

The ultimate test of viewing convenience is, of course: Does it play instantly, regardless of the operating system or browser I happen to be using? Flash leads the way in that regard. Silverlight aspires to the same level of plug-in ubiquity, and with the announcement of Moonlight that aspiration seems achievable.

Ultimately a screencaster wants to be able to produce one video that works well for everyone, everywhere, for various definitions of works well. That’s a hard problem. Solutions depend on the raw capabilities of media players, it’s true. But they also depend on an ecosystem of plug-ins, browsers, encoders, operating systems, and hosting services.

9 thoughts on “Silverlight for screencasters

  1. Holmes

    MSFT’s browses are losing market share every day. They can built Silverlight into IE, but the IE world continues to shrink. Next year, Firefox will overtake any individual IE browser for market share. Will IE have even 50% market share in 3-5 years? I’m skeptical. From a user’s perspective, Silverlight doesnt’ seem to offer any advantages.

    Reply
  2. Jon Udell Post author

    “Will IE have even 50% market share in 3-5 years?”

    Note that there is no IE requirement. Silverlight works with IE, Firefox, and Safari on Windows and Mac. If the Mono-based Moonlight pans out, it’ll do the same on Linux.

    Reply
  3. John C. Welch

    What is Microsoft doing so that I can trust that the current support for !IE !Windows isn’t just a 1.x – only push? Face it, outside of the Mac BU, Microsoft’s big cross platform initiatives have either not survived the beta, (x-platform active x, IE for Unix), become Windows only after 1.X (Rotor), or been a glorious combination of a horrible application that offered crippled support for !Windows, and was knifed at the first opportunity, (Windows Media Player for Macintosh).

    I agree that Silverlight is neat, but with the rather inane things coming out of the mouth of Ballmer with regard to non-windows users over the last few years, the delta on Moonlight, and the history of Microsoft towards such things, *why* would I go with Silverlight, and a Windows – only set of dev tools instead of an open standard like MPEG 4? Even Flash is more open than Silverlight is, and while Adobe does some pretty stupid stuff, vaguely threatening potential users with lawsuits hasn’t been one of them.

    The tech is only part of the package.

    Reply
  4. Jon Udell Post author

    “What is Microsoft doing so that I can trust that the current support for !IE !Windows isn’t just a 1.x – only push?”

    To flip that around, what /could/ Microsoft do in the short run to earn your trust? Realistically, perhaps nothing. Sounds like you’d need to see the initiative prove out over time, and maybe also see the Mono/Moonlight story play out successfully over time. Is that true?

    Reply
  5. John C. Welch

    Oh no, there’s quite a few things they can do.

    1) Directly support Linux as fully as they do the Mac OS. Yes, the Mono team will do a good job, but that is an additional delta to deal with every time there’s a new version on Windows, and it’s not like the Mono team is getting paid. I’m sure that the Silverlight team is helping the Mono team out, but it creates a perception, not helped by Ballmer’s big mouth, that Linux is not considered a full player in the Silverlight ecology.

    2) Make it easier to host Silverlight content on !Windows servers. That means the ability to host Silverlight without any Windows servers whatsoever. The idea here is to make it as easy as possible to adopt the technology with as little risk as possible. So, open source the code for hosting Silverlight ala Darwin Streaming server. It can’t hurt the bottom line any more than the Xbox team is doing, and it will create considerable good will that Microsoft desparately needs. None of this stupid Shared Source license. Use a BSD license. It’s simpler and more free than the GPL, and far less onerous.

    3) Stop hoarding the dev tools. Write Eclipse plugins, Xcode plugins, whatever. Make it so that it’s stinkin’ easy to create and deploy Silverlight content on every platform everywhere, and without the dodge of “Well, you can just write XAML in a text editor. That’s inane and we all know it.

    Microsoft wants !Windows people to buy into this idea then we need more than a plugin.

    Reply
  6. Angel

    Hi Jon,
    Really i didn’t understand about the silver light even i don’t have so much of time to read every thing. If you don’t mind can you explain in simpler words & in short form because i am in a search of the best web hosting & designs.or can you provide something which will be useful for me.

    Reply
  7. Jon Udell Post author

    “does this mean Camtasia now does what you’d hoped?”

    The original v5 beta did not, I don’t think, but sounds like it will now, I’ll update and see.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s