TMPGEnc multipass encoding

[greengate69]

I am interested if any of the experts on here can shed some light on multipass encoding.

I believe in 2-pass encoding that the first pass is to analyse the input and allocate bits depending on the requirements (high motion vs low motion etc).

Assuming I have got that bit right, for more than 2-pass, what do the other passes do and how do they work? Does each pass progressively reduce the potential end file size ? Do they just jugle the bits around keeping the file size the same ?

The specific situation I am thinking of is encoding an XVCD of a >80minute input source (MPEG2 capture), to fit on a single 80 minute VCD. At present with TMPGEnc, using 2-pass VBR, I can set the output file size pretty accurately. I cannot go above 2-pass with TMPGEnc though (I think).

I am wondering if it would be possible to do a (e.g.) pseudo-4 pass encode by doing 2-pass encoding twice ?

If so, then is the logical thing to do the first 2-pass encode to the required final file size, and simply run the second 2-pass encode keeping the file size the same ?

Or would it be more logical to run the first 2-pass encode to reduce the file size to (e.g.) 120% of the final file size and the second 2-pass encode to trim it further to the final required size ?

Or are all the above assumptions wrong and does it make no sense to run 2-pass encoding twice !!

Cheers.

[ZippyP.]

Or are all the above assumptions wrong and does it make no sense to run 2-pass encoding twice !!

I would agree with the above quote. Re-encoding a file always results in a loss in quality. Multi-pass encoding doesn't really encode the video multiple times, it analyzes it multiple times and encodes once. I assume that more passes will give better bit allocation, up to a certain point, beyond which it isn't noticible anymore. Cinema Craft Encoder (CCE) does true multi-pass but is very expensive, I believe the lite version has that feature disabled.

[Vejita-sama]

The low vs high motion search has nothing to do with 2pass VBR. Here's the basic idea:

CBR - constant bitrate. During a CBR encode you set a bitrate and that bitrate is used for the entire video. It's easy to predict file size of your encoded MPEG. bitrate x runtime = filesize (Aside - notice that the bitrate is the only thing that affects file size, not motion search, size of your source file, or resolution).

The problem is that CDRs only hold 800MB (which is pretty small). And people want to put as much video as possible, at as high a quaility as possible, on each disc. The higher the bitrate the higher the quaility. But if I raise the bitrate I increase the file size, and that means less video (runtime) per CDR.

But when you think about it, a lot of the video is just people standing around doing nothing. Those low motion scences don't really need a high bitrate. I only really need to high bitrate during fast/motion scences.

(multiple pass) VBR - variable bitrate. Enter VBR, for a VBR encode you set a min bitrate, a max bitrate, and an average bitrate. The encoder will then lower the bitrate in low motion scences (but not below the min) and raise it in high motion scences (but not above the max). But do so such that the average bitrate works out to what you entered.

This means you can still predict file size. ave bitrate x runtime.

The first pass is normally a CBR encode, and the 2nd alliquots(sp) out the bitrate. Most people find that you get the best results encoding with multipass VBR by setting:

max = standalone players max (normally 2520kbit/s or so)
min = 300 or 500 (ie. REALLY low, to let the encoder play)
ave = # from bitrate caculator for desired final size of encode

TMPGenc only allows for 2pass VBR, the motion search setting tells TMPGenc how 'hard' to look for high vs. low motion scences. CCE allows for 5 (or is it 9) but most agree that anything about 3 (or 4) is just a waste of time.

As stated above you DO NOT want to re-encode your MPEG file. That will will always lower the quaility.

[DJRumpy]

Not necessarily a waste, but probably unnoticable accept for the most demanding quality freaks. After the first pass, the encoder starts allocating bitrate at the gop level. On additional passes, the encoder can allocate bitrate down to the macroblock level. The idea is that each additional pass lets you allocate bitrate better. If you reduce your average bitrate to get any particular movie to fit on an 80 minute CD, then each additional pass would improve the quality of output, since each pass lets the encoder better allocate bits per frame.

The only thing that will affect output size is your average setting. X number of bits per second will produce a file that is X in size. This is a constant. If you set a CBR encode to 997 kbits/s for an SVCD, and the movie was 1:30 minutes, then the output might look somewhat crappy because the encoder simply can't exceed the CBR bitrate value of 997 required to get the MPEG to fit on that 80 min CD, even though the encoder may require more to reproduce any particular scene accurately, and without artificats like macroblocking.

Using VBR, it can go as high as your max (2524 for SVCD for example), or as low as your min (0), allowing it to allocate bitrate to scenes that need it, and take away bitrate from scenes that don't need it. This could allow the encoder to allocate 2524 kb/s on a complex scene, while allocating 300 kb/s on a low motion/still scene. Because you specify an average setting, this average tells the encoder that no matter how much it borrows, it must balance the borrowed bits, giving them back somewhere so that the output file meets the AVERAGE setting.

The other benefit of multipass VBR is that the encoder doens't have to guess as to how much bitrate any particular gop needs. After the first pass, it knows exactly what is required for any particular gop. This is especially true of scene changes/fades. MPEG encoding works on a keyframe principal. At the start of every gop (group of pictures), there is a keyfame or I-Frame. This I-Frame is complete, with the entire frame encoded and reproduced. The next frame is examined. Any image detail that does not change from this I-Frame or image detail that is detected as 'moving', is not encoded in the next frame. Only new bits of information, or image detail that is not detected as motion of existing image are encoded. Say for example, that you had an video of a talk show, and only the host was moving in from frame to frame, then the background would not have to be re-encoded from frame to frame, until the next I-Frame was created. If the motion detection properly detected that the host's hand moved up slightly from one frame to the next, then it would not encode that image area either. It would simply log that the image in that area moved up X number of pixels. When the GOP was closed, and a new one was created, the entire frame would be encoded, including the background, host, everything. This new I-Frame is then used as the reference frame for the next Group Of Pictures (GOP).

Now think of a scene change. Since these types of frames usually jump from one scene to the next, with each frame looking completely 'new' to the encoder (it can't find any frame of reference to the original Key Frame), every frame after that requires bitrate to encode, because every bit of detail looks 'new', until the next keyframe is encoded. These 'new' frames can take up so much bitrate to produce that the overall image quality suffers, since there isn't enough bitrate to go around. With multipass, the encoder has forknowledge of these scene changes/fades, and can allocate bitrate/motion vectors properly to handle them.

Knowing this, for example, if GOP #17 is very low motion, and GOP # 52 has very high motion, then the encoder can reduce the allocated bitrate for 17 to a much lower bitrate. These saved bits can then be applied to GOP #52 to produce better image quality. Same thing for a scene change. If the scene changes on a CBR mpeg and it is not predicted properly, quality will suffer until the next Keyframe is generated. With forknowledge of the scene change, the encoder can force a new I-Frame (usually for a scene change), or better allocated bitrate to handle the change for something like a fade.

To do more than two passes, you would need to get an encoder that supports multipass above 2-Passes. CCE will do this. I'm not sure about MainConcept. TMPGenc does not support more than 2 passes.

[tphaggerty]

MainConcept is 1-pass VBR or CBR (supposedly going to have 2-pass in 1.4 release).

CCE Basic has CBR, 1-pass VBR and 2-pass VBR. Other versions of CCE support multiple (more than 2) passes for VBR.

ProCoder is CBR, 1-pass VBR and 2-pass VBR.

[DJRumpy]

Thnx tphaggerty. I wasn't aware that the MC Encoder didn't support more than one pass. Is this 1-Pass like CCE's, meaning it actaully makes 2 passes on the file. The first to gather info, and the second to encode?

[tphaggerty]

Not as far as I know. When you encode with MCE and view with BitRate, the variance is fairly small and tightly contained. It appears that MCE encodes VBR "within reason" so that it can reasonable correct itself if its running out of bitrate further down the stream.

Compare that to CCE or ProCoder (haven't tried with TMPGenc) 2-pass. The variability is much greater, normally with a much higher Max. It seems to indicate that they are much more aggressive at allocating bandwidth where needed - not just guessing. BitRate generally shows that both ProCoder and CCE have much lower overall Q values for the encoded video, although visually the results are similar. Except CCE Basic, of course, which I haven't yet been able to get to encode DV AVI without fuzziness.