wuly@vax5.cit.cornell.edu (04/16/91)
Ok, I have been getting some requests by EMAIL for .FLI information and sites. I thought I'd just post what I know at this point. .FLI sites: export.lcs.mit.edu, in /contrib, there are 2 xflick unix-compressed tar files, one has the player and the other a couple of animations. These work fine on a SPARC, and look pretty good. kfps-roble6-dynamic.stanford.edu, some in /anim/fli. In .zip format. (haven't tried them yet - I don't have a .zip extractor) wuarchive.wustl.edu, in /pub/zap (MSDOS self-extracting archives, I haven't tried them since I have a SPARC but they are there) and /pub/raytracker, in .lzh format (haven't tried them yet - I don't have a .lzh extractor). .FLI FORMAT: > From: IN%"hole@rieska.oulu.fi" 16-APR-1991 09:25:13.10 > Hi Jesse, I made those animations, but I dunno about the fliformat, since > I used Autodesk Animator. But I have the description of the format, So I > might as well include it here. > And here's the document: Autodesk Animator files explanation (.FLI only excerpted). I believe that the original programmer wrote up this doc. It's correct, as I've used the info to realtime playback stock .FLIs on a 680x0 machine. All numbers in a .FLI file are in Intel format, so you may have to compensate for that, of course. - kevin 8.1 Flic Files (.FLI) The details of a FLI file are moderately complex, but the idea behind it is simple: don't bother storing the parts of a frame that are the same as the last frame. Not only does this save space, but it's very quick. It's faster to leave a pixel alone than to set it. A FLI file has a 128-byte header followed by a sequence of frames. The first frame is compressed using a bytewise run-length compression scheme. Subsequent frames are stored as the difference from the previous frame. (Occasionally the first frame and/or subsequent frames are uncompressed.) There is one extra frame at the end of a FLI which contains the difference between the last frame and the first frame. The FLI header: byte size name meaning offset 0 4 size Length of file, for programs that want to read the FLI all at once if possible. 4 2 magic Set to hex AF11. Please use another value here if you change format (even to a different resolution) so Autodesk Animator won't crash trying to read it. 6 2 frames Number of frames in FLI. FLI files have a maxium length of 4000 frames. 8 2 width Screen width (320). 10 2 height Screen height (200). 12 14 2 flags Must be 0. 16 2 speed Number of video ticks between frames. 18 4 next Set to 0. 22 4 frit Set to 0. 26 102 expand All zeroes -- for future enhancement. Next are the frames, each of which has a header: byte size name meaning offset 0 4 size Bytes in this frame. Autodesk Animator demands that this be less than 64K. 4 2 magic Always hexadecimal F1FA 6 2 chunks Number of 'chunks' in frame. 8 8 expand Space for future enhancements. All zeros. After the frame header come the chunks that make up the frame. First comes a color chunk if the color map has changed from the last frame. Then comes a pixel chunk if the pixels have changed. If the frame is absolutely identical to the last frame there will be no chunks at all. A chunk itself has a header, followed by the data. The chunk header is: byte size name meaning offset 0 4 size Bytes in this chunk. 4 2 type Type of chunk (see below). There are currently five types of chunks you'll see in a FLI file: number name meaning 11 FLI_COLOR Compressed color map 12 FLI_LC Line compressed -- the most common type of compression for any but the first frame. Describes the pixel difference from the previous frame. 13 FLI_BLACK Set whole screen to color 0 (only occurs on the first frame). 15 FLI_BRUN Bytewise run-length compression -- first frame only 16 FLI_COPY Indicates uncompressed 64000 bytes soon to follow. For those times when compression just doesn't work! The compression schemes are all byte-oriented. If the compressed data ends up being an odd length a single pad byte is inserted so that the FLI_COPY's always start at an even address for faster DMA. FLI_COLOR Chunks The first word is the number of packets in this chunk. This is followed directly by the packets. The first byte of a packet says how many colors to skip. The next byte says how many colors to change. If this byte is zero it is interpreted to mean 256. Next follows 3 bytes for each color to change (one each for red, green and blue). FLI_LC Chunks This is the most common, and alas, most complex chunk. The first word (16 bits) is the number of lines starting from the top of the screen that are the same as the previous frame. (For example, if there is motion only on the bottom line of screen you'd have a 199 here.) The next word is the number of lines that do change. Next there is the data for the changing lines themselves. Each line is compressed individually; among other things this makes it much easier to play back the FLI at a reduced size. The first byte of a compressed line is the number of packets in this line. If the line is unchanged from the last frame this is zero. The format of an individual packet is: skip_count size_count data The skip count is a single byte. If more than 255 pixels are to be skipped it must be broken into 2 packets. The size count is also a byte. If it is positive, that many bytes of data follow and are to be copied to the screen. If it's negative a single byte follows, and is repeated -skip_count times. In the worst case a FLI_LC frame can be about 70K. If it comes out to be 60000 bytes or more Autodesk Animator decides compression isn't worthwhile and saves the frame as FLI_COPY. FLI_BLACK Chunks These are very simple. There is no data associated with them at all. In fact they are only generated for the first frame in Autodesk Animator after the user selects NEW under the FLIC menu. FLI_BRUN Chunks These are much like FLI_LC chunks without the skips. They start immediately with the data for the first line, and go line- by-line from there. The first byte contains the number of packets in that line. The format for a packet is: size_count data If size_count is positive the data consists of a single byte which is repeated size_count times. If size_count is negative there are -size_count bytes of data which are copied to the screen. In Autodesk Animator if the "compressed" data shows signs of exceeding 60000 bytes the frame is stored as FLI_COPY instead. FLI_COPY Chunks These are 64000 bytes of data for direct reading onto the screen. -eof- Notes: Since these are animations, the last frame will delta into a copy of the first one (which was usually a large BRUN chunk). Therefore, looping should go back to the _second_ frame chunk (usually a LC or COLOR chunk) instead of all the way back to the file beginning, to avoid a "stutter" caused by unnecessarily redecoding the original frame. Also, a very few files may have palette animation, so write your code so that COLOR chunks can be found at any time. - kevin And there you have it. If *anyone* has already written code to take images and wrap them into .fli, please let me know! Also, everybody interested in .fli animation on SPARCs will need to extract .zip and .lzh files. If you have source to such a beast, again please let me know! Jesse Lackey
luk@cs.rochester.edu (04/17/91)
Hi, >.FLI sites: >export.lcs.mit.edu, in /contrib, there are 2 xflick unix-compressed tar files, > one has the player and the other a couple of animations. These > work fine on a SPARC, and look pretty good. I tried to tar the two files I got from the site, but both failed: (I did that on Sparc too) uncompress xflick-flis.tar.Z uncompress: corrupt input tar xvf xflick.tar tar: directory checksum error (0 != -1168) Can anyone give me some advice on this ? Thanks! Steve Luk