Digital Video Forums

Go Back   Digital Video Forums > Video File Formats > AVI, DivX/Xvid

Reply
 
LinkBack Thread Tools Rate Thread Display Modes
Old 27 Nov 2002, 01:29 AM   #1
Member
Member
 
Join Date: Jun 2002
Posts: 70
Default first pass stats

just to make sure
i can use first pass stats for encoding even if i change settings, for example bitrate
right?
mescalino is offline   Reply With Quote
Old 27 Nov 2002, 07:59 AM   #2
khp
The Other
 
khp's Avatar
 
Join Date: Nov 2001
Location: Online
Posts: 2,161
Default

It's OK to change the bitrate a little (upto 30 %).
All other settings should be kept the same.
__________________
Donate your idle CPU time for something usefull.
http://folding.stanford.edu/
khp is offline   Reply With Quote
Old 27 Nov 2002, 09:28 AM   #3
Member
Member
 
Join Date: Jun 2002
Posts: 70
Default

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)
mescalino is offline   Reply With Quote
Old 27 Nov 2002, 10:57 AM   #4
Old member
 
Join Date: Feb 2002
Posts: 5,417
Default

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.
Enchanter is offline   Reply With Quote
Old 27 Nov 2002, 11:13 AM   #5
khp
The Other
 
khp's Avatar
 
Join Date: Nov 2001
Location: Online
Posts: 2,161
Default

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.

Last edited by khp; 27 Nov 2002 at 11:16 AM
khp is offline   Reply With Quote
Old 27 Nov 2002, 12:13 PM   #6
Member
Member
 
Join Date: Jun 2002
Posts: 70
Default

that's what i thought but i wasn't sure
thanks
mescalino is offline   Reply With Quote
Old 28 Nov 2002, 11:55 AM   #7
Old member
 
Join Date: Feb 2002
Posts: 5,417
Default

Quote:
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)?
Enchanter is offline   Reply With Quote
Old 28 Nov 2002, 01:29 PM   #8
khp
The Other
 
khp's Avatar
 
Join Date: Nov 2001
Location: Online
Posts: 2,161
Default

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 ?

Last edited by khp; 28 Nov 2002 at 01:34 PM
khp is offline   Reply With Quote
Old 28 Nov 2002, 03:42 PM   #9
Old member
 
Join Date: Feb 2002
Posts: 5,417
Default

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.
Enchanter is offline   Reply With Quote
Old 28 Nov 2002, 04:37 PM   #10
khp
The Other
 
khp's Avatar
 
Join Date: Nov 2001
Location: Online
Posts: 2,161
Default

Quote:
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.

Quote:
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)

Quote:
Originally posted by Enchanter

I hope I'm not the one talking crap here.
Not at all

Last edited by khp; 28 Nov 2002 at 04:41 PM
khp is offline   Reply With Quote
Reply

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




All times are GMT +10. The time now is 10:57 AM.

Kirsch designed by Andrew & Austin


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.6.0
Copyright © 1999 - 2011 Digital Digest

Visit DivXLand   Visit dvdloc8.com