SWF File Header
Field
Type
Comment
Signature
8 bits
Signature byte:
F indicates uncompressed
C indicates compressed (specific to SWF6 and later)
Signature
8 bits
Represents W
Signature
8 bits
Represents S
Version
8 bits
Represents the SWF file version, e.g. 0x06 represents SWF6
File Length
32 bits
The total number of bytes occupied by the entire file
Frame Size
RECT structure
The size of the SWF stage, in units of 1 twip (1/20 pixel)
Frame Rate
16 bits
Frame Count
16 bits
The total number of frames in the movie
The file header begins with three signature bytes, which are either 0x46, 0x57, 0x53 (“FWS”) or 0x46, 0x57, 0x43 (“CWS”). An FWS signature indicates that the file is uncompressed. A CWS signature indicates that the entire file, after the first eight bytes — that is, after the file length field — is compressed using the open standard ZLIB. It uses the ZLIB library data format, which is described in the Request for Comments (RFCs) 1950 through 1952 documents. CWS is only permitted in SWF6 and later.
The byte following the signature is the version number. This version number is not an ASCII character, but an 8-bit number. For example, the version number of an SWF4 file is 0x04, not the ASCII character “4” (0x35).
The file length field represents the total length of the entire file, including the file header. If it is an uncompressed SWF file (FWS signature), the file length field represents the exact size of the file; if it is a compressed SWF file (CWS signature), the file length field represents the size of the file after decompression, so it is generally not the actual file size. Making the uncompressed (decompressed) size visible allows the decompression process to be more efficient.
The frame size field represents the width and height of the movie. It is stored in a RECT structure, which means its size can vary according to changes in the coordinate values (the coordinates of four points). The file size RECT is usually in this form: the Xmin and Ymin members are both 0; the Xmax and Ymax members declare the width and height. (Refer to the Using Bit Values section)
The frame rate represents the ideal number of frames to play per second. If the SWF file contains streaming sound data, or if the Flash player is running on a slow CPU, this rate cannot be guaranteed.
The frame count represents the total number of frames in the SWF movie
Note:
The unit of length in swf: swf uses twips to represent distances in coordinates, 1 twips = 1/20 pixel
swf uses 8-bit, 16-bit, 32-bit, 64-bit, signed and unsigned integer types. All integers use little-endian byte order (that is, the low-order value is stored in the high-order byte). Then within each byte, big-endian ordering is used. Example: the 16-bit 0xe712 is stored as 12 e7; the 32-bit 0x456e7120 is stored as 20 71 6e 45.
There are two kinds of fixed-point numbers in swf: 16-bit (8.8) and 32-bit (16.16). They use little-endian byte order
There are 3 kinds of floating-point numbers in swf: 16-bit (half precision), 32-bit (single precision float), and 64-bit (double precision double)
A bit value is a variable-length number, used in the RECT structure in swf. A bit value can represent unsigned, signed, and 16.16 fixed-point numbers. Bit values do not need byte alignment (other types do); if a type that needs byte alignment appears immediately after a bit value, zero padding is required. Bit values are interpreted using zero-padding or one-padding depending on the type. For example, SB[4] (signed 4-bit bit value) = 1110 is interpreted as the 16-bit signed integer 1111111111111110 = –2.
Definition of the Rect structure:
Field
Type
Comment
Nbits
UB[5]
Defines how many bits each item such as Xmin uses
Xmin
SB[Nbits]
The minimum x value of the rectangle
Xmax
SB[Nbits]
The maximum x value of the rectangle
Ymin
SB[Nbits]
The minimum y value of the rectangle
Ymax
SB[Nbits]
The maximum y value of the rectangle
Nbits is used to determine how many bits are used to store each item such as Xmin, Xmax…, for example given a rectangle (decimal means decimal, binary means binary)
Shorthand notation table:
UIx x-bit unsigned integer; (e.g. UI8 means an 8-bit unsigned integer, i.e. a one-byte unsigned integer) SIx x-bit signed integer; UIx[n] an array of x-bit unsigned integers of length n; SIx[n] an array of x-bit signed integers of length n;
FIXED 32-bit 16.16 fixed-point number FIXED8 16-bit 8.8 fixed-point number
FLOAT16 16-bit half-precision floating-point number FLOAT 32-bit single-precision floating-point number DOUBLE 64-bit double-precision floating-point number
UB[n] an n-bit bit value representing an unsigned integer SB[n] an n-bit bit value representing a signed integer FB[n] an n-bit bit value representing a fixed-point number
Flash Tag Format
Each tag begins with a tag type and length. There are two tag header formats: short and long. The short tag header is used for tags whose data does not exceed 62 bytes; the long tag header can be used for any tag within 4GB, much larger than what is actually used.
Tag header (short)
Field
Type
Comment
TagCodeAndLength (tag type and length)
16 bits
High 10 bits: tag type
Low 6 bits: tag length
If the tag is 63 bytes or longer, it has a long tag header. The long tag header is like a short tag header beginning with 0x3f, followed by a 32-bit length.
Tag header (long)
Field
Type
Comment
TagCodeAndLength (tag type and length)
16 bits
The tag type and tag length (the tag length here is not the real one) combine to form 0x3f, packed like a short tag header
Length
32 bits
Tag length
Definition Tags and Control Tags
Definition tags: These tags define the content of an SWF movie, such as various shapes, text, bitmaps, sounds, and so on. Each definition tag is assigned a unique identification number when its content is defined; this is called a character ID. The Flash player places these characters into a storage space, which we generally call a dictionary. Using definition tags does not draw any graphics and does not produce any animation.
Control tags: These tags are used to create and manipulate the rendering of character instances in the dictionary, and to control the flow of the movie.
Ordering of SWF Tags
In general, tags can appear in any order, but it is not entirely arbitrary — they follow some rules:
A tag can only depend on tags before it, not on tags after it.
A definition tag that defines a character must come before the control tags that reference this character.
Streaming tags must be in order; streaming media without order also plays without order
The end tag should be at the end of the SWF file.
Dictionary
The dictionary is the repository of all characters that have been defined, and it can be used through control tags. The process of building and using the dictionary is as follows:
A definition tag defines some content, such as a shape, font, bitmap, or sound.
The definition tag assigns a unique character ID to that content.
The content is stored in the dictionary according to the character ID.
A control tag looks up the corresponding content from the dictionary according to the character ID, and then performs some action on this content, such as displaying a shape or playing a sound. Each control tag specifies only one unique ID. Duplicate IDs are not allowed. As a symbolic example, the first character’s ID is 1, the second character’s ID is 2, and so on. The character with ID 0 is a special ID, regarded as the empty character. Control tags are not the only tags that point into the dictionary. Definition tags can also point to multiple characters to define some more complex characters. For example, the DefineButton and DefineSprite tags both define their content based on other characters. The DefineText tag can point to font characters to select different fonts for text.
Processing an SWF File
Before a Show Frame tag arrives, the Flash player processes all tags in the SWF file before the Show Frame tag. At this time, the display list is copied to the screen, and meanwhile the Flash player is idle before processing the next frame. The content displayed in the first frame is the cumulative effect of all control tag operations before the first Show Frame tag. The content displayed in the second frame is the cumulative effect of all control tag operations from the beginning of the file to the second Show Frame tag. And so on.
File Compression Strategy
Since SWF files are transmitted over network connections very frequently, they are of course better the more compact they are. There are many techniques to achieve this. These are several effective strategies we have chosen:
Reuse The structure of the character dictionary makes it very easy to reuse SWF file elements. For example, a shape, button, sound, font, or bitmap can be stored only once in the file but used many times.
Compression Shapes use a very effective difference encoding method for compression; often the starting coordinate of a line is the ending coordinate of the previous line. Distances are often expressed by the coordinates of the previous position.
Default values Some structures such as matrices and color transforms have some common attributes that are used more than others. For example, for a matrix, the most commonly used attribute is the translation attribute, while scaling and rotation are used relatively less. Therefore if the scaling attribute is not defined, its value is assumed to be 100%; if the rotation attribute is not defined, its value is assumed to be no rotation. Using default values can minimize file size.
Change encoding As a rule, SWF files only store the change between two states. This is reflected by the shape data structure and the positioning/moving/removal blocks used in the display list.
Shape data structure The shape data structure uses a unique structure that minimizes the file size of shapes and makes smooth anti-aliasing of shapes on screen very effective.