Ever since September 10, I've been quite excited about the announcment that Adobe was finally releasing an encoding server solution called Flash Media Encoding Server.  I was able to secure a pre-release version through work to take it for a test drive.

Initial results were great.  Of course, being a pre-release, there were several challenges.  The first being that the software required a USB drive for a USB key.  In a time when virtualization is sweeping the corporate world in an effort to reduce costs, the requirement for something as simple as a physical USB port was very irritating.  We overcame that with a hardware/software solution, not the most desirable (spending money just for trial software), but oh well. 

The next challenage was the documentation, or rather, the lack thereof.  Yes, the basic steps for installing the software were included, as well as the basic steps for setting up watch folders.  One of the big features I was anxious to test, though, was the SDK.  Surprise, surprise.  No SDK documentation.  We're hoping to put FMES (or some transcoding agent) in the front of our video asset management workflow to generate proxies of video assets for review within out applications.  Most of our applications are homegrown and based on Adobe technologies (ColdFusion, Flash/Flex, AIR, etc).  So the ability to leverage a transcoding solution via SDK is a vital element.

Aside from the lack of documenation with the pre-release trial, I did find that several of the source files I tried to run through FMES couldn't be encoded.  Ok so they were odd codecs (WMV3, muxed mpeg, etc), but still.  The error messages gave me little to go on besides the error message, "There is a video decoding error."  Using some other transcoding tools, I was able to encode the problem files, however, so why couldn't FMES process them?

Finally, my biggest surprise is that in testing FMES, I discovered that at its core, it's really a product by Rhozet called Carbon Coder.  After a little quick digging, I discovered this press release indicating Adobe's intentions.  It seems to me that, basically, Adobe has taken Rhozet's product, swapped out the words "Rhozet Carbon Coder" with "Adobe Flash Media Encoding Server" and limited the outputs to only those that are compatible with Flash.  The licensing model is slightly different than Rhozet's, however, it is more or less the same product.

At this point, I'm trying to decide why we would want to go with FMES over Carbon Coder.  If we're going to spend several thousand dollars to a transcoding solution, why not spend a few more and not be limited to only Flash-enabled media outputs?

Now that FMES is available for purchase, Adobe will have more documentation or white papers available that can make a good argument, in addition to not choking on certain input formats.  Granted, video transcoding experts can probably explain why some of these problems exist and how to solve or get around them, but for a product that seems as if it should be a turnkey solution from Adobe, I would have hoped my intermediate skills in working with video transcoding should be more than enough to work with FMES. 

More to follow in the coming weeks, I'm sure...

I added a few pictures from my Washington vacation with my fiancee to my photos page.  Photos are of Arbor Crest Winery, Spokane Falls, St. Aloysius at Gonzaga, Wanapum Lake, mountain ranges, and Snoqualmie Falls.

On my last trip out to LA for work, I spent some time on the plane brainstorming on the data model and abstraction for gpuds.  I basically want to take the core feature set in the current incarnation of gpuds and abstract it into a "real" ColdFusion application.

I'm starting to realize that most of the ColdFusion development I've done in my career, starting back with CF 4.5 (I think), hasn't really evolved with the evolution of ColdFusion itself.  I'm still writing html/page based apps that require a lot of tedious maintenance and aren't very scalable.  In working more and more with BlogCFC and Mango Blog, I'm realizing some of benefits of CF 7 and 8. 

I think that I knew all along, in theory, how great CFMX was, but never from a practical perspective until I started working on the gpuds framework.  I can't even remember when CFCs were introduced, but aside from facilitating communication from the Flash player to the server, I think I've really been ignorant on why they are so important.

I don't think my applications were ever bad, but they could have been better.  The nature of ColdFusion as a Rapid Application Development platform is what perpetuated my continual use of less-than-efficient application design.  My applications worked and I could crank them out quickly, so why would I bother with any other approach or even framework?

I also think the fact that I'm doing much less development now and more project management is why I'm able to see these things.  I always had a deadline or projects piling up, leaving little time for analysis or post-mortem.  Now that I see these things from a different perspective, I can see all the shortcomings of my approach.

It's amazing to me that I've "discovered" all this in just the scope of working on my gpuds framework, especially considering that I've only just begun!

Ben Forta wrote a very interesting blog the other day about the newly created CFML Language Advisory Committee.  This post is great for two reasons.  One, it outlines how this new committee will hopefully benefit CFML in and amongst the ColdFusion community in the long run.  Two, he comments on how and why opening a language up to a community can impact that community in both positive and negative ways, not just on CFML. 

A great read for any developer.

Although I was excited each time a new version of Flex and AIR were available on the Adobe Labs site, I am really excited about Adobe's new AIR/Create Suite project, SwitchBoard.

At work, I'm involved a lot with our Digital Asset Management projects.  Our company deals a lot with high-volume photo shoots.  In almost every aspect of the creative workflow in regards to digital photography, our employees use Adobe products to manage, manipulate and edit our assets.

While we do have a large and expensive Digital Asset Management system in place, we constantly find ourselves writing custom applications to better facilitate the workflow amongst our photographers, image techs, photo editors and our legal staff. 

I think there is a lot of great potential with the announcement of SwitchBoard to really take our DAM applications to the next level!  I'm hoping to do some testing with it in the next couple of weeks to see how we can leverage SwitchBoard's features in our workflows.