boot-anim

[Neil Graham]

As it stands now there seems to be no 100% reliable way to judge the 
compressed size of things on jffs2.

I  cast my eye to the boot-anim,  uncompressed it comes to about 60 Meg, is 
there space being wasted there?

http://lists.laptop.org/pipermail/library/2007-July/000070.html says 
> JFFS2 compresses 4K chunks using zlib.  So it's not just per-file
> compression, it's compressing bits of a file.  It doesn't compress files
> where compression doesn't help.  And there's a 68 byte overhead per
> compressed chunk.  Plus probably some fixed overhead per file.

doing some tests using mkfs.jffs2 on a filesystem with a single file of zeros 
at varying sizes gave me.

 409600 --> 11656
 819200 --> 23256
1228800 --> 34856 
1638400 --> 46456

each growth of 100 4k blocks added 11600 bytes.  I'll go out on a limb and say 
the best case on jffs2 is turning a 4k block into 116 bytes,  about 35:1 
compression, or down to 2.8% if you prefer

This is why the boot-anim bothers me.  If it were all zeros it should be 
taking up just over 1.5 meg.  It compresses really well, but it can't go 
beyond that limit.  

Running the jffs2size.py script on /usr/share/boot-anim reveals. 

 no compression : 60480336, 60480K
  estimated jffs2: 1983630, 1983K (3%)
  mkfs.jffs2     : 2344068, 2344K (3%)
  zipped         : 389259, 389K (0%)
  .tar.gz        : 399360, 399K (0%)
  .tar.bz2       : 184320, 184K (0%)

It looks like there's easily a meg to be had there, two meg looks doable.

Where to go from here is another issue.  total flexibility and 90% of the size 
gain could be had by using pngs (not sure if there is a speed issue there)

If there were to be a simple runlengh encoding,  the bulk of the size would go 
and jffs2 would crunch the remainder.   wadeb whipped up a tiny rle 
compressor/decompressor pair.

gzipping at a file level removes the block overhead and the size drops to 
about 380k.

For smallest size, lzma compressed rle files. appear to be the best.  lzma 
isn't in the default install. It is small at 90k and has potential other user 
applications.

   6325  frame00.565.gz
   2283  frame00.565.lzma
 15236  frame00.565.rle
   1841  frame00.565.rle.gz
   1451  frame00.565.rle.lzma
 
 28097  ul_warning.565.lzma
 30594  ul_warning.565.rle.gz
 22935  ul_warning.565.rle.lzma

The final compression method is colour-of-the-bikeshed stuff,  the important 
thing here is freeing up the 2 meg.  Whether the actual saving can be1.9MB or 
2.2MB is less important.