I had been trying to get my environment set up to play with Adobe Alchemy, but kept running into problems with my Cygwin setup.  After several frustrating hours of installs, re-installs, uninstalls and some out-of-control Perl threads, I think I've got it ready to go.

The problems I was running into were largely due to two things: 1) The path of my home directory containing spaces ("C:\Documents and Settings\...") and 2) my inexperience with Cygwin.

In regards to #1 above, I think this was causing my home directory (/home/username) to not get created properly.  That meant additional difficulties in customing my environment by editing my .bashrc file.  After the initial learning curve and interpreting the less than specific Adobe Getting Started on Windows instructions for Alchemy, I was able to get the sample library compiled and working correctly.

I did run into a few other problems, but I was able to get through them.  I'll be doing a write up for getting started with Alchemy and Cygwin for Windows users with very little Unix experience when I get some more time.  Of course, now that I've got Cygwin running, I'm hoping to do try out something more significant than Hello World :)

My first thoughts on the Alchemy project were of doubt.  What would be the benefit of running C/C++ code on the AVM2?  It seemed more like a novelty, like running old school NES games on the Wii.  The more I started to think about it (and get past my bad memories of Computer Science C/C++ classes in college), the more I started to realize just how powerful this could be.  There are so many open source C/C++ libraries for a wide variety of applications that, when paired with Flash, could have an amazing impact on Flash and AIR.

I thought I would tinker with it a bit.  Of course, coming to the realization that Alchemy is still limited by the Flash player sandbox was a little disheartening, but I suppose understandable.  I found the initial download and setup quite cumbersome.  One of my biggest roadblocks was working with Cygwin.  I admit, that using Cygwin has its advantages, but configuration thus far has been a beast.  Additionally, the getting started section for Windows section left something to be desired in terms of details.  I'm the first to admit I'm no UNIX or Linux expert, but I'd like to think I know my way around a bit.

After a few hours of trying to just get my environment set up, something more important required my attention, so I have yet to get the provided examples working.  I hope to get back to this more in the next couple of weeks.  I've got a few open source C++ libraries I'd love to test out.  I'm extremely intrigued, but until I get my environment set up, I'm still skeptical.

Branden Hall has written a good overview of Alchemy.

I've ported a few free css templates to Mango Blog skins, but this is the first one I'm posting for public consumption :)  I used lotus flower from Free CSS Templates for my personal blog/website (picked by my wife, I have to add) and just swapped out the header image.

Download the skin and extract it to the "skins" directory in your Mango Blog installation.  Then just select it in the Mango Blog administration.  That's it!

One of my colleagues at Adobe MAX in San Francisco sent me a text message last night.  He was at the sneaks session and indicated that there was a preview of an Adobe product called Media Orchestrator.  This AIR application, in conjunction with existing products like Premiere and LiveCycle, will facilitate video production workflow, from production to review, feedback and rights application.

Considering that we have been spending most of our time lately at work trying to write a custom video asset management solution using Adobe products, this announcement is really bittersweet.  It's fantastic that Adobe is (or considering) releasing this as a product, however, it most likely won't be available any time soon and we need it right now.

More information and pictures on Serge Jespers and Andrew Shorten's blogs where they were live blogging the sneaks event.

can it be?

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...