A Deep Dive Into YouTube FLV Video

In my last post I did a quick comparison of Jing screencast video in lossless swf vs lossy flv hosted on YouTube. After seeing the rendered results embedded in a web page I quickly became a bit more curious about YouTube’s flv files and set out to discover some more info.

First, using Safari’s Activity monitor, find and retrieve the flv served up by YouTube:

Save the file url to disk and give it a .flv file extension. To discover a little bit more about the YouTube video we’ll need to take a look at its metadata and for that we’ll use a neat little Ruby app Flvtool2 (if you need a primer on using flvtool2 check here and here).

From the above we can see that YouTube flv files are short on conventional metadata, but interestingly each keyframe’s time, in seconds, and location, in bytes, is stored. This keyframe metadata is likely there for future deep tagging, to assist seeking logic, or waiting for advertising event logic–any way its a cool idea.

We still haven’t officially been able to see the flv’s width and height so it’s time to use flvtool2 to inject some additional metadata into the file and save the result with a new name (utube.flv). Here’s a look at how to accomplish this.

Running flvtool2, once again to read back the new flv file with additional metadata gives us the following:

It’s clear the file is 320 x 240 and it’s also possible to verify that YouTube is still using the Sorenson Spark .h263 codec by looking at the “videocodecid” attribute that flvtool2 inserted. If you check the Flash file format specification you can see that “2″ is the id corresponding to .h263.

Pretty interesting stuff–in the future maybe I’ll try to discover some information about Brightcove’s flv media.

Jing Video and YouTube Comparison

I’ve been watching the blogosphere comments regarding TechSmith’s Jing Project and a frequent objection / feature request is for Jing to output to the popular consumer video hosting site YouTube. This is an interesting request given a couple of facts:

1. YouTube currently doesn’t support upload of videos from third party tools or sites. To say it a different way, YouTube does not currently have a public upload API, therefore the process of uploading is done manually via their site.
2. The quality of your screencast video goes from lossless swf to lossy low bitrate h.263 flv.
3. Your video resolution is constrained to no greater than 320 x 240.
4. Visual conversations go from quick and seamless to slow and clunky.

So those are some of the answers as to why YouTube output wasn’t supported “out of the project” by Jing (I’m just deducing the above as I didn’t actually sit in on the design / scoping meetings for the Jing Project). Given these issues, I thought it would be interesting to do a side by side comparison of the same Jing video in its “native” swf format vs uploaded and encoded on YouTube.

I used AfterEffects CS3 to import a Jing swf file (using a special build of Jing that creates swf files without the start screen thumbnail overlay). I created a 320 x 240 composition, added the comp to the render queue and exported a QuickTime .mov file with Animation compression (Animation is very close to uncompressed). The .mov file was then uploaded via YouTube’s web uploader.

YouTube using the default the dimensions provided by YouTube’s embed tags:

Jing swf saved locally and uploaded to my webserver–same quality as Screencast.com:

YouTube using modified video aspect ratio dimensions (tags reflect actual video size plus playback controls):

Analyzing the results above a few things become clear:

• YouTube’s decision to scale the video results in a poor end user experience. It’s clear they made a decision that most users would favor size over quality. My guess is they wanted to stick with a 4:3 aspect ratio in a resolution supported by a large number of devices, couldn’t afford the bandwidth or web layout challenges 640 x 480 brings, but felt like full motion video can scale up a little without total degradation. Unfortunately, the combination of screen capture video and the codec’s poor scaling capabilities hurts and it shows in the first embedded video.
• The native swf output of Jing is clearly the highest quality video output.
• When YouTube’s embed dimensions are altered to fit the actual size of the flv being played back the screen video looks surprisingly good. It’s obvious the guys setting up the server-side encoding know what they’re doing and are maximizing the Flash .h263 codec’s capabilities. Clearly a screen recording with more motion would have presented some challenges to the codec, but YouTube seems surprisingly well equipped to support screencasting.
• 320 x 240 is a very cramped environment for screencasting. It’s definitely doable, but the simplified rich recording client used by Jing makes for a very clunky workflow at this resolution.
• For those curious YouTube was easily the winner in the video size category weighing in at 236 KB while the Jing lossless uncompressed swf was 696 KB. Even after compression (something Jing has to do in my mind), the Jing swf still weighed in at 544 KB.

So the question still remains, is YouTube a no brainer when it comes to video output from screen recording clients such as Jing, Camtasia and Captivate?

Adobe Flash 9 SWF Specification To Be Released End of Month (July 07)

Woot! JD left a comment today on an a previous post indicating that the Adobe Flash 9 SWF Specification will be pushed live the last week of July 07.

It’s been a while coming, but I’m just geeky enough to be happy knowing I’ll be parsing that pdf within a fortnight.

Oh, and thanks JD for somehow being plugged in 24 / 7 and still remembering to follow up internally on a rather obscure blog post from a couple of months back – you are a fantastic asset to the community. :)

Embedded Asset Paths in ActionScript 3

After banging my head against a brick wall for a bit, I finally realized that when embedding assets in ActionScript3 files the path to the embedded asset is relative to the location of the .as file in which the embed statement is placed and not relative to my MXML or AS application entry point. If you look at the image below you’ll note that the embed statement has to traverse up the package structure (3 levels) before pointing to the required graphical asset.

It’s a bit strange that the compiler isn’t smart enough to establish a top level path to assets based on the application entry point, but maybe I’m missing something.

Simon Cave points out in the comments, “You can use an absolute path (which is actually relative to the project directory) by starting your reference with a forward slash.” Here’s what that looks like:

Flex Framework Source Location on Mac OS X

In case you’re wondering where Flex Builder installs the Flex framework .as source files here’s a snapshot:

And Here’s a path to copy and paste (based on the moxie beta):

/Applications/Adobe Flex Builder 3 Plug-in/sdks/moxie/frameworks/projects/framework/src