i would only use dxt's block compression schemes, thats not to say i will be using the dds file format. say you take a 440*200 cbani. this animation would be roughly 110*50 blocks in size. keyframes would always have all blocks defined, consecutive frames would only update blocks that change significantly enough. so if only 50% of the second frame has changed from the first frame, then only 50% of that frame need be stored (this is in addition to the block compression). this could be streamed for forward playback (this method of compression would not allow reverse playback without precaching). only the file header, current frame header(s), and frame buffer(s) need be stored in memory. no more than a few frames would be buffered in ram at any one time, during playback the file handle will be left open until the the playback session is ended, at which time the handle is closed. keyframing would be handled as a stored offset of the frame header of the keyframe.
i dont like the idea of container formats for image files of some format. they lack any form of inter-frame compression, which is how video formats manage a pretty good compression to size ratio. mng i believe does this, my only objection to that format really is the unavailability of existing tools. my alternative really isnt much better, as it only exists in the mind of a rather unfocused hack-coder, and would probibly take me forever to write proof of concept code anyway. i said before (in the previous mng thread) that mng looked good on paper, and if you guys think it will be easier to code and support (despite the difficulties with the format) than a from scatch format, have at it.
i was looking at the compression algorithms for dxt5's alpha channel, and if i encode all four rgba channels in the same way, i can compress down the blocks to 16bpp. something like this is used with bc5 normal maps to improve quality over dxt5nm (except using 2 channels instead of 4). if i limit the color table in a block to 2 bits (instead of 3) per pixel, i can drop the compression down to 12bpp. this should still result in better quality than dxt1 since all channels are encoded separately. still looking at alternatives to dxt1a blocks which would provide more quality at a minor expense to size.
i can also do a variation on dxt1 where the two 16 bit colors are replaced with two 32 bit colors, while keeping the 2-bit color indexes. this would result in the block weighing in at 6bpp. also the 2 bit per color index could be up-sampled to 3 or 4 bits at an extra 1 or 2 bits per pixel. this could improve quality but may lead to some bizarre artifacts however (alpha would intrude into the color space). i could avoid this by using 2 bits for color and 2 bits for alpha (8bpp).