Sti Media: The Source

Flash Lite and Alpha Transparent PNGs

I was recently working on a little Flash Lite (1.0) project targeted at DoCoMo 900/901 handsets and came across something odd with PNG files.

In the project I had a small animation created from an imported sequence of alpha transparent PNG files, which were exported from Swift 3D 4. After importing into Flash, everything looked fine, but I wanted to do some minor touch up work in Photoshop. After completing revisions and updating the library items in Flash, I exported the SWF (flash lite 1.0) and uploaded to our test server. While the animation appeared as expected on a PC, those "slides" I edited in PS displayed on the mobile phones with a black background.

At a loss for what was happening, I started to backtrack to figure out what was different in the edited files. Both were exported as PNG with alpha transparency. The difference was, by default Swift exports 32bit PNG files with alpha transparency, Photoshop only exports up to 24bit. I had not read anywhere in the Flash Lite (for DoCoMo) docs that this was an issue, but, I guess it is.

The fix was to open the PS exported PNG docs in Macromedia Fireworks and export as 32bit. Problem solved!

I'm not sure if this happens on any other devices that support Flash Lite, but hopefully it helps someone out of a bind.

Foma 901i with Flash Lite 1.1

NTT DoCoMo has announced the release of the 901i series of phones for their 3G FOMA service. The focus this time around seems to be on "3D" graphics and sound, but what I am most interetested in is the support for Flash Lite 1.1 (Which they are referring to as "Power-up Flash"..hehe). However, I will curb my enthusiasm until I find out if DoCoMo has managed to strip 1.1 of any of its useful features during their "port" of the player.

DoCoMo staggers the release of models in a series. The first is to hit the market here in Japan on December 1st.

Official 901i site (Japanese only)

English Press release

DVD to CD-ROM：FLV to the rescue!

Warning: This is a long post...so you might want to take the time to grab the beverage of your choice...

Overview

Last week I was working with a client who wanted to have a promotional DVD, which was created by another company, “converted” for distribution on CD-ROM. The DVD contained 5 promotional videos (chapters), plus short intro and exit titles, that formed a short story about the company’s B2B mobile services. They were to be distributed during events and the client wished to have a version for users who did not have a DVD drive. Each video was 3-5 minutes long, with the combined time being approx. 27 minutes.

NASA, we have a problem…

The initial project request was to convert the DVD menu to Flash and simply link it to QuickTime movies, one for each chapter. I really did not like this approach, as it seemed rather unsophisticated (I hate requiring the user to open up an external player for vid…). However, the timeframe for the project was pretty short and the budget was tight, so they shot down the all Flash idea when I brought it up, as I mentioned it could require additional time. The project had lost some of its appeal at this point, however it sounded simple enough, but a few issues came up after the client delivered the materials.

1. The first was that the DVD had a “loop” feature, which allowed the viewer to click a button and watch all 5 chapters in order. The only way this was going to happen with using external QuickTime files was to make one long video containing all the clips in order. When I brought this up they simply said the feature could be omitted from the CD. Easy enough solution…but I hate admitting defeat…after all, Flash can do anything….right?
2. The movie files were delivered on a DVD in QuickTime format (DV25 codec) and were 720x480 non square pixels. Each clip ranged from 600mb to 2 gigs. I didn’t consider this a problem, as it would just require some conversion; however the client specified that they desired videos to be 640x480 and still have a pretty clear picture and audio… After doing some conversion tests with multiple compression methods in Premiere, I quickly realized that this simply was not going to be feasible. I reduced the file dimensions a little, but he best result I would be able to get, while maintaining clear sound and a decent picture, was still going to be almost 2gig. Obviously not ideal for a 700mb cd-rom….. This combined with the fact that the client wanted to include the QuickTime installers for both Mac and PC was spelling disaster.

The Menu

If you do video conversion, you know it is not exactly a speedy process. From Premiere, one video was averaging 40min to an hour for full conversion. While I was doing the above mentioned compression tests, I went ahead and recreated the Chapter menu in Flash, using supplied PSD files. The original DVD menu was pretty boring. No animation to speak of, not even button rollovers. So, I setup the menu so that the title screen first played, displaying the name of the disk, and added some subtle rollover effects to the buttons. I also included an exit button that played the closing title sequence before quitting the presentation.

A solution and the pitch…

Once I had confirmed that the QuickTime approach was not going to work with the required specifications, I went ahead and did a test converting the shortest video to FLV, using Sorenson Squeeze 4. Up until this point, I had only really used FLV for online solutions, so I was not sure of the results I would get when converting for CD quality. Happily, the resulting file, at 640x480, was well under half the size of the same MOV (Only 30mb), and the picture and sound were still good, even when viewed fullscreen. The best part was the conversion process took far less time. 20-30min.

Armed with this information, I contacted the client to show them the menu and discuss an alternative method for video delivery. I once again suggested an all Flash solution in which the movies played within an FLV video player. But, this time around I had an example to show them. The “winning” points in swaying the clients decision were the following:

1. The end user did not need an external player application. This created less possible support issues, improved usability and increased chances the client would view the entire presentation.
2. The save in file size and not requiring the installers allowed the video and sound to be compressed at higher quality.
3. It was going to take less time to convert to FLV than it was QuickTime, which made-up for the extra development time in Flash.
4. The loop feature could be reinstated if using Flash.

With both sides happy, I went back and planned what changes needed to be made to the interface. I integrated the FLV player, added a “back” button to return to the menu and added the loop button to the menu, with t he necessary scripting (Detect what video was playing, if it was finished and which to load next).

Conversion to FLV and Sorenson Squeeze 4…Not totally smooth…

I would like to say converting everything to FLV was simple, but…..
We had previously documented the issue with Meta data. Below are some problems I experienced with Squeeze during the project.

1. Squeeze 4 is NOT Multilingual friendly. (Read: If you are not on an English OS, or one that only uses the roman alphabet, you could have problems).

   I had previously found that Squeeze would not successfully export if the path for the destination folder had any directories using 2byte characters (Japanese in this case) in the name. This time around I found that it will also not successfully import files from those directories as well. To make things worse, the error message you receive states that it failed because the file format was unsupported… You can imagine my frustration when this happened while attempting to import an MOV file that had been compressed using the Sorenson codec….

2. Initially my FLV files would not play at all. I was not a happy camper. With some more experimenting, I found that the problem went away if the Audio codec was changed from Fraunhofer MP3 to Uncompressed. Not a big issue for this project, as file size was a concern, but only if it REALLY bloated. I did manage to reduce the file size drastically by changing the Audio Channels to Mono instead of Stereo.

Once those two issues were worked out, it was smooth sailing. The batch conversion features of SS4 made the job a lot easier and, as I mentioned, it cut through the compression process in great time.

The Wrap up

You probably need a refill of your drink by now. Thanks to those of you who made it to this point.

After it was all said and done, the CD, with 5 FLV videos and projectors for both PC and MAC, the total file size came in at under 500mb, well short of the 700mb mark. I could have increased the video quality even more, but the clock was ticking and it was time to deliver. The client was extremely pleased with the final product. In fact, they preferred the menu and delivery of the CD version BETTER than the DVD, although the DVD still obviously had better video quality. All in all, the project was a great experience and solidly shows that, when file size is a concern, FLV is a great technology for offline video solutions as well.

Flash Lite 1.1 for AU

The time is coming around again for me to pick up another mobile phone. One of the primary reasons is in order to test content. Up to this point I have been a loyal NTT DoCoMo user (5 handsets in 3 years) and my current primary mobile is an SH900i for Docomo's 3G Foma service. Besides the wide array of features (Mega pixel camera, video phone, java games, web enabled, etc), my primary reason for upgrading was to have support for 100kb Flash Lite 1.0 movies. Prior to this I was using the 505i series that were the first phones to support Flash Lite (20kb max). I have been creating Flash Lite content since the beta release was made available to some content providers here in Japan and since that time have pretty much pushed the medium to its limits (which are not all that vast), but... I digress.

This time around I am thinking of going with an AU handset by provider KDDI. In November, they will be releasing the "Talby" (pictured below), a stylish little phone that supports the Flash Lite 1.1 player. I have been itching to develop some solutions using 1.1, exploiting the capabilities that are so painfully absent from the DoCoMo 1.0 port (ability to pull/push data from external sources, send variables, load movie, fscommand/fscommand2, etc), but without a true handset to test on, it is rather pointless. Yes, there are emulators, but these do an extremely poor job of reflecting one of the biggest issues in Flash Lite dev....system resource usage.

We have already started throwing around ideas for having the phone interface with some of our PC RIA (note that 1.1 still uses a subset of AS 4.0). So, we will keep you updated once the R&D begins!