It is available at Berkeley's FTP site
mm-ftp.CS.Berkeley.EDU and called
mpeg_encode1.5b
It has lots of options to tune, so you should spend quite a lot
of time playing with this. The configuration I use is in file
doc/mpeg.param.
I've also made some patches that makes possible to use the
pattern and motion files generated from XaoS. The patch is in
doc/mpeg_encode.patch. So if you want to use these
features (they are EXPERIMENTAL) you might apply
this patch and recompile the encoder.
Once you filled the mpeg.param file (see comments
inside), you should render sequence using mpeg_encode
[filename] and with luck you are done.
MPEG sequence consist of these three frames. The I frames are just images saved in a format similar to JPEG files.
The P frames are images which are constructed as a delta from the previous one (the latest I or P frame). In case consecutive frames are similar (and in animations they often are), a P frame takes much less disk space than an I frame.
The B frames are constructed from the nearest previous P or I frame and the next P or I frame. They take even less disk space, but they are quite hard to encode. Also they are not used as previous frames, so their information is lost once they are displayed. They are usually rendered at lower quality than a P or I frame and used just to interpolate nearest frame and make animation smoother. It is generally not a good idea to make a whole sequence just from B frames.
Using just P frames is generally not a good idea. It makes the
file shorter, but to jump into Nth frame of animation you need to
recalculate all P and B frames since latest I
frame. Decoders often want to jump to some frame (when the
user asks, or when they can't decode a sequence in time and must
skip some), so you need to have some I frames in the animation to
make this possible. The latter reason means that you need to place
them quite often. Usually they are used for every 15th frame or
thereabouts. Because they cost quite a lot, in my animations I
usually use every 27th frame. To set this distance use
-iframedist option. It should be a multiple of 3.
XaoS generates a recommended order of frames based on its
knowledge of fractal motion. Situations where the screen doesn't
move at all are rendered just from P frames (since jumping is
usually not required here); in situations where the screen changes
completely (at least in XaoS's opinion) I frames are used and in
other cases, a standard sequence IBBPBBPBBPBBP... is
used.
If your encoder supports this, you should supply this pattern for encoding to squeeze out some bytes.
If some objects on the screen are moving at a constant speed, motion vectors can store that speed, so no image needs to be saved to represent that change.
Calculating this motion vector is a very significant task. If you guess them well, you increase quality and reduce file size, which is always great. Calculation also takes lots of CPU and it is hard to get optimal vectors (it just takes too long).
XaoS knows how the fractals move, so it can calculate this
vectors quite easily. XaoS saves this information into
*.p and *.b files. (*.p are
for P frames, *.b are for B frames). If your encoder
supports this, you should provide this vector to increase quality.
They are not exact (XaoS can make mistakes); the
encoder should try to find its own vectors, then try XaoS's ones,
and pick whichever is better.
This technique saves quite a lot of bytes in fast zooming/un-zooming animations (where images move more than 3 or 5 pixels per frame--since most programs look 10-20 pixels around each point for motion vectors).
To enable saving of motion vector files, add the option
-rendervectors.