first pass stats

[mescalino]

just to make sure
i can use first pass stats for encoding even if i change settings, for example bitrate
right?

[khp]

It's OK to change the bitrate a little (upto 30 %).
All other settings should be kept the same.

[mescalino]

so if i change bitrate for more then 30%, i need to do first pass again?
(i decided to make 2 cd rip; bitrate went from 599 to 1295)

[Enchanter]

If I remember right, nandub does its first pass at maximum bitrate input (6000kbps) and it does not take into account the input bitrate by the user. Hence, it should be alright to re-use the STATS file if all you are changing is only the bitrate.

[khp]

Um, yeah sorry. My previous posting only relates to divx5.

With nandub and Xvid for that matter, you can change the bitrate all you want. Because the first pass is always done at maximum quality.

[mescalino]

that's what i thought but i wasn't sure
thanks

[Enchanter]

Originally posted by khp
Um, yeah sorry. My previous posting only relates to divx5.

With nandub and Xvid for that matter, you can change the bitrate all you want. Because the first pass is always done at maximum quality.

Do you know why it is not the same case for DivX 5 (and 4, I'm sure)?

[khp]

I don't know exactly why DXN choose to do it diffrently.

I think there are both advantages and disadvantages to both methods. And I suppose it might have been a political decision, to do something diffrent from nandub just to set it apart.

Nandub dose it's first pass at maximum quality, does some bitrate curve compression to make highmotion scenes lower quality than lowmotion scenes, and scale down it's quality estimate to hit the desired bitrate. Durring the second pass this estimate is then subjected to slight corrections to make sure the desired filesize is matched as close as possible.
This perhaps has the disadvantage, that if the desired filesize, is much lower than maximum quality, nandub won't have a very detailed knowlede, of how high a quality setting, it can use to achive the desired filesize.
However it has the advantage that it always knows exactly how much data it has left to encode. Which makes it impossible for nandub to make the file the slightest bit undersized unless it has reached maximum quality.

Divx5 on the other hand, basically does a 1-pass bitrate controlled encode, durring the first pass. (except that the output is discarded and a log file is written instead). Durring the secondpass it then tries to ironout any malplaced quality adjustments made durring the first pass.
When encoding close to maximum quality this approach tends to make filesize prediction a bit more sketchy.

Does this make the slightest bit of sense, or am I just talking complete crap ?

[Enchanter]

In a way, it does make sense to me.

My understanding for nandub is that it runs the first pass at maximum quality and each frame in a given video stream will very likely reach their saturation point. Nandub will then 'plot' the maximum required bitrate for each frame from the said video stream in a STATS file. Knowing that they will all compress differently (some will require more bandwith while others require less), the plotted points will form a curve. The amount of bitrate required is not stored. Nandub will concern itself only with the shape of the curve aka. bitrate needed relative to other points (Y-axis) and the frame position/time (X-axis).

For the second pass, it makes use of the STATS file and determines the amount of required bitrate for a particular frame from the STATS file and user-input bitrate. What I'm trying to get at is that the amount of user-input bitrate is treated as line "Y = (bitrate)", around the middle (mean or median, I can't decide) of which the curve is redrawn according to the STATS file. Hence the amount of bitrate to be used for a particular frame (at position "X = frame position/time") is determined from the position of the curve (at position "Y=bitrate). Here, the other parameters under SBC settings (luminance corrections, curve compression, DRF, etc.) will play their part in influencing the final bitrate to be used for each and every frame. ==> I'm also grasping for words here, but I do hope you get the meaning.

Let's say that this DOES apply to nandub (I have not found any documentations on how exactly nandub operates), it is a very effective 2-pass encoding method although it will indeed have trouble with very-low-bitrate requests (where it will have to make HEAVY modifications to the bitrate curve to ensure that the low-motion scenes do not hit 0 kbps or below and the fast-motion scenes do not start dropping frames). Seems that I am of the same opinion with you.

As for DivX 5, the methodology you described seems pretty good, especially if the bitrate used is not changed too much. However, it does leave a lot of inflexibilities, such as the case when the encoder decided that he would go for a 2-3 CD rip instead of 1 CD. And frankly, I don't really see how the DivX 5 will manage low-bitrates any better than SBC (the first pass scan followed by the second pass' error and such correction seems more effective than nandub, but it should not make that much of a difference).

This is what I have in mind. I hope I'm not the one talking crap here.

[khp]

Originally posted by Enchanter

For the second pass, it makes use of the STATS file and determines the amount of required bitrate for a particular frame from the STATS file and user-input bitrate. What I'm trying to get at is that the amount of user-input bitrate is treated as line "Y = (bitrate)", around the middle (mean or median, I can't decide) of which the curve is redrawn according to the STATS file. Hence the amount of bitrate to be used for a particular frame (at position "X = frame position/time") is determined from the position of the curve (at position "Y=bitrate). Here, the other parameters under SBC settings (luminance corrections, curve compression, DRF, etc.) will play their part in influencing the final bitrate to be used for each and every frame.

I pretty much agree with all of this, I admit that my explanation overly simplified things.

Originally posted by Enchanter

(where it will have to make HEAVY modifications to the bitrate curve to ensure that the low-motion scenes do not hit 0 kbps or below and the fast-motion scenes do not start dropping frames).

I don't think nandub will start dropping frames, even if the rate control mechanism want to encode at a bitrate below 0kbps. In my thinking nandub first decides how may bits it can afford to spend on a particular frame, and then encodes the frame at the quality level it thinks will match the desired size. However this is restricted by the max/min DRF values.
The core of the encoding engine does not understand anything about bitrates, it only understand DRF's (called quantizers in divx5)

Originally posted by Enchanter

I hope I'm not the one talking crap here.

Not at all