by Jan Ozer
November 5, 2009
|
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
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
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.




