Version Tested: 3.5 standalone, 1.2 full plugin
Type: Software encoder
MPEG Standards: all versions: MPEG-1, MPEG-2, VCD, SVCD, DVD; standalone version: HDTV
Bit Rate Control Modes: average-based VBR, CQ VBR, average-high/average-low/max/Q VBR, CBR
Bit Rates: 0.1-15 Mbit/s
GOP Formats: I-frame, IP-frame, IPB-frame, unlimited number of frames per GOP
MPEG Audio Modes: Full MPEG-1 layer 2
Frame Sizes: Any (works with input size)
Multi-threaded Encoding? Yes
Scene Change Detection? No
Encoding Rate: 18.2 fps (plugin) or 8.7 fps (standalone) on a 1.2 GHz Athlon
Availability: Download
Price: US$180 for LE plugin or standalone full version, $250 for the full plugin

NOTE: This product is no longer available. However, I am keeping the review online for a couple of reasons. First, the Ligos GoMotion technology behind the LSX-MPEG Premiere plugin is still used in several third-party products, so the information here is stil useful. (I have it on good authority that it is the technology behind the All-in-Wonder cards, and the MPEG export plugin in recent versions of Adobe Premiere, among other things.) Second, it was one of the best encoders I've ever tested, so a lot of pages on this site still point to this review, for comparison reasons.

This is the best overall encoder in the roundup. Its two closest competitors are TMPGEnc and CCE SP. Its image quality is better than TMPGEnc's, it's faster than TMPGEnc, it comes with documentation and support, and it is much easier to use with Premiere. As for CCE SP, the LSX-MPEG Premiere plugin is faster, but the standalone version is slower. Both LSX-MPEG flavors are more functional and more usable than CCE SP, and they're a fraction of the price.

Ligos' encoding time is predictable: although the standalone encoder doesn't give a completion time estimate, it does say how many frames it has encoded, how many frames are in the movie, and how long it has taken. After one minute of encoding, you can divide the total frame count by the number of frames encoded and get the number of minutes left in the encode process. By contrast, TMPGEnc does give a completion time estimate, but it is inaccurate until about 50% of the movie is finished encoding.

Ligos' standalone encoder has a running encoding quality meter. It does this by measuring how different the encoded frames are from the originals, and then scaling it to a nonlinear 0-100 scale. Since it also displays the encoded video as it runs, you can easily monitor how well the encoding is going. If you aren't targetting a fixed bitrate medium like VCD or SVCD, you can use this to gauge whether to continue encoding or to stop and increase the bitrate setting in order to get usable video. When the encode process is finished, it displays the average and lowest quality levels achieved.

Here are the major differences I noticed between these two encoders:

Feature Standalone Encoder Premiere Plugin
CQ Mode Gives a variable quantization curve. Also, if you encode the same video with each encoder in CQ mode using the same Q value, each encoder will give a different bit rate. Gives a flat quantization curve (the right thing, IMHO)
Speed settings 5 settings which should be labeled "normal", "10% faster than normal", "a smidge faster than that", "10% slower than normal", and "your MPEG will be ready tomorrow, maybe the next day". 20 speed steps disguised as a "motion estimation accuracy" setting. Since changing this setting appears to have no discernable effect on the output quality, there is only one speed setting worth considering: ME=1, the fastest setting.
Frame Processing Resizing, letterboxing, deinterlacing, noise reduction, IVTC detection None – you can do all this in Premiere
Parallel Processing Yes, if your system has multiple CPUs Since the plugin relies on Premiere's weak multi-CPU support, it doesn't use multiple CPUs as efficiently as the standalone version. However, since the plugin is generally faster than the standalone version, this advantage doesn't matter in practice. (See the Encoding Speed section below for the hard data backing this up.)
Multiplexing The encoder encodes the audio and video to separate files, then optionally multiplexes them, and optionally deletes the audio and video stream files. Encodes straight to a multiplexed Program or System stream, or encodes to two separate files. No separate multiplexing step.
Audio Options Mono, stereo, dual channel and joint stereo Only mono and stereo.
Other Features Drop-B frame encoding (effectively makes low frame rate files, though MPEG only allows 24-30 fps), several GOP closure settings, stream padding (to maintain a given constant bit rate), running encoding quality display. None.
File Size Limited to 2 GB input AVIs, unless you frameserve to it from VirtualDub or patch the executable so you can feed it an AviSynth script. Unlimited file size, since Premiere does the file handling, not the plugin.

It's a bit of a toss-up as to which encoder is better. The plugin is faster, simpler to use, and has a proper CQ mode. The standalone encoder is generally more powerful, but slower and a bit harder to use.

For what it's worth, Ligos claims that the standalone encoder has a slight edge in terms of quality, though my tests showed the two to have almost indistinguishable output. They may be easier to tell apart when encoding different kinds of video, or encoding with different settings than used for this test.

Encoding Speed

The 18.2 fps encoding rate given above is with the Premiere plugin with the motion estimation turned all the way down to 1. This edges out even the blazing-fast CCE SP encoder! With ME=16, the video encoded at 12.7 fps, and at ME=20, encoding rate decreases to 5.9 fps.

The standalone encoder is an entirely different story: instead of a 20-position motion estimation setting, it has five speed settings. With the output window turned off and the encoder reading the AVI file directly instead of via VirtualDub's frame server, it encodes the test video at 10.3 fps (very fast), 10.0 fps (fast), 9.0 fps (normal), 7.8 fps (slow), and 1.9 fps (very slow). To summarize: "very fast" doesn't buy you much over "fast", and "very slow" is truly that. Keep in mind, you can only achieve these speeds with relatively small input files — under 2 GB. For larger files, you will need to use VirtualDub, which drops the encoding rates down to 8.7, 8.6, 7.8, 6.9 and 1.9 fps on my machine. In other words, the faster the encoding mode you choose, the higher the frameserving overhead is relative to the encoding time.

It's clear that Ligos has spent a lot more optimization effort on the MPEG encoding engine in their Premiere plugin. If you include the VirtualDub frameserving speed hit, the standalone encoder at its fastest was about half the speed of the Premiere plugin version.

The encoding speed doesn't affect quality very much with the standalone encoder. There is a noticeable but small difference between "very fast" and "very slow", but it is only worth it to pick "very slow" if you've got the time to burn, such as when you're doing an overnight encode. If time is important, go ahead and pick "normal" or one of the "fast" settings. With the Premiere plugin version of LSX-MPEG, the speed settings make no substantial difference in the output, with my test video. Unless I'm missing something, there is no reason to use anything other than the ME=1 setting with the Premiere plugin, all the time.

The GoMotion Engine

The LSX-MPEG Premiere plugin is based on their GoMotion engine, which focuses on tunability for real-time encoding. GoMotion is the engine ATI embeds in the MMC software for their current All-in-Wonder cards to provide real-time MPEG-2 encoding. So far in testing the LSX-MPEG Premiere plugin, I have not encountered any encoding errors like I saw with the AIW. I don't know for sure why the AIW would perform differently; perhaps ATI intentionally sacrificed correctness when tuning the encoder for real-time performance, or perhaps they're using an old version of the encoder.

Encoding errors aside, what about the difference in performance? The AIW comes very close to real-time performance (30 fps) on my test machine, but the plugin "only" manages 18.2 fps at with its fastest setting. That's still quite impressive for a software MPEG-2 encoder, but nowhere near what the ATI version of the encoder manages.

There are at least two differences between the ATI instantiation of the GoMotion encoder and the Premiere plugin. First, the ATI version gets its video from the capture section of the video card, whereas the Premiere plugin must read it from disk. And second, the ATI card's capture section delivers uncompressed YUV video to the encoder, whereas in my test, Premiere must uncompress the MJPEG data before the encoder can deal with it. Between the disk I/O and decompression hits, that easily explains the 1.6:1 speed difference between these two encoders. The only way to eliminate these overheads would be to use uncompressed YUV AVIs stored in a RAM disk. Anyone want to lend me a few 1 GB DIMMs? :)

I did another test with files using different types of compression, to see how much decompressing the AVI affects the Ligos encoder's speed:

AVI Codec Encoding Time File Size
PICVideo MJPEG, Q=20, 4:2:2 color space 1:02 197 MB
YUY2 (4:2:2 YUV) 1:02 593 MB
RGB (24 bit) 1:19 887 MB
HuffYUV (4:2:2 YUV color space) 1:26 181 MB

This more or less matches with my expectations: the 4:2:2 YUV formats are closest to what an MPEG encoder needs (it actually needs 4:2:0 YUV), which is why MJPEG and YUY2 are on top. HuffYUV is last simply because it's a fairly slow codec overall, not because of any YUV vs. RGB issue. And the RGB24 codec is last partly because the encoder must convert from RGB to YUV 4:2:0, but also in small part because of the file size overhead. (The latter doesn't seem to have hurt YUY2, however.) If my disk subsystem weren't so fast (2-disk ATA100 RAID-0) the RGB codec might have fared worse.

Supported VBR Modes

The Ligos encoders have three VBR modes: a 1-pass VBR mode based on max/average limits, a standard constant-Q mode, and a 4-parameter mode Ligos calls "optimized Q".

The 2-parameter VBR sometimes manages to "escape" the average bitrate value you specify. Once, for example, I asked for a 3 Mbit/s average bit rate and got a 3.5 Mbit/s file. That's an extreme example; usually it comes in pretty close to what you asked for. And, if you do have a hard limit you must hit, you can set the maximum and average bit rates to the same value.

The optimized Q mode is based on 4 parameters: maximum bit rate, high and low bounds for average, and target Q. This mode sacrifices some of the quality of the plain CQ mode to gain a bit of predictability. If you set the high average bound and the maximum bit rate to the same value and the low average bound to 0, you get the same file as if you'd used the CQ mode. As you increase the low average bound and decrease the high average bound, the generated stream's bit rate becomes constrained with respect to the ideal bit rate for the Q level you've set; in other words, you begin losing quality. This mode is best used when you are making files for SVCD, DVD or similar media: you have a definite maximum bit rate, you have a desired quality level, and you have a bit rate range you'd like the encoder to stick to, on average.


Frame 0, Frame 1, Bitrate and Quantization Data.

I used the standalone encoder in CQ mode to make these frame grabs.

Do some flip comparisons between these frames and TMPGEnc's: they're almost indistinguishable. Granted, some tiles have artifacts in one frame and not in the other, but this is just tit for tat: the artifacts seem pretty well distributed between the two encoders.

Previously I used the Premiere plugin, which, in CQ mode, gives a constant Q curve like TMPGEnc and Vitec's MPEG Maker do. I've since switched to the standalone version, which doesn't have a constant Q curve in CQ mode, a behavior I consider more than a little odd. Anyway, you'll have to take my word that video made by Ligos' Premiere plugin gives a nearly-identical bitrate curve to TMPGEnc, but with a lower Q level. This means that the Ligos encoder used more accurate DCT coefficients in constructing each frame, and still managed to produce frames the same size as TMPGEnc's, on average. Though this doesn't seem to make a visible change, this might be important if you wanted to use an MPEG editor on the files, since the Ligos would probably come through with fewer re-coding artifacts around the cut points.

Bottom Line

If you can spend $180-250, I can't think of a better encoder to spend it on than one of the LSX-MPEG encoders. The plugin is the fastest encoder in this roundup, and the standalone version rates a respectable third place (if you consider both CCE encoders as tied for second place). These encoders have top-flight video quality, they have a very good level of configurability, and they have intelligent, straightforward interfaces.

When choosing between the various LSX-MPEG editions, you can first eliminate the CBR-only LE plugin. If you are truly so strapped for cash that you can't afford the full plugin, I recommend buying the standalone version and lashing it to Premiere through Avisynth's Premiere plugin. If you want more convenience or speed than that lash-up gives you, spending the extra $70 is a better idea than settling for the LE plugin. Aside from a lack of cash, the only other reason I can think of to get the standalone version over the full Premiere plugin is that you don't have Premiere and don't plan on getting it.

Usability: 10
Functionality: 9
Quality: 10
Core Value: 10
Bundle value: 2

Overall: 9.5

(The "bundle" score is 2 because the full plugin and standalone versions include an MPEG player application.)

Updated Mon Sep 22 2008 12:15 MDT Go back to MPEG Encoder Reviews Go to my home page