Jesse Ezell Blog

One of the most interesting part of the SWF specs has been the embedded video section. As you may know, starting with Flash 6.0, Macromedia added support for embedded video inside of SWF movies. The video compression codec was licensed from Sorenson and output to a slightly modified version of the H.263 video compression standard. Although it hasn't gotten any coverage yet that I have seen, in Flash 7.0 / MX 2004, Macromedia has added support for another video codec: ScreenVideo. ScreenVideo basically just divides your screen up into a grid and then encodes each of those grid squares as a lossless (or ZLIB compressed) chunk of data. If a grid square does not change, then the chunk's data is left out in subsequent frames, which means that this format is great for encoding video that has relatively static content (screen recording is a likely usage). Unfortunately, true to Macromedia's style, the docs on the video tags inside the SWF are incorrect (yes, the specs are a ton better, but still a few bloopers in there), and I had to spend all night decompiling SWFs and finally get in touch with Burak (the ASV guy) to confirm my findings. In any case, just to document this so people running into the same prob can find the answer, the ScreenVideo packet needs to be proceeded by UB[4] Frame Type, UB[4] Codec. This bears a striking resemblence to its format inside of an FLV file, which is noted in the specs as UB[4] Codec, UB[4] Frame Type. However, Burak mentioned that the FLV specs might be incorrect and that the reverse order is actually what you want. Oh, well. It works now.

If you haven't visited pinvoke.net yet, what are you waiting for?

Brian LeRoux blogs:

Nik Khilnani has an interesting experiment up and running. After thinking (like many others) that Flex is outragously priced ($10k+), he set out to prove that MXML compilation is a trivial process. Head over to:

I guess I wasn't the only one thinking this:

If you haven't heard, there is a special version of Tortiose SVN now for people using VS.NET. It gets rid of the .svn folder problem that messed up VS.NET web projects.

If you head over to:

While working on our .NET port of SwfSource (a .NET library for working with flash content and creating flash enabled applications), I have been extremely impressed by Macromedia's latest file format docs. A few years back, when I was working on the C++ version of the SDK, the docs from Macromedia sucked big time. They contained a bunch of misinformation and didn't cover a lot of the information inside the swf file format. Since then, Macromedia has restructured it's file format strategy, getting rid of the C++ SDK that they previously offered (good choice, since it was also crap), and focusing mainly on delivering quality docs so that third parties can create better Flash content creation tools (I'm sure the good docs probably had something to do with the Flex team needing some better explaination of the swf format too). This is the first time I've had a chance to really dig deep into the updated docs, and it is quite impressive when you consider the previous state of affairs. In any case, +1 for Macromedia on this one.