Review: StreamCity Magic Publisher

Magic Publisher is an online video platform (OVP) provided by StreamCity that costs £495 (about $812 U.S.) per year, plus £500 (about $820 U.S.) per terabyte of delivered video data. Though it lacks many of the features required by high-end streaming producers, such as syndication and advertising server support, its feature set and usability are perfect for most smaller shops.

Overview and Workflow

I’ll detail operation of the platform, but I want to start by providing a high-level workflow. As with most OVPs, you upload your video files to the service and then create a player. Next, you create a “campaign” by choosing a player and one or more videos, then publish and track the campaign through the Magic Publisher reporting system. So you upload your videos, choose a player and create a campaign, and then deploy the campaign via the typical embed codes enabled by all OVP and user-generated content (UGC) sites.
Now let’s dig deeper into each of those operations.

Uploading and Encoding

Magic Publisher is a Flash-based system only—no Silverlight, Windows Media, or QuickTime, which is typical of OVPs. The only currently supported Flash codec is VP6, though H.264 should be available by the end of 2009.

You can upload your files in two ways. If you’ve already encoded your file into the FLV format, you can upload it directly. Or if you want StreamCity to encode your file for you, you can drag and drop the raw file in most relevant formats onto the Encode/Upload window shown in Figure 1.

Figure 1. Client-side encoding interface: very few parameters but certainly easy to use

As you can see in Figure 1, the only parameters that you can adjust are resolution and aspect ratio. This will give comfort to newbies who care about little else, and advanced users can encode in their own tools before uploading. To perform this client-side encoding, StreamCity downloads and installs an Active X control for Internet Explorer and plug-ins for Firefox and Safari. On the Mac, note that you can only use the Safari web browser for client-side encoding. On my 3.2 GHz quad-core HP Z40-0 workstation, which was running 64-bit Windows XP with 6GB of RAM, client-side encoding was slightly faster than real time, with a 4:45 (min:sec) file encoding in 3:45.

Whatever approach you take, you can only upload one video at a time—heck, even YouTube lets you upload multiple videos in sequence. If you’re in a hurry to get your video uploaded, this will be a major frustration.

Player Creation

Once you upload your videos, it’s time to create a player (Figure 2). Here, your options are limited to choosing background and foreground colours and choosing which options (such as Full Screen view, Tool Tips, Share, and the like) will appear on the player. For example, if you don’t want other websites to be able to embed your videos, you would leave off the Share option.

Figure 2. Choosing player options: again, relatively few parameters but easy to use

The size of your player window is determined by the first video that you load into your campaign. For example, if your first video is 640x360 (as was the case in both my campaigns), that’s the player size. Add a video smaller than that (say 320x240) to the campaign, and it’s stretched to fit the player—I would have liked the option to letterbox the smaller videos rather than stretch and distort them.

In addition, a better approach is to let the web producer specify the resolution of the player directly rather than using the resolution of the first uploaded video. My primary website, www.streaminglearning center.com, (shameless plug)uses a column size of 500 pixels. When I added the campaign to my test page, the player hung over the edge, obscuring some menu text and other design elements. The UGC site that I use, Vimeo, lets me set the player size to whatever width I need, which ends up looking much tidier.

Why not encode to 500 pixels wide and be done with it? There are several reasons. First, codecs work most efficiently in 16x16 blocks, and 500 isn’t divisible by 16. Second, I like using a 640x360 encoding size because it provides more resolution should the viewer scale the video to full screen. Thirdly, most of my videos are screen cams produced at 640x480, so using a 500 pixel output resolution would distort the text and other interface elements. Not to make a thesis out of this point, but your player should be easily adaptable to fit your webpage design, and you shouldn’t have to adjust the resolution of your streaming video file to do so.

Free

for qualified subscribers

Subscribe Now Current Issue Past Issues