Is 3 passes really enough??

[narco220]

This would be to shrink a source dvd or 7.4gig into a dvd5
4.3gig

Is 3 passes enough for over 6gig? I have also been using Bitrate Redistribution.

I use CCE SP and want to get the best possible quailty i can.

[chickenmonger]

I'd say it depends on your hardware and how long you're willing to wait. I have an Athlon XP 2200+ (1800 Mhz), and it usually takes between 380 and 450 minutes to do HC 2-pass encoding. That's about the upper bound of how long I'm willing to wait for quality.

I'd only switch to N-pass encoding if I had a faster processor, and even then, the benefits of N-pass encoding are subjective at best, and non-existent at worst.

EDIT: Also, the fact that I don't have CCE or DVD-RB Pro makes N-pass encoding an unavailable option.

[steptoe]

I use 3-passes with CCE SP2, and thats fine for me, but I don't have a huge 42" plasma TV to notice things that you wouldn't on a 26" CRT TV

Some say 6-passes is better for fast motion or high complexity scenes, and people have reported better results when doing movies like Star Wars and Lord of The Rings

Even CCE makers say anything above 3 passes is really too much and just adds time with not a great deal in quality, but the options there


Anything over 2-pass means the software is scanning the source tweaking it to a finer level for every extra pass, so in a way more passes could help in sources that need to squeeze every last bit out of the source

[narco220]

I'll give 5 passes a go then as thats just the problem im getting blocky pixels with fast movement.

[archaeo]

Sorry, but I cringe when I see another thread starting to move into that endless debate on what are the optimal 'number of passes' in CCE. :eek:
No offense, but this really has been exhaustively covered in this forum and others (the old CCE forum) at Doom9. It usually comes down to a matter of personal opinion (of which of course I won't mention mine to avoid further debate). To help this move along and prevent redundancy, I did a quick search on this topic, and came up with dozens of threads, a few of which are here:


http://forum.doom9.org/showthread.php?t=87831&highlight=CCE+Passes

http://forum.doom9.org/showthread.php?t=122581&highlight=CCE+Passes

http://forum.doom9.org/showthread.php?t=123135&highlight=CCE+Passes

[Fishman0919]

This is from a test I did with CCE SP/SP2.. I post just the SP result because the scores were the same...

Time Size PSNR Score
--------------------------------------------------------------------------------------------------------------
CCE Basic 2.70 | :59 sec| 25,588 KB | 45.2893
--------------------------------------------------------------------------------------------------------------
CCE SP 2.70 | | |
2-pass AQM | 1:00 | 25,611 KB | 45.3050
--------------------------------------------------------------------------------------------------------------
2-pass no AQM | :59 | 25,609 KB | 45.3133
--------------------------------------------------------------------------------------------------------------
3-pass AQM | 1:29 | 25,668 KB | 45.3217
--------------------------------------------------------------------------------------------------------------
3-pass no AQM | 1:29 | 25,687 KB | 45.3597
--------------------------------------------------------------------------------------------------------------
4-pass AQM | 1:59 | 25,676 KB | 45.3287
--------------------------------------------------------------------------------------------------------------
4-pass no AQM | 1:59 | 25,659 KB | 45.3535
--------------------------------------------------------------------------------------------------------------
10-pass no AQM | 4:59 | 25,669 KB | 45.3553
--------------------------------------------------------------------------------------------------------------
100pass no AQM | 50:46 | 25,669 KB | 45.3553
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
OPV Q-40 | :30 | 25,357 KB | 45.4022
------------------------------------------------------------------------------------------

after 4 passes the score did not change. This was the same on several test.

[narco220]

The reason i ask this question is when i shrunk the original dvd9 with dvdshrink and then dvdrebuild with cce sp2 (3 passes) there was very little if any difference when viewing them both on my sony vaio laptop as in both looked blocky in fast movement.

Heres some info on the Source and would it be considerd a high or low bitrate?

[13:19:29] Phase I, PREPARATION started.
- DVD-RB v1.26.2
- AVISYNTH 2.5.7.0
- CCE 1.0.0.15 encoder selected.
- Source: VIDEO_VTS
- VTS_01: 2,749,908 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 246,299 frames.
-- Building .AVS and .ECL files
- VTS_02: 542,803 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 48,609 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 64.4%
- Overall Bitrate : 3,393/2,714Kbs
- Space for Video : 4,075,268KB
- HIGH/LOW/TYPICAL Bitrates: 8,808/1,178/2,714 Kbs

[RickA]

Not sure if you going for a full disc or movie only dub. If the numbers you have posted are for a full disc w/ extras copy I would definitely go the movie only route. If they are movie only stats then you may be stuck with what you have. Unless you care to brave layer breaks on a dual layer disc.


*Added: I would consider your typical bitrate of 2,714 Kbs as low (even your overall bitrate of 3,393). I prefer a minimum typical of 3,500 plus where ever possible. Depends on the amount of action in the movie and how long the movie is. For instance if the movie is a couple hours of fast Matrix style action compared to ducks lazily swimming across a pond 2,714 Kbs will be hard pressed to cut it. IMVHO

[archaeo]

The reason i ask this question is when i shrunk the original dvd9 with dvdshrink and then dvdrebuild with cce sp2 (3 passes) there was very little if any difference when viewing them both on my sony vaio laptop as in both looked blocky in fast movement.

Heres some info on the Source and would it be considerd a high or low bitrate?

[13:19:29] Phase I, PREPARATION started.
- DVD-RB v1.26.2
- AVISYNTH 2.5.7.0
- CCE 1.0.0.15 encoder selected.
- Source: VIDEO_VTS
- VTS_01: 2,749,908 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 246,299 frames.
-- Building .AVS and .ECL files
- VTS_02: 542,803 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 48,609 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 64.4%
- Overall Bitrate : 3,393/2,714Kbs
- Space for Video : 4,075,268KB
- HIGH/LOW/TYPICAL Bitrates: 8,808/1,178/2,714 Kbs



@narco220:

I believe you said you are doing bitrate redistribution? - Can you post your redistribution log to see what bitrate the blocky segments are allocated?

[narco220]

I Disabled bitrate redistribution and took it up to 5 passes but judging from your responces this ain't going to improve anything.

I did strip some of the dvds extras with VobBlanker but like to leave the menus and important extras in there.

Im working with DvdRB settings as default apart from adding passes to CCE SP2.

So all i really need to know is if theres any settings i need to change to improve the bitrate/quality of the overall finished Rip?

[archaeo]

I Disabled bitrate redistribution and took it up to 5 passes but judging from your responces this ain't going to improve anything.



It may not, but if you decide to do bitrate redistribution, and pinpoint the segments that are blocky (I assume not all of them are that way), you could cross check the bitrate allocation in the log to see if the bitrate is exceptionally low for those segments. It gives us more information.

[RickA]

You have a choice - movie only with the best quality you are going to possibly be able to get or degraded quality with extras and menus onboard. If the extras mean that much to you then I suggest putting them on a seperate disc. You can use Dvdshrink in reauthor mode to seperate them out and an authoring / menu creating program like TMPGEnc DVD Author for your extras and their menus.

Cheers

[dynamis]

This is from a test I did with CCE SP/SP2.. I post just the SP result because the scores were the same.

...

after 4 passes the score did not change. This was the same on several test.

is this 4 CCE passes or 4 rebuilder passes? thanks.

[Fishman0919]

is this 4 CCE passes or 4 rebuilder passes? thanks.

1 vaf +3 passes ... with CCE SP2 they have done away with showing the vaf pass when encoding... it show it as m2v or mpg not vaf

[dynamis]

ah.. i see. and what tool do u use to measure PSNR?

i was looking at the MSU Video Quality Measurement Tool just for fun, but had no idea what files to throw in there... (the vaf or something else?) and what files i can throw in there as the original. all i got is vobs... :confused:

[narco220]

It may not, but if you decide to do bitrate redistribution, and pinpoint the segments that are blocky (I assume not all of them are that way), you could cross check the bitrate allocation in the log to see if the bitrate is exceptionally low for those segments. It gives us more information.


I just rencoded again but this time with bitrate redistribution enabled and 3 passes.
So theres no way to tweak rebuilders settings to improve the quality of the details below?

[22:36:14] Phase I, PREPARATION started.
- DVD-RB v1.26.2
- AVISYNTH 2.5.7.0
- CCE 1.0.0.15 encoder selected.
- Source: GRABIT DOWNLOADS
- VTS_01: 3,042,596 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 249,782 frames.
-- Building .AVS and .ECL files
- VTS_05: 107,472 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 12,906 frames.
-- Building .AVS and .ECL files
- VTS_07: 202,685 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 18,185 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 64.2%
- Overall Bitrate : 3,619/2,895Kbs
- Space for Video : 4,140,194KB
- Redistributing using Base_Q: 34
- HIGH/LOW/TYPICAL Bitrates: 4,506/1,732/2,895 Kbs


BITRATE APPLIED TO FEATURE SEGMENTS (SEGMENT ORIGINAL REDISTRIBUTED)
(Created using a 10% sample)

V01000000001001 2,846 Kbs 2,707 Kbs
V01000100001002 2,943 Kbs 3,039 Kbs
V01000200001003 2,956 Kbs 2,546 Kbs
V01000300001004 2,962 Kbs 2,571 Kbs
V01000400001005 2,954 Kbs 1,732 Kbs
V01000500001006 2,962 Kbs 2,796 Kbs
V01000600001007 2,957 Kbs 2,429 Kbs
V01000700001008 2,962 Kbs 3,685 Kbs
V01000800001009 2,961 Kbs 3,298 Kbs
V01000900001010 2,960 Kbs 2,946 Kbs
V01001000001011 2,961 Kbs 3,142 Kbs
V01001100001012 2,957 Kbs 2,592 Kbs
V01001200001013 2,912 Kbs 3,773 Kbs
V01001300001014 3,429 Kbs 119 Kbs

[Fishman0919]

V01000000001001 2,846 Kbs 2,707 Kbs
V01000100001002 2,943 Kbs 3,039 Kbs
V01000200001003 2,956 Kbs 2,546 Kbs
V01000300001004 2,962 Kbs 2,571 Kbs
V01000400001005 2,954 Kbs 1,732 Kbs
V01000500001006 2,962 Kbs 2,796 Kbs
V01000600001007 2,957 Kbs 2,429 Kbs
V01000700001008 2,962 Kbs 3,685 Kbs
V01000800001009 2,961 Kbs 3,298 Kbs
V01000900001010 2,960 Kbs 2,946 Kbs
V01001000001011 2,961 Kbs 3,142 Kbs
V01001100001012 2,957 Kbs 2,592 Kbs
V01001200001013 2,912 Kbs 3,773 Kbs
V01001300001014 3,429 Kbs 119 Kbs

Those bitrates are a little low.... try encoding with HC, AQE or QuEnc and maybe QLB Matrix... to me they do a better job at lower bitrates then CCE

[archaeo]

V01000400001005 2,954 Kbs 1,732 Kbs


@narco220:
Is this the only segment that has given you the trouble? This one obviously stands out. In addition to trying Fishman's advice above, you could also tweak that particular segment in RB's segment editor by bumping up the bitrate allocation for that segment. Of course it will have to come from somewhere so you'll be robbing peter to pay paul, but the other segments might be able to afford the bitrate loss, possibly.

[jdobbs]

Just as an added note: I would challenge anyone to find a way to tell the difference between a PSNR of 45.30 (2 pass) and 45.32 (4 pass) without the help of the numbers...

It is my firm recommendation, based upon hundreds of tests, that most discs should be done with two passes, and only rarely, on very hard-to-encode sources you may want to use three passes.

Of course, for those who have spare CPU time -- the extra passes don't hurt at all and it may make you feel better... so to each his/her own.

[Fishman0919]

Just as an added note: I would challenge anyone to find a way to tell the difference between a PSNR of 45.30 (2 pass) and 45.32 (4 pass) without the help of the numbers...

100% agreed. I do 3 passes with CCE just for the fact of size issues every once in awhile. If it wasn't for that I would do 2 passes all the time.

[Boulder]

As I always say, 2 passes for non-AQM, 3 for AQM. 2 passes would probably be enough for AQM and a regular source but 3 passes will make sure there'll be no undersizing if the source happens to compress a lot. If you don't have the time to wait, 2 passes should be enough to maintain good quality in any case.

[Wombler]

I Disabled bitrate redistribution and took it up to 5 passes but judging from your responces this ain't going to improve anything.

I did strip some of the dvds extras with VobBlanker but like to leave the menus and important extras in there.

Im working with DvdRB settings as default apart from adding passes to CCE SP2.

So all i really need to know is if theres any settings i need to change to improve the bitrate/quality of the overall finished Rip?

Well if you really need to keep all that then you might like to try one or more of these tricks prior to compressing.

Use VobBlanker to convert the menus (or if you prefer just the sub-menus) to stills if they aren't like that already.

It's surprising how much space you can recover from fully animated scene selection menus etc.

Disable movie company pre-movie intros and/or unnecessary credits at cell or even sub-cell level with VobBlanker.

Use PGCEdit to scan for and remove any uncalled PGCs then follow up with FixVTS (or VobBlanker) to recover the space. I'd recommend this one regardless of what you're keeping.

If you're up to it and they're included on the disc then you can also remove foreign menus and disable the buttons that select the foreign menus with PGCEdit.


Wombler

[Wombler]

Just as an added note: I would challenge anyone to find a way to tell the difference between a PSNR of 45.30 (2 pass) and 45.32 (4 pass) without the help of the numbers...

It is my firm recommendation, based upon hundreds of tests, that most discs should be done with two passes, and only rarely, on very hard-to-encode sources you may want to use three passes.

Of course, for those who have spare CPU time -- the extra passes don't hurt at all and it may make you feel better... so to each his/her own.

That I'm glad to hear as I've done all my movies using CCE with 2 passes and have been pleased with the results.:)

'Saving Private Ryan' was the only one I wasn't entirely happy with in certain scenes but then it's a stern test of any encoder.


Wombler

[Sharc]

There have been some posts about the difficulty with Saving Private Ryan in the past. (I don't have this disc).
I wonder if anyone ever has tried redistribution on that difficult disc, and if so, did it help?

[jdobbs]

That's a good one to try with REDISTRIBUTION! I'll give it a go.

[Wombler]

That's a good one to try with REDISTRIBUTION! I'll give it a go.

I'll look forward to hearing the results.

When I last tried messing around with this one I wasn't as familiar with all the encoding options as I am now so I didn't try anything like this and decided I'd be better off just watching the original.

If you find the optimum settings I might give it another go myself. :)

The last time I looked at it the key areas to check for artifacts were the Omaha Beach scene on the boat prior to landing and on the beach itself.

There's another scene where they're marching in the rain and the noise of the rain transforms into that of gunfire. After the first bit of this scene, just as they enter the town, is another area full of glitches.

HTH


Wombler

[Boulder]

It would also be interesting to see what kind of outputs HC and CCE provide. Lots of smoke and dark scenes should provide a nice test between constant quality(OPV)- and constant quant-based redistribution methods.

EDIT: Hehe, 3000th post :p

[HKT3020_1]

That's a good one to try with REDISTRIBUTION! I'll give it a go.

Studios are pushing the limit. I just tried backing up House, M.D. Season 3 and the bitrates are really low. Any recommendations which filters I could use since I'm completely new to using them. :confused:
- "Adaptive Quantizer Matrices" is enabled.
- Source: HOUSE_SEASON_3_DISC_1
- VTS_01: 3,733,369 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 316,165 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 54.8%
- Overall Bitrate : 2,835/2,268Kbs
- Space for Video : 3,651,204KB
- Redistributing using Base_Q: 44
- HIGH/LOW/TYPICAL Bitrates: 4,725/1,571/2,268 Kbs

[Boulder]

Studios are pushing the limit. I just tried backing up House, M.D. Season 3 and the bitrates are really low. Any recommendations which filters I could use since I'm completely new to using them. :confused:
- "Adaptive Quantizer Matrices" is enabled.
- Source: HOUSE_SEASON_3_DISC_1
- VTS_01: 3,733,369 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 316,165 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 54.8%
- Overall Bitrate : 2,835/2,268Kbs
- Space for Video : 3,651,204KB
- Redistributing using Base_Q: 44
- HIGH/LOW/TYPICAL Bitrates: 4,725/1,571/2,268 KbsFirstly, enable CPU=4 by adding this line under [options] in rebuilder.ini: MPEG2SOURCE_OPTS=cpu=4

For filtering, try this one:


Degrain(sad=400,lim=2,ol=0)

function Degrain( clip c, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "lim")
{
blk = default( blk, 16 )
ol = default( ol, 4 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
lim = default( lim, 255 )
vbw1=MVAnalyse(c,isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(c,isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(c,isb=true,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(c,isb=false,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
return MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=1,plane=pl,limit=lim)
}
Raise lim for a stronger effect. For better motion estimation (but slower processing), use ol=4 or ol=8. You need the latest MVTools (avisynth.org.ru) for this function.

NOTE: I don't know how filtering works with telecined NTSC sources (that's what I assume House, M.D. is).

[HKT3020_1]

MVTools is not available on the website. Might I trouble someone for an alternative web address? Sendspace perhaps.

[Boulder]

What do you mean it's not there?

http://avisynth.org.ru/mvtools/mvtools.html

The download links are at the bottom of the long page. Note that I edited the function and fixed the default value for lim. A total brain fart on my behalf that was :p

[HKT3020_1]

Okay, my first time ever writing a script but here's what I managed so far.
Used notepad and copied this...

Degrain(sad=400,lim=2,ol=0)

function Degrain( clip c, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "lim")
{
blk = default( blk, 16 )
ol = default( ol, 4 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
lim = default( lim, 255 )
vbw1=MVAnalyse(c,isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(c,isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(c,isb=true,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(c,isb=false,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
return MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=1,plane=pl,limit=lim)
}
Then read an overview on AvsP and played the script back with MPC...
http://img295.imageshack.us/img295/6109/snapshot20070901194928yr4.png
Extracted MVTools to the Avisynth 2.5 - plugins folder in case you're wondering.
I just want to be sure before I actually run this since 3-passes or even 2 will take quite awhile on a 3hr 39m DVD. :o

[Boulder]

Try Degrain(last,sad=400,lim=2,ol=0).

EDIT: also post your complete script.

[HKT3020_1]

Here it is and also just so we're clear, the adjustments for ol=4 and raised lim would be in the area marked in bold?
Degrain(last,sad=400,lim=2,ol=0)

function Degrain( clip c, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "lim")
{
blk = default( blk, 16 )
ol = default( ol, 4 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
lim = default( lim, 255 )
vbw1=MVAnalyse(c,isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(c,isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(c,isb=true,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(c,isb=false,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
return MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=1,plane=pl,limit=lim)
}

[Boulder]

Yes, the parameters are set in the line that calls the function.

Does that work? If not, what does the avs script itself look like? There's no source loaded anywhere so I can't say what might be the problem - I use that very same function myself constantly.

[HKT3020_1]

Since I'm completely new to all this, I think I may be in over my head but I'm willing to learn.
Here is what my avisynth plugins folder looks...
http://img236.imageshack.us/img236/3954/avsscoe0.png
Also my dvd-rb folder...
http://img181.imageshack.us/img181/3843/dvdrbgo8.png
current avs script in the dvd-rb folder...
#------------------
# AVS File Created by DVD Rebuilder
# VOBID:05, CELLID:04
#------------------
LoadPlugin("C:\Program Files\DVD-RB PRO\DGDecode.dll")
mpeg2source("H:\D2VAVS\V01.D2V")
trim(296174,316163)
SeparateFields().SelectEvery(2,0)
ConvertToYUY2()
AudioDub(BlankClip())
As for source, I was hoping dvd-rb would handle that but correct me if I'm wrong.
If this is off topic then perhaps PMs might be appropriate.

[Boulder]

You must copy-paste your test script in the DVD-RB filter editor window, redo the prepare phase and then open any of the avs files in the D2VAVS folder. The problem is that you are not loading a source in your testscript - and DVD-RB is not using the function at all as you can see from the DVD-RB created avs script.

[HKT3020_1]

Filter editor is active and I knew it wasn't so easy.

http://img301.imageshack.us/img301/6441/snapshot20070903034406dp1.png

[Boulder]

Post the script you are using. The error message already tells you what you need to do.

[HKT3020_1]

The script is exactly as you suggested.
Firstly, enable CPU=4 by adding this line under [options] in rebuilder.ini: MPEG2SOURCE_OPTS=cpu=4

For filtering, try this one:


Degrain(last,sad=400,lim=2,ol=0)

function Degrain( clip c, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "lim")
{
blk = default( blk, 16 )
ol = default( ol, 4 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
lim = default( lim, 255 )
vbw1=MVAnalyse(c,isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(c,isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(c,isb=true,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(c,isb=false,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
return MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=1,plane=pl,limit=lim)
}

If this at all helps, here is what was in D2AVS folder...
#------------------
# AVS File Created by DVD Rebuilder
# VOBID:06, CELLID:01
#------------------
LoadPlugin("C:\Program Files\DVD-RB PRO\DGDecode.dll")
mpeg2source("H:\D2VAVS\V01.D2V", cpu=4)
Degrain(last,sad=400,lim=2,ol=0)
function Degrain( clip c, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "lim")
blk = default( blk, 16 )
ol = default( ol, 4 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
lim = default( lim, 255 )
vbw1=MVAnalyse(c,isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(c,isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(c,isb=true,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(c,isb=false,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
return MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=1,plane=pl,limit=lim)
trim(316164,316164)
ConvertToYUY2(interlaced=true)
AudioDub(BlankClip())

[Boulder]

You are missing the opening { and closing } in the function in the DVD-RB script. Compare the original function to what you have in the filter editor window.

NOTE: the script will be slowish ;)

[jdobbs]

The output in the D2VAVS file is missing the opening "{" and closing "}" of the function. There was probably a cut-and-paste error of some kind or it wasn't entered.

[Edit] Whoops, looks like Boulder beat me to the answer.

[HKT3020_1]

Silly me I didn't add an image of the script in DVD-RB, the { } are there. One of the things I learned in 1st year of programming years ago, one little mistake throws it all off which is why I just copied and pasted.

http://img73.imageshack.us/img73/8/untitled1wm3.png

[Boulder]

Well, you can cut this part and paste it in Notepad and save as degrain.avsi in your plugins folder. Then simply call it using the Degrain line in the filter editor, no need to have the actual function there. That way it should work (it's what I actually use). Just make sure Notepad doesn't put .txt as the extension, it needs to be .avsi.

function Degrain( clip c, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "lim")
{
blk = default( blk, 16 )
ol = default( ol, 4 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
lim = default( lim, 255 )
vbw1=MVAnalyse(c,isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(c,isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(c,isb=true,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(c,isb=false,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=1,sharp=sh,overlap=ol,divide=div)
return MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=1,plane=pl,limit=lim)
}

[jdobbs]

Interesting that the "{" didn't show up. Can you post your REBUILDER.INI so I can see if it is correctly represented there?

[HKT3020_1]

Well, you can cut this part and paste it in Notepad and save as degrain.avsi in your plugins folder. Then simply call it using the Degrain line in the filter editor, no need to have the actual function there. That way it should work (it's what I actually use). Just make sure Notepad doesn't put .txt as the extension, it needs to be .avsi.

So the filter editor in dvd-rb should read like this...
Degrain(last,sad=400,lim=2,ol=0)

Interesting that the "{" didn't show up. Can you post your REBUILDER.INI so I can see if it is correctly represented there?
Here it is jdobbs...
http://www.sendspace.com/file/6k03p1

[jdobbs]

The sendspace server holding it is at capacity... I'll look at it some other time.

[Boulder]

So the filter editor in dvd-rb should read like this...
Degrain(last,sad=400,lim=2,ol=0)Yes, the function itself is automatically imported when the file containing it has the .avsi extension and is in the plugins folder.

[HKT3020_1]

I suppose it worked and you guys weren't kidding, talk about slower processing...:(
- AVS Filters are enabled.
- "Adaptive Quantizer Matrices" is enabled.
- Source: HOUSE_SEASON_3_DISC_1
- VTS_01: 3,733,369 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 316,165 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 54.8%
- Overall Bitrate : 2,835/2,268Kbs
- Space for Video : 3,651,204KB
- Redistributing using Base_Q: 44
- HIGH/LOW/TYPICAL Bitrates: 4,725/1,571/2,268 Kbs
[19:26:52] Phase I, PREPARATION completed in 79 minutes.

[Boulder]

You could try something like RemoveGrain(mode=5,modeU=17).TemporalSoften(2,3,4,8,2) instead of Degrain for faster processing. You need the RemoveGrain plugin, TemporalSoften is an Avisynth internal function.

[HKT3020_1]

I don't understand why the encoding took so long, I had CPU resources to spare. I logged only 49% of CPU use and on average the speed on CCE was 0.51-0.53. :mad:
[23:41:49] Phase II ENCODING started
[03:30:44] Phase II ENCODING completed in 1669 minutes.
[03:30:44] Phase III, REBUILD started.
[03:46:22] Phase III, REBUILD completed in 16 minutes.
The DVD looked great by the way, thanks for all the help. :p

[Boulder]

Avisynth is not multithreaded and with slow scripts most of the CPU usage comes from Avisynth processing. That is, CCE spends most of its time waiting for Avisynth to serve the frames to encode.

Welcome to the 24hr club :p

[jdobbs]

Wow. I'm not sure I have that much patience.

[jdobbs]

There have been some posts about the difficulty with Saving Private Ryan in the past. (I don't have this disc).
I wonder if anyone ever has tried redistribution on that difficult disc, and if so, did it help?I tried this again with REDISTRIBUTION using CCE. It actually came out worse than the one that wasn't redistributed. The bitrates didn't change dramatically (a surprise to me), and two of the segments came out too low, causing blockiness.

I'm testing now with HC.

[Sharc]

I obtained good results - for my eyes - for SPR (PAL) with the following settings:
- Encoder: CCE (for redistribution and encoding)
- Filter: cpu=4 (efficient suppression of macroblocks, with loss of some details in flat areas)
- Redistribution enabled, 2-pass encoding
- Matrix: Number 6 of RME (for redistribution and encoding)
- Q_final for redistribution = 107
- Cell 9 manually tweaked to 1300 (instead of 805, which is apparently too low, causing blockyness)

Overall reduction was 62.5%.
I selected Q_final for redistribution because I noticed significant differences in the redistribution profile between Base_Q (34) and Q_final (107) for HC/lumgain1 during my tests. Q_final produced similar profiles for CCE and HC, even for different matrices, so I felt more comfortable using Q_final.

[tom942]

@Sharc

Where do you get "Q_final", with RB-OPT?.

[Sharc]

Yes.
You might also get it from DVD-RB using OPV.
I didn't try the encoding with Base_Q (34) profile of DVD-RB, so I don't know how the result would have been. From earlier tests I found the risk of a cce crash during redistribution to be lower with a higher Q. That's another reason why I went straight to Q_final (=107 for matrix #6).

[JohnGalt]

@Sharc

That error should have been addressed in 1.26.3, unless you're talking about some other problem.

- Added an option to the MODE menu in which you can choose to always use HC as the encoder for REDISTRIBUTION. This prevents a rare CCE problem that can happen when high bitrate matrices are in use.

[Sharc]

@JohnGalt
Yes.
I found the HC profile with Base_Q (34) to be a little "flat", and in particular much different from the profile with HC or CCE for Q=107 and the said matrix. But as I said, I didn't try the encode with Base_Q and HC for redistribution, so I cannot judge the result. May be I will try later.
I just posted a setting which I found to produce a reasonable result for a difficult disc (long duration, film grain, smoke, dust, water, action). There might be better settings, though.

[jdobbs]

Could you show me an example of the difference between the distribution (in bitrate) between the two Q values? I wouldn't have thought it would be significant.

[Sharc]

Here 2 graphs for comparison:
Both using HC for redistribution, but with different Q.
Matrix for redistribution was mpeg standard in this case.
I have seen this dependence of Q in other cases as well.

If, however, the Q is selected such as to yield the same file size (Q_final for example for a DVD-5), the redistribution profile becomes almost independent of the matrix and the encoder. That's the reason why I normally prefer Q_final for redistribution. Because Base_Q and Q_final are for standard matrices often similar, the difference in the redistribution profile is normally not so obvious. The effect is more pronounced for high bitrate matrices.

[kumi]

I can confirm everything Sharc has said about the Base_Q<->Q_final discrepancies. It's the reason I use RBOpt for any projects that don't use the default matrix, since it calculates Q_final and applies it to redistribution.

I wonder if jdobbs would consider adding a Q calculation step to the redistribution process. It would make it safe to redistribute using custom matrices.

[jdobbs]

I'd have to be convinced that it would actually make it better (I'm not yet). I'd suggest in the example given that cell 9 looks really, really bad (mine did, if this is SPR -- and it had the higher of the two bitrates). Big swings aren't necessarily a good thing.

[Sharc]

I agree that big swings do not simply guarantee best results. However, I have seen - for high bitrate matrices - that Base_Q (or any Q which is significantly lower than Q_final) produces very flat curves (CBR like), much flatter than the standard 2-pass VBR mode. It also appears that these are the cases where CCE in tendency aborts and HC slows down - in particular when the VBV check is enabled. This made me put a little question mark.

Cell 9 in SPR appears to be an exceptional case which requires manual tweaking. Perhaps one should introduce a minimum bitrate parameter in the rebuilder.ini (e.g. 1300) to prevent redistribution from suggesting unrealistic low bitrates?

Added:
Could it be that a low Q in combination with a high bitrate matrix simply drives the bitrate to excessive high values? What does the encoder do then? Set the bitrate to the maximum compliant with the mpeg standard? Could this be the reason for "flat" redistributions? Or does the encoder crash? .... ??

[archaeo]

Just a note - attachment is still pending approval - still not able to see what Sharc has posted - thanks

[Wombler]

I obtained good results - for my eyes - for SPR (PAL) with the following settings:
- Encoder: CCE (for redistribution and encoding)
- Filter: cpu=4 (efficient suppression of macroblocks, with loss of some details in flat areas)
- Redistribution enabled, 2-pass encoding
- Matrix: Number 6 of RME (for redistribution and encoding)
- Q_final for redistribution = 107
- Cell 9 manually tweaked to 1300 (instead of 805, which is apparently too low, causing blockyness)

Overall reduction was 62.5%.
I selected Q_final for redistribution because I noticed significant differences in the redistribution profile between Base_Q (34) and Q_final (107) for HC/lumgain1 during my tests. Q_final produced similar profiles for CCE and HC, even for different matrices, so I felt more comfortable using Q_final.

I've tried SPR again myself and your settings are definitely better than my original effort.

I'm glad I suggested this film as it's proving very interesting for the experts and educational for me.:)


Wombler

[Wombler]

Cell 9 in SPR appears to be an exceptional case which requires manual tweaking. Perhaps one should introduce a minimum bitrate parameter in the rebuilder.ini (e.g. 1200) to prevent redistribution from suggesting unrealistic low bitrates?


Is it not a bit difficult though to determine either if the bitrate is unrealistically low or if the source just happens to be highly compressible?

Credits/intros or fade-ins/fade-outs can in certain instances drop to very low bitrates without any substantial deficit.

If you specify a minimum bitrate that's possibly too low then you risk not optimising the remainder of the film.

I suppose the key would be finding a happy medium between the two.

Sounds like a good idea though.


Wombler

[Boulder]

I wonder if that ninth cell is the one that required some manual intervention (=using CCE and tweaking the .vaf file after the first pass) before it looked good when encoded. The encoders seemed to allocate too few bits there no matter what the matrix or the other settings were.

SPR also has a very low avg bitrate for such a bitrate-hungry material, which will make things even more difficult. I have one CBR-encoded TV series DVD where redistribution also makes one scene look really bad (smoke, flat greenish colours). Then again, the other scenes look much better than with a non-redistributed encode. It's a kind of "choose your poison" decision there.

[Sharc]

@Wombler:
It is a compromise, yes.
The lowest redistributed cell bitrate I have seen so far without producing artefacts is around 1000 kbps (dark scenes, like in WTC). Even end credits are normally higher. If one goes below 1000, even simple dark scenes tend to collapse. If we would now lift the 1000 to "luxury" 1300 that wouldn't cannibalize the rest of the movie much, since there are not many "1000 scenes" anyway.
Just some thoughts. Might require more tests though.

[Sharc]

I wonder if that ninth cell is the one that required some manual intervention (=using CCE and tweaking the .vaf file after the first pass) before it looked good when encoded. The encoders seemed to allocate too few bits there no matter what the matrix or the other settings were.
Yes, exactly. It helped to manually set the average bitrate of that cell to 1300 - the original redistributed bitrate was in the range 800 .... 1200.
1300 brought it just around the corner, sort of a threshold effect.

[jdobbs]

The idea, though, is to create a process that doesn't require manual intervention. The majority of users only want to check the option, and not have to review the data to see if it is good or bad. The process should result in the assumption of "good".

The problem with setting a "minimum" bitrate is that there are so many exceptions. What happens when all the segments are under the minumum? What happens when the total of the ones under the minimum creates an oversize? When you raise the bitrate for one that doesn't meet the minimum you have to steal the bits from somewhere else... where? etc and so forth...

[Sharc]

Sure, if the process can be automated, the better.
Actually I thought it could be automated:
After the prepare the bitrates are known. The ones below the minimum would be raised to the minimum, the required bits would be stolen in proportion from the rest. I agree, not so straightforward. I also do see the problem with the "right" value for the minimum. It depends for example on the encoder.

I am just about to encode SPR with HC, matrix #6, redistribution with Q_final=107, and cell 9=680 (!). The test encode of cell 9 at 680 kbps looked surprisingly good .... may not require much tweaking, if at all ....

[kumi]

Just a thought: are we sure there isn't a CCE-specific problem when redistributing? I wonder if someone with SPR has tried redistributed it with HC, and checked whether or not cell 9 needs manual bitrate adjustment.

[Sharc]

See graphs above for HC. The low bitrate for cell 9 is not specific to CCE. CCE and HC produce similar low values for that cell. HC however seems to cope much better with the very low bitrate. Just about to run an encode with HC ....

[jdobbs]

Cell 9 is an exceptionally dark cell, which contributes to the low bitrate... it distributes the same way (low) with CCE, HC, and Mencoder, so it's the process -- not the encoder that is the source of the problem.

[Fishman0919]

@jdobbs

Won't it just be easy and more accurate to do a full 2 pass encoding with the avg bitrate you need with whatever encoder you would like to use (that way you can see how that encoder deals with the entire movie) then get the bitrate for each segment from the full 1 file encoding.

It would be a much longer process but it would also be the most accurate.

[jdobbs]

That would work -- but I'll tell you honestly, the minimal benefits you get from REDISTRIBUTION really aren't worth all that effort. You'd be better to just not use it in a case like SPR. It does cell 9 (and the rest of the movie) just fine. I'm have occasional doubts as to whether I should have ever even included REDISTRIBUTION in DVD-RB. It is very definitely overused. It solves the problem of CBR sources or poorly encoded originals -- but that's a very rare occurance. Others, of course, may have different opinions.

[JohnGalt]

So it's best not to leave redist. on all the time? I've used the option for several backups now, and I've been quite pleased with the results thus far. Granted, Lynch's 'Inland Empire' looked rather shoddy, but no worse than the original -- the lo-fi DV was, after all, an aesthetic choice on the director's part.

[Sharc]

Not a 1-click method, but what I usually do is:
- Select a matrix which is slightly "lower bitrate" than the matrix of the original. This is often matrix #2 or #3 of RME. It helps to preserve the sharpness.
- Do redistribution and 2-pass encoding with that matrix, using Q_final.
- Very exceptionally I test or even tweak suspicious low bitrate segments after the redistribution -- cell 9 of SPR with cce has actually been the only exception in my experience where manual tweaking was really requested.....

IMHO this gives better results than any other > 3-pass standard method - what the original question of this thread was about.

Sure, the degree of noticeable improvement compared to the standard 2- or 3-pass mode depends on the source material and on individual perception/preference. It is sometimes difficult to improve something which is already very good .... :)

[jdobbs]

So it's best not to leave redist. on all the time? I've used the option for several backups now, and I've been quite pleased with the results thus far. Granted, Lynch's 'Inland Empire' looked rather shoddy, but no worse than the original -- the lo-fi DV was, after all, an aesthetic choice on the director's part.
You're fine leaving it on... except in the rare instance such as SPR. I'm adding some code for the next release the will help prevent radical changes like the one in cell 9.

[Wombler]

You're fine leaving it on... except in the rare instance such as SPR. I'm adding some code for the next release the will help prevent radical changes like the one in cell 9.

Ahh excellent. It's good to see something productive has come out of this thread.

Although DVD Rebuilder is that good now that it must be getting more and more difficult to find areas to improve on.


Wombler

[Sharc]

@jdobbs:
Would it be too difficult to add a parameter under rebuilder.ini options to select Q_Final rather than Base_Q?
To me it makes a significant difference on the quality and effect of the redistribution, especially for non-standard (high bitrate) matrices. I personally don't care much about the extra time required for Q_final calculation. Q_final needs not even to have the same accuracy as for OPV - if speed of calculation should be important.

[jdobbs]

I can add it as a hidden option, but is there any way you can show some PSNR or other data that might support the idea that it improves the quality? I've done a quite a bit of testing -- and it just doesn't seem to be supported from what I've seen. It seems to be something along the lines of "measuring with a micrometer and cutting with an axe".

I guess it doesn't hurt to add it though.

[jdobbs]

Ok. For the next release I've added a "REDIST_USE_FINAL_Q=n" parameter to the "[Options]" area of the INI. If set to 1, a set of prediction passes is run against the main movie vts (same as OPV). The Q from that prediction is used as the FINAL_Q value for REDISTRIBUTION. Not sure if it will definitively improve quality in any way -- but it surely won't hurt it, so "C'est la vie"...

[Sharc]

Thanks a lot. I guess I will set the new parameter to 1 .... :)

[jdobbs]

Yeah, I probably will too. :)

I'm testing it now. I had to make a couple of adjustments for when "Always Use HC..." was checked.

[kumi]

That's brilliant, thank you jdobbs :D

[JohnGalt]

Ok. For the next release I've added a "REDIST_USE_FINAL_Q=n" parameter to the "[Options]" area of the INI. If set to 1, a set of prediction passes is run against the main movie vts (same as OPV). The Q from that prediction is used as the FINAL_Q value for REDISTRIBUTION.

When the next release comes out, perhaps someone could write a short guide explaining all this? I've been following the redist. threads and have a vague handle on it, but I'm rather lost with this latest turn in the discussion regarding Q_FINAL vs. BASE_Q and so on.

Also, does this redistribution method take filters into acc't (or does it matter)? I almost invariably use Half+Half + KISS on extras.

[jdobbs]

Yes, filters are taken into account.

One of these days I need to write a complete user guide...

[stereo]

When the next release comes out, perhaps someone could write a short guide explaining all this? I've been following the redist. threads and have a vague handle on it, but I'm rather lost with this latest turn in the discussion regarding Q_FINAL vs. BASE_Q and so on.

Also, does this redistribution method take filters into acc't (or does it matter)? I almost invariably use Half+Half + KISS on extras.

I second that. It would be great to have a short guide, because lately, I too have been pretty lost in the redist. area.

On that note: It would be great to have a guide - or a sticky - outlining all the hidden options that are now available.

[auldyin]

I echo the comment by stereo

Cheers

[Wombler]

One of these days I need to write a complete user guide...

That would be really useful as there's very little available elsewhere for the more technical stuff.


Wombler

[AGKnotUser]

You could try something like RemoveGrain(mode=5,modeU=17).TemporalSoften(2,3,4,8,2) instead of Degrain for faster processing. You need the RemoveGrain plugin, TemporalSoften is an Avisynth internal function.

Do you still need to add cpu=4?

[Boulder]

I'd still use that.

[AGKnotUser]

You could try something like RemoveGrain(mode=5,modeU=17).TemporalSoften(2,3,4,8,2) instead of Degrain for faster processing. You need the RemoveGrain plugin, TemporalSoften is an Avisynth internal function.

I read in the RemoveGrain docs: "RemoveGrain modes 1-10,17-25 are for truely progressive input only". Should Mode=5 be changed to another value for interlaced?

[Boulder]

You shouldn't use any mode of RemoveGrain directly with an interlaced source. There's a lot of threads which discuss dealing with interlaced sources.

[AGKnotUser]

Thank you, I'll look them up.

[Wodan]

Do you still need to add cpu=4?

where do i put cpu=4? in the rebuilder.ini ? also should the vbr bias always be set to 0? same with qual prec?

[Sharc]

In the rebuilder.ini under [Options] include the line
MPEG2SOURCE_OPTS=cpu=4

[HKT3020_1]

I wasn't exactly sure if a new thread should've been created. I'm new when it comes to mobile encoding with DVD-RB. I used the default options & the iPod preset 16:9 (640x360) 800kbs and saw heavy pixelation during fast moving scenes on the latest Season of Boston Legal. Any suggestions from long time mobile encoding users?
I have the latest 4GB iPod Nano if that helps. :confused:

[jdobbs]

I recently started using that profile too (for my iPod Touch). I noticed the default bitrate on that mobile setting is probably a little too aggressive and is likely to pixelate. I'd suggest you change it (upward). You do that by double clicking on the option in the mobile settings window, typing in the new bitrate, and saving.

[HKT3020_1]

I recently started using that profile too (for my iPod Touch). I noticed the default bitrate on that mobile setting is probably a little too aggressive and is likely to pixelate. I'd suggest you change it (upward). You do that by double clicking on the option in the mobile settings window, typing in the new bitrate, and saving.

The new bitrate should be? :rolleyes:
Also, is it worth it having DVD-RB run 2-passes for such a small device?

[jdobbs]

I played with it a little last night. One little trick: if you set the video bitrate to any value less than 32, DVD-RB assumes you want to encode with a constant quantizer. I set it to 5 and single-pass. It looks pretty good (good enough to watch on my iPod's 3 1/2" screen, at least) :).

[Rafterman]

I played with it a little last night. One little trick: if you set the video bitrate to any value less than 32, DVD-RB assumes you want to encode with a constant quantizer. I set it to 5 and single-pass. It looks pretty good (good enough to watch on my iPod's 3 1/2" screen, at least) :).



Could you elaborate. When I doubleclick on this option(16:9 (640x360) 800kbs) the default Video Bitrate is "704", you changed this to "5"? I'm probably reading this all wrong.

[jdobbs]

Yes. You change the video bitrate to "5". That will produce a constant quality encode with a quantizer value of 5.