
 Video encoder/decoder 0.04
 ==========================
 This is an experimental video encoder and decoder.
 It was developed to test the speed and quality of 4-point DCT compared
 to 8-point DCT (as used by eg. MPEG and JPEG).
 Currently, it accepts files holding 15bpp RGB images as input, and also
 outputs 15bpp RGB.


 Copyright
 =========
 This software is copyright  Henrik Bjerregaard Pedersen, 2000 and is
 released under the GPL (any version).


 About the 'coder' program
 =========================
 The coder program is a frontend for the encoder and decoder in codec.c.
 The program should be run from the commandline, and accepts the following
 arguments:

     coder <switches> <sizex> <sizey> <inputfile> <outputfile>

          -n <frames>         no. of frames to encode              [1]
          -s <size>           target size for compressed frames
          -i <dist>           distance between I-frames            [15]
          -offset <offset>    start-offset in input-file
          -rgbyuv <filename>  name of rgb-yuv translation table
          -yuvrgb <filename>  name of yuv-rgb translation table
          -sprheader          save spriteheader before saving data
          -decoded            save decoded data
                              (rather than compressed data)

 The algorithm works by dividing the frame into blocks of 4x4 pixels.
 For each block, it tries to find a very similar block in the previous
 frame, and if it succeeds, it simply saves the coordinates of that
 block; if it fails, it performs DCT (Discrete Cosine Transformation)
 on the block, then quantizes the result (thus reducing the no. of bits
 required to store the result) and finally saves only those values that
 are non-zero.

 The program requires input in RGB and also outputs RGB, but this is
 not really optimal, as the algorithm uses YUV and it is therefore
 necessary to convert from/to RGB, which reduces quality a bit.
 

 Quality
 =======
 Most of the testing has been done using frames of 224x168 pixels, with
 a target framesize of typically 5 to 10 kbytes.
 The quality of the output seems to be somewhere between the quality of
 the output from MovingBlocks and the output from MovingBlocks HQ - which
 isn't very surprising as my algorithm is very similar to the algorithm
 used by (the various versions of) the MovingBlocks compressor.
