Encoding Software

This program has a nice GUI for batch processing and it works nicely, not for any fundamental reason to do with encoding video.

The only problem with this program is it cannot be set to automatic 2-pass encoding, which would produce better results and better control over the peak bit rate. We normally use 1-pass encoding for speed.

For best quality, use 2-pass encoding, but make sure that the second pass uses the statistics from the first pass of the correct file! We have seen files encoded with a second pass using statistics from the wrong file's first pass, which is worse than 1-pass encoding.

Video Encoding

The settings with TMPGEnc 4.0 Xpress are:

Video Resolution

The chip does officially support MPEG-2 at 1920x1080p @ 30fps, however we tend not to use MPEG-2 because it requires a higher bit-rate than MPEG-4 for the same quality.

Video Frame Rate

Ideally, the frame rate of source material should match exactly the video encoding, and they should both match the refresh rate of the screen attached to the player. Where helpful, a simple ratio especially 2:1 can be used.

If the screen refresh rate is unknown or doesn't match the source material, the video encoding should follow the source material.

Note that 29.97 fps and 30 fps are both common, as are 59.94 fps and 60 fps. The difference between 29.97 and 30 is enough to cause little jumps every few seconds.

As a general rule, screens attached over DVI, HDMI or VGA tend to use 60 fps or 50 fps. NTSC and PAL over S-Video use 59.94 fps and 50 fps, both interlaced.

Frame Rate When Rendering Graphics

We have the frame rate set to 30 fps, which works well on screens running at 60Hz which most of our screens do. When driving a 50Hz screen, 25 fps looks better. Each screen's native frame rate depends on the exact model.

Frame Rate When Transcoding Pre-rendered Or Filmed Video

Don't change the frame rate during encoding. It is almost always a mistake. It introduces motion artefacts which the player cannot remove, and they can be compounded by a second layer of motion artefacts during playback.

Instead, encode at exactly the same frame rate as the source content, or a simple ratio of it, and let the player handle the screen's frame rate.

For example, when supplied with source video at 29.97 fps (or 59.94 fps interlaced like NTSC), encode the video at 29.97 fps, not 30 fps. When the source video is 24 fps, encode at exactly 24 fps. When it is 25 fps, encode at 25 fps.

When it is 50 fps, encode at 25 fps, because 50 fps is unnecessarily high, so 25 fps is a simple ratio (2:1) and is used instead. The same goes for 59.94 fps and 60 fps source content. It is possible to encode up to 50/60 fps progressive, but then image quality can be compromised to get the higher frame rate, to fit within the reliable bit-rate.

Advanced Frame Rate Conversions

In special cases, such as PAL source material in 720x576 @ 50 fps interlaced, destined to be played only over S-Video on a PAL screen, then it is better to keep the video interlaced because all the parameters match exactly.

When pre-rendered or filmed source content is supplied at 29.97 fps (or 59.94 fps interlaced), encoding at 30 fps should be avoided as that introduced motion artifacts which cannot be removed. However, if your encoding software lets you stretch the source content to 30 fps, that is better if it is known the attached screens run at 30 fps or 60 fps. If there is audio, that needs to be stretched to match. Shrinking from 30 fps to 29.97 fps is also possible. You can imagine this sort of thing is not available in the simpler tools.

Occasionally, source content may have come from 24 fps or 23.97 fps “cinema” frame rates but be supplied already as 30 fps or higher, with frames duplicated. A lot of DVD films are like this; it is called Telecining. The ideal thing to do is inverse-Telecine back to the original frame rate before encoding, which we won't describe further here.

Audio

Bit-Rate

Above that, and they begin to degrade gradually. The effect is not consistent, but intermittent. It does not show up in tests from a quick glance except at high bit-rates. At 16 Mbit/s, files do play, but sometimes slowly and sometimes at full speed, and may play for several minutes with no apparent problem. It is due to complex factors of the internal buffering when transferring data from disk.

So for reliable video, we recommend keeping to 8 Mbit/s or below. If higher bit rates are used, they must be tested carefully and for a long time.

Note that many encoders produce a peak bit-rate which is much higher than the requested average, when VBR (“Variable Bit Rate”) is requested. Often they are optimising to fit into a particular file size, with no regard for how difficult the file is to decode. The player does accept higher peaks because it has a substantial buffer (more like web video than live broadcast video), but the peaks must still be limited to ensure smooth playback.

CBR (“Constant Bit Rate”) does not have this problem, as it is designed for live broadcast video, which does not tolerate variable buffering delays and has strictly capped bandwidth. But it does not allow as much detail in fast transient shots.

File Names

  » Make sure file extensions are correct for the container format.

File names must not have spaces or unusual punctuation in the name. It is best to stick with letters, numbers, dashes, underscores and dots. Don't start a name with dot or dash. Unicode multilingual characters may be fine, depending on the user interface driving the video players.

  » Make sure file names don't contain punctuation or spaces.

Issues Resulting From Incorrect Encoding

A rule of thumb is to compare the file size in Megabytes with it's duration in seconds. At 8 Mbit/s, they should be about the same. If the Megabytes is much larger, the bit-rate is much larger too and that's a problem.

If a file plays nothing at all, it is likely due to using different software or different encoding settings than described in this document. Most encoding software is fine in our experience, and the chip supports many profiles of MPEG-1, MPEG-2, MPEG-4. However, as with all media players, there are profiles it does not support, and unusual settings it does not support.

  » Solution – Try known software, a tested format and tested settings first.
If alternate software is used, try to stick with the tested format and settings.

Another reason for a file not playing is trivial: the file name having the wrong extension, or containing punctuation or spaces which confuses some programs.   » Solution – Check file names are suitable and extensions are correct.
If audio “stutters”, it is very likely due to the file's video bit-rate exceeding the recommended target of < 8 Mbit/s. The problem here is overload due to fetching data for video decoding, which either slows everything causing gaps between audio frames, or simply overloads the system too much to keep audio playing.

  » Solution – Reduce the average and peak bit-rates.
If a file plays, but the video is slow in many places, it is likely due to the file's bit-rate exceeding the recommended target of < 8 Mbit/s.

If video slows down at different places each time it is played, then it is almost certainly encoded at higher averate bit-rate than the safe level, but below the range where the player can just about keep up (which is quite large). The player keeps up, but complex factors during playback slow the video unpredictably.

  » Solution – Reduce the average and peak bit-rates.
If video slows down in exactly the same places each time it is played, but most of the video is always played at full speed, then the average bit-rate is fine, but it has been encoded with a peak bit-rate which is too high. Unfortunately, we found several software encoders don't provide good control over this. If there is no other way, set the encoding to CBR (“Constant Bit Rate”) instead of VBR (“Variable Bit Rate”). CBR is used by broadcast video, because broadcast video cannot use a long buffer to hide variable bit-rate delays.

  » Solution – Reduce the peak bit-rate, or set to CBR (“constant bit rate”).

Alternative Software

On Windows, we have used MediaCoder (available from SourceForge) and FFMpeg to do encoding of content for the players, using the same settings as above, without any problems. MediaCoder just a graphical interface around FFMpeg, and has the nice feature that it shows how it calls FFMpeg, so that FFMpeg can be called directly from batch files or scripts for the same results.
On Linux, we have used mencoder, VideoLAN (vlc) and FFMpeg to encode for the players, usually XviD in AVI, but also MPEG-2. These are quite good quality encoders, however there is often some work to deducing the best options are there are so many.

Many free and low-cost encoding packages use FFMpeg under the hood, either for video encoding or for the whole encoding process. Many of them use a slightly modified version, according to feedback from their user communities.