Main | August 2006 »

July 27, 2006

HD Preset

Wow, it's all zip zap zoom with the updates today. Thanks Dan!

We've now got an HD Quicktime 7 preset. This will only show up if your source media is at least 1440x1080. You'll get a 1920x1080 H.264 file with a rather chunky bitrate - perhaps as high as 8mbits/sec. For reference, this is on par with the HD videos you can get from Apple - they tend to range from 8-10mbit, and so became my target when creating the preset.

Please submit comments if you think this preset should be tweaked in any way. I don't have a ton of HD footage to test with, so it's my best shot at balancing Ultra-Quality with reasonable compression.

Windows Media Presets

Our derivative support has grown again - you can now create Windows Media 9 video derivatives, in the standard Small, Medium, Large and Very Large formats.

These are all WMV9, single pass. With the exception of the Very Large format, they are all constant bitrate. This may switch down the line, when I have time to tweak the variable bitrate (VBR) presets for each quality level.

The WMV9 is more or less on par with the Quicktime7, and definitely a step above Flash. Only in the most compression-challenging scenes does Quicktime 7 (h264) take an edge over Windows Media (VC1).

July 26, 2006

Performance Enhancements

Some good news about performance for once.

As I mentioned earlier, I had tracked down the Flash performance hit to either Compressor or FlixExporter. I now think it's a combination of both.

Essentially, if we tell the Compressor software to store its temporary files outside of the default location, disk accesses for the Flash plugin go through the roof. While this fundamentally seems to be a bug in Compressor (and I've reported it to Apple), the FlixExporter seems to blow it way out of proportions. Flash jobs were using, at most, 40% of the available CPU time.

For now, I've switched to a secondary Flash encoder - this time, the default Quicktime plugin which comes with Flash 8 Professional, instead of the separate On2 product. You get less control over the final video this way, but I think it'll be Good Enough(tm) for now.

While this plugin still stuffers from the Compressor issue, it's at most suffering from a 12% performance hit, instead of a 60% (or more) performance hit.

As an aside, the reason that we're using a non-default storage location for the compression cluster is that it allows us to get rid of the annoying "preparing video" step. During that step, your whole video had to be copied off of the RAID array and onto a local harddisk. This was a major time hit, and also meant we had to set aside extra storage on the local machine. By placing the storage on the RAID, your video starts processing as soon as you hit submit - on larger jobs, this could save you up to 10 minutes of processing time.

New Feature: Download your Original

When you access your "My Videos" page, you'll now see that you have a download icon attached to each original video. This allows you to download the original video file which you uploaded to Media Mill, totally unmolested.

This file is only available to you - the link requires that you be authenticated with your University username and password.

July 25, 2006

Flash is Faster

So I nailed our Flash issue down to a bug in either Compressor or FlixExporter. The good news is, I've been able to work around the issue. I'm going to continue working to track the issue down, but until then, Flash encoding should be between 2 and 4 times faster. Hoorah!

Why is flash so slow?

Short answer: I have no idea. Read on.

In order to generate Flash video's, we use the Flash Exporter plugin from On2. It's just a standard Quicktime plugin. Compressor send video into the FliX black box, and out the other side comes FLV video. It seems to take approximately an hour to do compress four minutes of video at 640x480. This is running on a dual G5 xServe, pulling data over an xSan. It seems that there are a few problems with that setup. First, the export plugin isn't multithreaded, so it will only ever use a single CPU.

Next, when processing the data, nfsd uses about 50% of the CPU time. It seems like it's constantly reading and writing data from the shared folder that qmaster creates.

I'm hoping that when we transition to Intel xserves, some of this issue may magically be resolved. Unfortunately, until then, I think we're stuck with very slow Flash.

July 24, 2006

Embedded Flash!

Follow the link for my test of YouTubeyness!









July 21, 2006

Regarding Job Completion Information

If you've played with Media Mill much, you may have noticed that the percentage-complete indicator for your job doesn't update that frequently. The reason for that is that we only cache that information once every 60 seconds (give or take). So, the percentage you see could be up to a minute out of date. This is because it actually takes quite a long time to get status information out of the compression cluster. When we initially deployed Media Mill, all that information was queried on every page load, and it took *forever*. 60 seconds seems like a reasonable tradeoff. Doing it more frequently would just deprive the actual compression process of cycles, making your job take that much longer.

Make sense?

Preset Revamp

I've just finished revamping all of the Quicktime 7 download presets. While working on testing for the upcoming WMV presets, I couldn't help but notice that the WMV9 looked a whole lot better than the Quicktime7 (h264) that we were generating. Well, perhaps not a whole lot better, but better nonetheless.

After poking around a bit, I came to a few conclusions. First, a lot of the perceived quality advantage of WMV9 is just because they're oversharpening the decoded results on playback. There isn't actually more detail, the edges are just more vibrant. Next, I realized that WMV9 is not using a fixed keyframe cadence (at least, as best as I can tell). I had previously had our QT7 presets set to keyframe every 30 frames. I've now switched that to automatic.

Finally, I don't think that WMV9 actually maintains a fixed bitrate, even with the CBR setting. I think it's more like semi-fixed - it won't exceed the cap, but may shift bits around a bit. In order to replicate that effect, I've switched the download presets from using a hardcoded bitrate to using a spatial quality setting. I had previously been wary of this, as it can result in files that are of an unexpected size, but in my testing, I think the new presets will deliver file sizes about on par with the old settings, while providing higher quality results.

Why you may ask, does it provide such better results? By using a spatial quality setting (temporal stays at 50%), the compressor is able to shift bits around, giving a few more bits to a complex scene and giving less bits to a less complex scene. This means the video is much less likely to "fall apart" and start showing big macroblocks.

The streaming settings remain unchanged, as I still believe that a constant bitrate is a high priority for good streaming.

Please, let me know if you think the new presets are good, bad, or still lacking.

Windows Media 9 support

We've added support for Windows Media as an import format. You can now submit all of those WMV files you have choking your harddisk, and convert them into Quicktime or Flash.

I'm also in the last stages of testing WMV9 presets, so that you'll be able to generate Windows Media video. I must say, I'm very happy with the quality of the Flip4Mac export component. It gives me plenty of control and is far more userfriendly than the On2 flash encoder we're using.

Why aren't we doing H264 for the iPod?

Anyone who's used the iPod preset has probably noticed that we're using the older MPEG-4 codec, instead of H264.

Initially, this was done because up until Compressor 2.1, the H.264 that was generated wouldn't work on the iPod. Compressor 2.1 added an iPod preset, but unfortunately it comes with a little bug. Apple is investigating the issue, and when the issue is resolved, I will switch the preset to H.264. Until then, we have to sacrifice a little video quality in order to preserve the audio.

Welcome!

This blog is intended to provide updates about the MediaMill project (http://mediamill.cla.umn.edu). I'll try to post here when changes are made to the site, or when I want to discuss future directions.

Please post comments with your feedback!

-Colin