XaoS online help - Berkeley parallel MPEG encoder
Description: XaoS, realtime, fractal, zoomer

# Berkeley parallel MPEG encoder

This is the encoder we used to recommend. However, it has not been updated for a very long time and no longer appears to compile on modern systems. Also, there are much more modern codecs available that provide better video quality and compression rates. Still, we have kept the following instructions mainly for historic purposes.

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.

## Pattern file

Some other files are generated as well. A pattern file is generated, which contains a recommended order of P, B and I frames.

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.

## Motion vector files

XaoS also generates a motion vector recommendation for the encoder. This is useful for encoding of B and P frames.

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`.