Thursday, March 30, 2006

SWF & FLV file format specification version 8

Emmy Huang just posted on the update of the Flash File format specification documentation. This new documentation contains all of the changes we made for Flash Player 8, along with various corrections based on internal and customer feedback. Note, due to the fact that we are using some newer dynamic features in this .PDF file we published (to handle the license dialog), this will neither display using the built-in OSX PDF viewer or xpdf. You have to use Adobe Reader 6.x or newer.

The most important changes are probably the better documentation on the FLV file format, now including the data packet format which we had not publicly disclosed in earlier releases. Interestingly this was not because of our unwillingness, but simply because nobody thought of it. You'll notice the format is essentially AMF.

There will probably be some disappointment that NellyMoser and the On2 VP6.x bit stream formats are not documented. Unfortunately there is not too much I can do about this, despite my personal belief that we should document everything. Here is hope though that in the future we will adopt the same policies and resources as Adobe has done for PDF, which has excellent file format documentation. Currently it is basically the engineers on the Flash Player team who maintain this document, which is also the reason there is always such a large delay after a release of the Flash Player.

My own contributions in this document are the PlaceObject3 documentation (including the filter descriptions), the FLV file format description, the video section, the changes to the shape structures and various other clarifications and notes. Spot my terrible English writing none of our reviewers did spot. :-) I already found a couple of grammatical 'glitches' after re-reading my own writing tonight. Time to update our internal errata with this so we can fix this the next time around... ;-)

Monday, March 20, 2006

My first Flex 2 Application using Flex Builder 2

Flex Beta 2 was just released and I finally spend some time fiddling with it today. While I have used the mxmlc command line compiler quite a bit to reproduce bugs, this has been my first real exposure to Flex Builder. So far I have to say it's neat. In a few hours I was able to hack together a little color picker from scratch.

Check the sample flex app here. This is obviously a shameless rip-off from the Photoshop color picker, with 90% of the functionality missing and not even scratching the surface on what you can do with Flex ;-) Also note: This will require the beta build of Flash Player 8.5 we just released, e.g. Flash Player 8.5.0.245 (you can check your version number here).

The full project including source is here and pardon the dust in this code, it's really meant to get some experience... But maybe you'll find this useful.

Wednesday, March 15, 2006

Public preview of Flash Player 8 Universal build now available

We are finally ready to offer you a universal binary of Flash Player 8 for OS X. Take a look at this tech note and the post by Emmy Huang, the product manager of the Flash Player.

This is a public preview, we do not see this as the final release. That is the reason you do not see it right now on the main download page. There is still some work on our side to finalize it, something we will try to accomplish with Flash Player 8.5.

Of note, we fixed the 'blue text' issue, along with the alpha blending bug which was reported to us. It should also be a tad faster, but please: do not use this build for benchmarking, it's really not reflecting what we are trying to reach in Flash Player 8.5 for MacTel systems.

Monday, March 13, 2006

On color spaces and gamma correction in the Flash Player

Now that we are part of Adobe, we are subject to the huge body of knowledge when it comes to color technologies. One of the earliest questions we got was how we handle gamma correction in the player. The simple answer is: we don't.

The Flash Player is currently using 8 bits per component and this has traditionally limited what we can do. So in essence we use sRGB throughout the renderer without correcting our compositing functions for linearity (see some of the links below to understand why this is a problem). This has been done mostly for performance reasons, as any kind of correction would require more than 8 bits per component and an additional pass using table lookups to get the correct results.

In addition OS X's native gamma is 1.8, whereas sRGB is close to 2.2. This means content on these machines looks different. Unfortunate, but pretty much all image formats for the web have the same problem (GIF, JPEG and PNG), that includes plain HTML/CSS colors. Safari has made the situation a little more complicated, since it does some gamma correction, but is not always consistent.

What does the future hold? Well, probably not too much in the immediate future. But as I look at how we could take advantage of using GPUs we will have to revisit this (Disclaimer: I do NOT know what we will do in this regard, this is pure speculation from my side). Currently most GPUs will use linearRGB internally and gamma correct their output for displays in the last stage of the pipeline (linearRGB is essentially a linear version of the sRGB color space). This is the 'correct' thing to do and does improve compositing quality quite a bit. It also does not impact on performance in the context of GPU rendering. But using linearRGB internally means drastic changes to rendering, the effect would be that content will look different in a software implementation versus a hardware implementation. The other option is to take a huge hit performance wise for the software implementation, something we might not be ready to do.

Some links on this might be of interest, they pretty much explain everything about the problems I scratched on here: