To add a linked library for a project
1. Right click the project in the Explorer pane of Eclipse
2. Click the FDT Source Folder
3. Click Add Linked Libraries
4. Add away and get a sandwich from Healthy CA

This is a simple issue to fix, but I'll point out how for the non power users.

1. Create a folder on your drive to be considered as your core actionscript lib (ex: C:\tools\flash\core_lib).

2. Copy the contents of FP8 folder and mx folder itself from your FDT install (ex: {ECLIPSE INSTALL}\configuration\com.powerflasher.fdt.core\.config\core\as2) to the core lib

3. In Eclipse go to your preferences > FDT > core libraries > as2 core libraries

4. Either edit the current core lib or add another one and point it to the lib you created

5. eat some snacks and get ready to code.

Hope this is of help to someone who might get confused with it.

The main bump was the usage of Akamai's authorization abilities. For those unfamiliar with this, Akamai offers the ability to only allow video plays with an auth token (aka you can't request video unless you know the secret password Charlie). The bump really was in how this is implemented by Akamai for VOD. Akamai does an auth on socket connection vs on stream request. This means when going from video to video, you are tearing down a connection each time. This is expensive and also causes delays for setting up and playing the stream. Worse, if you were wanting to switch streams (think high quality to low quality) on the fly, you would be starting over vs just switching and buffering. You aren't able to reuse the connection, which contrast to how typical implementations work, creating a branch in logic for this specific instance. Oddly, their live implementation works based on stream requests, so why not their VOD? Regardless it is easy to resolve, but not my cup of tea.

As we move towards FMS 3 and SWF verification (only allowing a specific SWF on a specific domain to make requests), I recommend moving away from auth towards this type of verification. The reasoning behind this, is that SWF verification could be transparent across CDNs, while the current auth implementation is very CDN specific. It also protects you from someone figuring out your auth keys.

All that said, it's nice to see that all of Cartoon Network's video players have now been migrated over to a more flexible format.

What are the Guts of Express Install?
First, how does Express Install work? It's pretty basic and not something a NASA engineer needs to look at. Essentially you are loading in a SWF from Adobe that then does all the work and tells you it's status. Your host swf needs to be at least 215 x 138 pixels and the option only works in players 6r65 and above. The SWF you are loading is located at

http://fpdownload.macromedia.com/pub/flashplayer/update/current/swf/autoUpdater.swf

This SWF is considered loaded when it's startUpdate function is defined. At that point, you can define MMplayerType, MMdoctitle, and redirectURL on it and call it's startUpdate function, and it will begin it's process. During this process it will report back to a function installStatus that you define on your root (with the following codes "Download.Complete", "Download.Cancelled", and "Download.Failed").

What are the options with Express Install?
Now you can handle this one of two ways, implementing the logic to do the update in your own application or use an updater swf that is a proxy or prerequisite for your application swf (when needed). If you were to go with the first option, you are baking the code to do the update in your application. AKA, bad choice because isn't that the whole point? Your application is using a version of the player that you need to update to. In previous AS1/AS2 cases the code is fine and could still run, but it's somewhat defeating the purpose. However, in the case of AS3, no chance to collect cash and get out of jail, you are stuck.

The proper Express Install
The proper way to do this is option 2, using a SWF whose sole purpose is to do the update. Luckily, about 99% of the web is using SWFObject (whether 1.* or 2) and this is built in for your comfort and joy. With both implementations (which use Javascript to embed a SWF), you just define your Express Install SWF and you are good to go. In addition, you are given the source of the SWF to manipulate if you are feeling fancy. What SWFObject then does is run through a series of steps based on the version of player you have installed.

1. Runs a JS detect to see if you have the version needed.
Yes, it writes out the content SWF.
No, is there an Express SWF and the player is above 6r65
No, write out Alternative content

2. Yes, embed Express SWF, which then runs through it's process
Express SWF is successful, it calls back to the JS

3. JS writes out the content SWF

Summary
Ok, so all that said, let's summarize. Key point, SWFObject does everything you need to do. If you want to implement it yourself, just implement the same logic that SWFObject uses. SWFObject uses a separate SWF which is published as AS2 and can be used in previous players. You don't embed any Express Install logic in your app and just let the installer SWF handle the magic for you. It has the logic which can step into your content once it is done. Hope this help with anyone that may be confused by this process.

Democrate Delegates
Republican Delegates

The module allows you to view a graphical representation of the delegate "race" between candidates for either party. I'm pretty big on usability and information display, and I think it was a little tricky from an informational standpoint, since the way delegates are gained, lost, and solidified over time. In order to make it clear to the user, only the delegates that were considered solid were used as plot points. The "unsure" delegates are listed in the mouse overs. So overall I think the information is decently portrayed.

In retrospect, one criticism I have is the iconography used. All of the candidates are represented by their parties mascot (donkey or elephant). This doesn't make sense unless you are comparing 2 entities of different parties. A better icon for the graph would have been an image of the candidate, since they are the entity that is physically in the race. Another criticism is the actual style guide of interface elements (up, over, disabled states). Needless to say, the designer working on the project had an issue with it too. A lot of the elements look disabled when they are selected, enabled when disabled, etc. All that said, I think the module turned out great, but I think the taste is sometimes when all the details match up.

One thing we did do to jazz up the module with a bit of flair was to add the ability to scale the graph and animating the icons from point to point. Like with design, it's sometimes the little things that make and application more pleasurable and fun to use.

Check it out, let me know what you think, and remember to pay attention to the details on your projects, it all adds up.

Watch the Demo

At NAB (national association of broadcasters) this week, Akamai and NBA.com are showing off a live video app that Dreamsocket developed for the Final Four. The application they are showing is basic, a video mosaic that allows you switch camera feeds during the live event by clicking sections of the mosaic or buttons. I developed that app in a blink, but what I'd really like to show is the prototype. The prototype actually used a single mosaic feed, which it spliced and then blitted to the screen.

So what do I mean by blitting video? For those not familiar with the concept, instead of letting the video just "show" on the screen, you actually capture the video and cut sections of it and then render them where and how you want them. In the case of the NBA mosaic, the mosaic video was a single video that had 4 different views in it. The broadcaster combined all 4 into the same picture and broadcast that video (you see this in the news sometimes). When I received the video, before I "showed" it, I cut it up and then placed it into pieces I wanted. What this allowed me to do is have the mosaic be 4 interactive elements that the user could zoom in and out of them in real time. Since I could have as many duplicates of the video parts that I wanted, I was able to use each video section in the actual buttons as well. This gave real time views of each section.

So technically and visually, the concept is pretty cool. However, it is interesting that it has some actual benefits as well. You can't achieve the interactivity another way without opening all 4 feeds at once, which is expensive on the server, the bandwidth, and client machine (aka not feasible). By opening a single feed, you are consuming only the bandwidth for one stream, you are never hit with the delay of switching a stream, your feeds are never out of sync, and you have full control over manipulating the entire mosaic.

Are there downfalls? Yes, there are. For one, this is only possible with video whose rights you have to script. In the case of using FMS, you need FMS3 and the server must allow you to capture the video's pixels in it's application script (p_client.videoSampleAccess = "/";) or via it's configuration. The other downfall is that because you have 4 videos in one, each individual video's quality is a lower because your are zooming a smaller space.

All that said, this is an interesting concept that has a lot of different ways you could take it. Love to hear people's thoughts and ideas.

The major additional feature that we added was related videos to a video's detail section. When adding this, we actually didn't have a true "relateds" service, so I build it based on context. Essentially if you are browsing a section, you are looking at a video in context, so I grabbed those videos from that context. If you are deeplinking to a video, I request the first 'N' videos in that video's collection. It is a simple solution, but what I'd like to see is a more user driven symbolic relationship. Regardless, it works for now ;).  The great thing about the current setup, is that if you go into the What's new section or say Aqua Teen Hunger force, you will see all of the surrounding videos in your relateds, which allows you to select them without jumping back to browse. This also brings up another feature, continuous play.

Continuous play is tied somewhat tied to relateds and is what actually gives it worth. At first you might think it seems pretty lame, because you are using an ondemand application. However, what you have to realize is that the application is essentially keeping the related playlist in memory. This allows you to go fullscreen and just keep watching one item after another passively or jumping to next items manually. Also, if you find it annoying you can just toggle it off.

There are some other subtle changes, but I've bored you enough,  go check out the AquaTeen movie while they have it up!

If you want to test it yourself, just create a simple button called fullscreen_btn and add the following code to your fla (publish as Flash 9/AS2)