Who wants to test a new MPEG2 encoder

[dragongodz]

it seems that at very or extremly high bitrates enabling only I-frame give the best quality.
i assume you mean not for dvd bitrates. why not disable B frames and set a short GOP length (try 5) as that should be pretty damn good. or are you failing to reach a target bitrate with that ?

[Spyn]

Originally posted by dragongodz
i assume you mean not for dvd bitrates. why not disable B frames and set a short GOP length (try 5) as that should be pretty damn good. or are you failing to reach a target bitrate with that ?

i just want to test mpeg2 vs mpeg4 (xvid) at very high bitrates (higher than 10000 kbits), b-frames are already disabled.

i would like to test an encode with HC at Q1 with I-frame only, i think this is the best quality possible for mpeg2.

Tmpgenc allow to enable I-frame only but don't allow bitrate higher than 15000 kbits or something like this.

[dragongodz]

i just want to test mpeg2 vs mpeg4 (xvid) at very high bitrates (higher than 10000 kbits)
you shouldnt really be able to tell any difference if both are using just I frames and Q1.

Tmpgenc allow to enable I-frame only but don't allow bitrate higher than 15000 kbits or something like this.
change the profile from MP@ML to MP@HL to use higher bitrates.

[LigH]

Somehow, I prefer practical over academical tests... :sly: ;)

[dragongodz]

Somehow, I prefer practical over academical tests..
i agree. especially considering, as i said,
you shouldnt really be able to tell any difference if both are using just I frames and Q1. :D

[DoctorRad]

Originally posted by video
please consider that different levels of file service access are provided by the os for local and remote files. there is no problem with reading, opening, but maybe not possible to seek freely within the file. sequential forward read guaranteed to work on unc remote files, however that's might be not enough to dgindex/avisynth. for proper support, i feel dgindex might be prepared to handle files from an unc...
Errr... yes... my stupidly large capture source file would appear to be the cause... all 16.3Gb of it. A 10-frame test file works fine.

Sorry for the noise!

Matt...

[hank315]

Tmpgenc allow to enable I-frame only but don't allow bitrate higher than 15000 kbits or something like this.HC is meant for DVD creation, it can't create clips with only I-frames, why should it?

But it can create clips with a bitrate higher than 15000:
- GOP length 2, no B-frames --> IPIPIPIP scheme
- Constant Q run with Q=1
- no VBV check
- Profile best
- Disable scene change

Bitrate is unlimited this way, might go as high as 30000 or more...
Just don't see the need to do it this way :confused:

[LigH]

Because it is not configurable (yet?): Which luminance range does HC expect?

According to my tests, it seems to use "PC scale" (0..255).

Some MPEG encoders allow to set the input range. Other MPEG encoders seem to silently expect "TV scale" (16..235). I'll have to check that again before choss-comparing several different encoders, else comparison results will be rather useless, I'm afraid...

[Spyn]

Originally posted by hank315

Just don't see the need to do it this way :confused:

I want to know which codec between mpeg2 and mpeg4 (xvid) is the best at Q1, at 20000 kbits, at 10000 kbits and at 5000 kbits.

To get the better quality at Q1 i need to enable only I-frames.

[Xesdeeni]

Originally posted by Spyn
To get the better quality at Q1 i need to enable only I-frames. I don't know where you get that information, but I'm pretty sure it's wrong.

I-frames are simply encoded with no reference to other frames. P and B frames are deltas from other frames. But that doesn't make I-frames inherently higher quality. As long as the encoder is reasonable, the quality of P and B frames can be equal to I frames. And P and B frames use fewer bits! (on average, P-frames use about half the bits of I-frames for the same quality, while B-frames use 1/3-1/4 the bits of I-frames for the same quality.)

Also, a P or B frame can be composed of macroblocks that are I-like, if the encoder determines that this is more efficient (e.g. at scene changes that do not force an I-frame). So the least common denominator for P and B frames is an I-frame structure.

In reality (again, assuming a reasonable encoder algorithm), you will not get better quality at a given bit rate using I-frames only. And you are likely to have less quality, since you are not using the bits as efficiently.

Think of it this way:

Assume you feed an encoder the same frame over and over and encode a 30 fps video at 10 Mbps. For I-frame only, each frame is individually encoded. That means each frame could use 10 Mb / 30 fps = 333 Kb.

If you use P and B frames, a good encoder will see that there is no difference frame to frame. It will encode the delta frames as having no change, which is a very small amount of data, and all the bits can be concentrated on the occasional I-frame. Assuming an 18 frame GOP, that means one I-frame every 18 frames, or 1.667 I-frames every second. That equates to 10 Mb / 1.6667 fps = 6 Mb.

Certainly the 6 Mb I-frame will be better quality than the 333 Kb one.

Edit: BTW, this same holds true for MPEG-4. P and B frames are your friends :)

Xesdeeni

[Spyn]

Originally posted by Xesdeeni

But that doesn't make I-frames inherently higher quality. As long as the encoder is reasonable, the quality of P and B frames can be equal to I frames.

wrong

15000 kbits encode, source = very good mpeg2

SSIM results :

I-frame only : 96.30
1 I-frame every 5 P-frame : 95.46
1 I-frame every 14 P-frame : 94.51
default : BBIBBP : 95.20

[LigH]

Does is make any sense to use an already once DCT-based quantized material? Better always use original material which has not yet been encoded with the same technique, especially not with worse quality than your test options. Re-quantization does not provide valuable results.

For example, VQEG test samples are available as raw UYVY files, if you don't own a capturing source.

[video]

I think intra-only mpeg comes into the play if you have a hardware mpeg2 digitizer board and you would like to end up with a capture what is seamless key frame editable/cuttable. More recently these kind of setups appliing CBR encoding schemes as well.

[LigH]

Indeed, I-frame only MPEG is cuttable at any frame. But most MJPEG AVI codecs may provide similar, if not even better, quality.

[video]

Originally posted by LigH
Indeed, I-frame only MPEG is cuttable at any frame. But most MJPEG AVI codecs may provide similar, if not even better, quality.

in the last third of 90ies i had a damn good PCI mpeg-2 capture card(refurbished broadcast device). at that times the 1GByte avi barrirer was a huge problem, no opendml, no avisynth, no DV. But with mpeg i was able to have even 8G-16G captures on NT4. :)

[Xesdeeni]

Originally posted by Spyn
wrong

15000 kbits encode, source = very good mpeg2

SSIM results :

I-frame only : 96.30
1 I-frame every 5 P-frame : 95.46
1 I-frame every 14 P-frame : 94.51
default : BBIBBP : 95.20 You are basing your presumption on at least three assumptions:

1. The encoder is a representative encoder.

As I said, if the encoder wants, it can encode P and B frames in a way that is identical to I-frames. But the fact that it apparently does not is not indicative that I-frames are superior either. It's only indicative of the algorithms in the encoder. It may even be indicative of errors in your decoder. Many more calculations are necessary for P and B frames, so there is much more room for the decoder (and encoder) to make mistakes.

2. SSIM is accurate.

Keep in mind that P and B frames end up encoding data in a different way than I-frames. Different isn't necessarily worse. But SSIM's self admitted ("the SSIM metric still isn't perfect") bias may be on errors that occur less often in I-frames. Specifically, there may be motion errors introduced due to motion vector-based compression. There may in fact be less spatial error due to Discrete Cosine or quantization (and most probably will, given there are more bits to use). But if the SSIM algorithm is more sensitive to motion errors, it will erroneously report a lower quality.

To see an example of this. Use a computer generated (i.e. noiseless) source of some object moving across the frame at some non-integral number of pixels (e.g. 3.3 pixels per frame). I believe MPEG-2 has only a 1/2 pixel motion accuracy, so the location of the object can be off by as much as that. But fractions of pixels are not necessarily worse to the eye than DCT/Q artifacts. How SSIM reacts to these errors may be quite different.

3. MPEG source is a good source.

The MPEG source already has artifacts created by the first encoding. If the second encoder encodes similiarly to the first, you might find fewer additional artifacts in the result. But if the second encoder uses a different technique, even if only for scene change (forced I-frame) encoding, the artifacts could be multiplied. And using I-frames may very will avoid any additional motion errors at all. But this is not an indication of the validity of the second encoder.


Don't trust hype or arbitrary measurements. Trust your eyes. And be careful to understand what effects you are inadvertently introducing into the process.

Xesdeeni

[Spyn]

Originally posted by Xesdeeni

Don't trust hype or arbitrary measurements. Trust your eyes. And be careful to understand what effects you are inadvertently introducing into the process.

Xesdeeni [/B]

I prefer to trust SSIM cause i think no eyes are able to make the difference between each files at this bitrate, mine can't...

and i don't think the encoder can encode P and B frames as good as an I-frame, i got a partially proof of this by the test i made, you has no proof except you're words...

[Xesdeeni]

Originally posted by Spyn
i don't think the encoder can encode P and B frames as good as an I-frame, i got a partially proof of this by the test i made, you has no proof except you're words... Try reading the MPEG-2 specification. Note that each macroblock can be encoded as an Intra block. Note that all I-frame macroblocks are Intra blocks.

As for a specific encoder and judgement tools, please use whatever criteria you prefer. But please understand that results from one encoder are not universal.

Xesdeeni

[Spyn]

Originally posted by Xesdeeni
Try reading the MPEG-2 specification. Note that each macroblock can be encoded as an Intra block. Note that all I-frame macroblocks are Intra blocks.

As for a specific encoder and judgement tools, please use whatever criteria you prefer. But please understand that results from one encoder are not universal.

Xesdeeni

I don't know what is an intra or non-intra blocks, i just know that a P-frame use colors that are same to the previous frame to save bits.

I think it use the same colors even if they are not exactly the same, for example for a RGB pixel 13-13-13 of a frame, if the same pixel of the next P-frame is 13-14-13, it would use the pixel of the previous frame.

so colors are not exactly the same and that's why, quality is worse.

this is difficult for me to say all that i want in english, i hope you undestand me...

[video]

Originally posted by Spyn
I think it use the same colors even if they are not exactly the same, for example for a RGB pixel 13-13-13 of a frame, if the same pixel of the next P-frame is 13-14-13, it would use the pixel of the previous frame.
You sholud have a very good CRT to see any differences betwwen color #0C0C0C and #0C0D0C. speaking about a TFT, they can do 6bits/channel and trying to display the remained 2 bits via dithering. Even best EIZO S-IPS panels are 6bit depht per channel. The do a histogram recolorize on the fly to achive better look than cheap models.

keep in mind that mpeg is a publication format, and therefore not suited for intermediate mastering/editing even when there are mpeg capable video editors.
there are far more better 'intra only' codecs outside, such as morgan's MJPEG 2000, DV, and the EBU videocodec

@hank315
Would it hurt to extend the encoder's resolution to 1920x1080/1440x1080? Just because i've got a sony cinealta for a while, and it produces masters in size what is too much for even a 300gByte harddisk :)

[skal]

Hi,

Originally posted by video
Would it hurt to extend the encoder's resolution to 1920x1080/1440x1080? Just because i've got a sony cinealta for a while, and it produces masters in size what is too much for even a 300gByte harddisk :)

gee... i'd be delighted if you could shoot few samples with that cam, at such hi-res, and make them available somewhere (not 300gByte of course;). Raw, unprocessed, material of that size is hard to find for tests...

bye!
-Skal

[Koepi]

That would really be nice for testing, agreed :-)

Looking forward to some proper input material... (not just always decoded mpeg2 sources.)

Cheers
Koepi

[video]

Originally posted by skal
Hi,



gee... i'd be delighted if you could shoot few samples with that cam, at such hi-res, and make them available somewhere (not 300gByte of course;). Raw, unprocessed, material of that size is hard to find for tests...

bye!
-Skal

I appreciate your request, but I moved to the rural area, so I've got a gsm phone what can do a 9600bps. At work there is http, but it's just incoming. however cinealta really ROCKS :) I really love heavy cams, what can be put on your shoulder ;)

[Spyn]

someone know where i can find an uncompressed source ?

[konst]

Hi,
Sorry for my English, my native language is Russian and for my, maybe, stupid question. I'm a newbie to MPEG2 encoding and to this forum.
HCmanual has 10 intra- / non-intra matrices and somes a little bit similar to each other. Tell me, please, common practical recommendation for use these various matrices.
For examle:
*MATRIX NOTCH - appropriate to "slow" noiseless interlaced source at low bitrate (~2000kbps), produce 'soft' slightly blured MPEG with less details in black area ...and so on;
*MATRIX BACH1 - appropriate to "fast", dynamic, noisy interlaced or progressive source at average bitrate (~4000 - 6000 kbps), produce 'sharp' MPEG with more details in black area ... etc.

May be will a good think include such information to HCmanual?

Or advise any links about this, please.

I've read above posted explanations of LigH, posts from http://forum.doom9.org/showthread.php?s=&threadid=89897 and other Google's links, but, as for me, this almost 'pure' theory and mathematics :-) and don't practical recommendations.

I want to test HC and compare it with Procoder2 and I think: more correct matrices -> more correct result.

Once again sorry and Big Thanks.

[gigaset2004]

@ konst

I think tht´s the wrong threat for your questions.

So it woulb be best to read several postings for your need´s

Short expl.

You could get more compression with the matrix you choose. Bute every encoder needs normaly a specail matrix to get best results.

Means get a DVD movie on a CD with 700 MB

I coul recommend the Quenc 59 beta 3 with the QLB matrix.

So that´s it with the basic.

But you need the avisynth and so on.........

[konst]

@ gigaset2004

Thanks for quick replay.


I think tht's the wrong threat for your questions

The thread's name: "Who wants to test a new MPEG2 encoder".
I want :-) I want also to receive best result for my source.

OK.
My source is mainly a DV (PAL, interlaced) produced by Canon XM2 at daylight; the target is a ~60 - 90min DVD with IPB GOP 12/3 or IP 12/2, 2-pass VBR, 720x576.
My source is sometimes a DV (PAL, interlaced) produced by ADVC-300 from an old VHS; the target is a ~120 - 180min DVD with GOP IPB 12/3, 2-pass VBR, 480x576.

HCmanual has matrices:
* Default - 83; 33 (values from low right in the corner intra- ; non-intra)
*MATRIX HC - 87; 79
*MATRIX NOTCH - 79; 44
*MATRIX QLB - 87; 34
*MATRIX BACH1 - 83; 44

Their intra- parts are a little bit similar to each other. As far as I've understood, the lesser values in the low right area the more accuracy encoder can provide in high frequency range, the accuracy in small details is more correspondingly.

HCmanual has others matrices a little bit similar to each other:
*MATRIX HVSGOOD - 115; 144
*MATRIX HVSBETTER - 115; 137
*MATRIX HVSBEST - 115; 129

The detached matrices:
*MATRIX JAWOR1CD - 84; 124
*MATRIX AUTOQ2 - 94; 99


Bute every encoder needs normaly a specail matrix to get best results.

What is the matrices are more appropriate for me in HC-encoder (in both case)?
My 'ancient' PC very slow for ALL matrices testing :-(


Means get a DVD movie on a CD with 700 MB
I coul recommend the Quenc 59 beta 3 with the QLB matrix.
So that's it with the basic.
But you need the avisynth and so on.........

Thanks, but so far I use my friend's Procoder2.
Are avisynth really don't needed for HC-encoder?

P.S. A DVD movie on a CD with 700 MB - that's cool :-)

[gigaset2004]

@ konst

So far, but your source is interlaced thats the biggest problem.

Normally the matrices are optimised to produce a good quality on progressive material.

You have to choose :

encode interlace material - needs more space.

deinterlace the material - needs a avisynth sript and more know how.

I recommend you to read all the material in the forums and pick up best for you.

After reading the next 3- 5 days you know more what you do.

Your way is not a 1-2 klick programm..........

In the geramn forum there are a few members they have made test with Dv material so take a look to traslate.

look for scharffis brain or Kika or mb1

[Abond]

Normally the matrices are optimised to produce a good quality on progressive material.
Huh? This is new for me...

[guada 2]

For me too...

[skal]

Hi Video,

Originally posted by video
I appreciate your request, but I moved to the rural area, so I've got a gsm phone what can do a 9600bps.

too bad, thanks anyway!

Ahowever cinealta really ROCKS :) I really love heavy cams, what can be put on your shoulder ;)

Stop that, i'm drooling ;)

bye!
-Skal

[konst]

@ gigaset2004
Thanks for your philosophizing.
I watch my interlaced material by ordinary interlaced TV and deinterlace the material in this case is incorrectly, imho.
I'll have to must to spend many days on testing of all matrices.

@ ALL
Sorry, i did a search before that was posted and could not find any practical recommendation, i should of tested all matrices before posting.

[jeanl]

Guys,
I'm a bit of a newbie, so sorry if my question seems naive, or has been answered somewhere else (I did search though!). I've been trying HC on some home-videos (DV-NTSC, interlaced), and I've noticed that the quality of the output goes up tremendously if I de-interlace the input prior to encoding. To do my comparisons, I was using HC Best quality to encode into MPEG (using the default MPEG matrices - is that the problem?) at VBR with an average of 7.5Mb/s (pretty high).
- When encoding the interlaced input, I selected "interlaced" and chose Bottom Field First (as expected I think).
- To encode a de-interlaced stream, I ran either a simple Bob() or better, TomsMoComp(), and of course, deselected interlaced in HC.

My question is:
- Is it normal that the results should be so much better on the de-interlaced material? I watched the output with PowerDVD on my monitor. On a frame-by-frame basis, the MPEG version is very close to the DV original, with very little blocking, and no combing. This was not the case when encoding the original interlaced video: I could see a lot of combing on the output in that case.
- Am I doing something wrong when I encode the interlaced material? Why do I see so much combing on the output?
- Is there a better way to do what I'm doing? (like I said, I'm very much a noob).

Thanks for any input!
jeanl

[rhayman]

Jeanl: I think this is because interlaced material requires higher bitrates because the image is more complicated when its interlaced.
So if you can encode at a high bitrate i think your supposed to keep the video interlaced.

If im encoding at low bitrates (2000-2500) i usually deinterlace too because you get less blocking.

Hopefully someone can explain it better. I dont really know that much about it.

[jeanl]

Originally posted by rhayman
Jeanl: I think this is because interlaced material requires higher bitrates because the image is more complicated when its interlaced.
So if you can encode at a high bitrate i think your supposed to keep the video interlaced.

If im encoding at low bitrates (2000-2500) i usually deinterlace too because you get less blocking.

Hopefully someone can explain it better. I dont really know that much about it.
Thanks rhayman, that's useful input. I do want to keep my video interlaced, so I think de-interlacing to get better quality is the wrong way to go about it in this case. I'll do some more experiments tonight.
Jeanl

[onesoul]

@jeanl

What you describe i weird, HC does a pretty good job on interlaced content for what I have tested.
Could you please give the avisynth script when encoding as interlaced, did you use any filters?
And btw did you use autogop on? Try gop 12 2.

What I don't see very clear is how could you see combing on powerdvd as it deinterlaces unless you told it not to.

Cheers

[FredThompson]

Since when does HC support interlaced source?

@jeanl,
If your source is interlaced and not a candidate for decombing, you really should leave it interlaced if at all possible. Deinterlacing removes half the temporal information, introduces visual mud and creates artifacts, no matter how good the deinterlacing routine. You just can't smash the equivalent of 50 (PAL) or ~60 (NTSC) distinct images into 25 or 30 images and keep the quality. It is not uncommon for the fields of a single frame of interlaced source to have very different content.

Decombing is different. If the original source was progressive, it's almost always a good idea to decomb.

Early video compression didn't support interlaced source. MPEG1 doesn't, as an example. MPEG2 does support interlaced source. However, as I mentioned at the top of this post, make sure HC supports interlaced source before you try to use it for that.

[onesoul]

Originally posted by FredThompson
Since when does HC support interlaced source? What? Have you tried HC? It has supported interlaced encoding from the beginning...
You can check the test I made with pal DVD interlaced source.

[jeanl]

Yes, there's no doubt that HC supports interlaced source. And no, my source isn't originally progressive, so I should definitely leave it interlaced. This confirms that I'm on the wrong path with my de-interlacing, and that the higher encoding quality that I seem to observe is probably the result of faulty comparisons (on a progressive display, my PC monitor!).
jeanl

[jeanl]

Originally posted by onesoul
What? Have you tried HC? It has supported interlaced encoding from the beginning...
You can check the test I made with pal DVD interlaced source.
onesoul, do you have a link to that test? Couldn't find it... I'd be interested to compare to what I get (although I'm NTSC :( ).
jeanl
EDIT: Never mind! I found them, really interesting! Thanks!

[onesoul]

The test still appears on first page of this forum (other mpeg1/2 encoder) and it is here (http://forum.doom9.org/showthread.php?s=&threadid=91405),
Clicking on www under my signature will redirect you to the test also.

I don't recommend using any filtering when encoding interlaced source (except for reinterpolate411() when using mainconcept dvcodec), it's too painful to do it the right way (takes too long and it's not 100% accurate).

[jeanl]

Originally posted by onesoul

I don't recommend using any filtering when encoding interlaced source (except for reinterpolate411() when using mainconcept dvcodec), it's too painful to do it the right way (takes too long and it's not 100% accurate).
so according to you, I should encode straight from my interleaved DV NTSC video, no pre-processing, and the results should be pretty good (especially at 6-7Mb/s), right? I'll try again tonight, and i'll try to be more careful in the way I compare the output.
jeanl

[onesoul]

Originally posted by jeanl
so according to you, I should encode straight from my interleaved DV NTSC video, no pre-processing, and the results should be pretty good (especially at 6-7Mb/s), right? I'll try again tonight, and i'll try to be more careful in the way I compare the output.
jeanl Yes. Please check back to us then.

[FredThompson]

Originally posted by onesoul
What? Have you tried HC? It has supported interlaced encoding from the beginning...
You can check the test I made with pal DVD interlaced source. Look at pages 13 and 14 of this thread.

[Ebobtron]

@FredThompson
Sorry, but I would remind you, about page 13, that a number of us tried to explain to you that HC encodes interlaced frames.

The error as I remember it was caused by feeding HC field based material.

HC has from the start done as good or better on interlaced sources as any other encoder I have tried. The only progressive input I have, I have to make as all my sources are captured camera or broadcast.

[jeanl]

Originally posted by jeanl
so according to you, I should encode straight from my interleaved DV NTSC video, no pre-processing, and the results should be pretty good (especially at 6-7Mb/s), right? I'll try again tonight, and i'll try to be more careful in the way I compare the output.
jeanl
I did more tests tonight, and indeed, my (big) mistake was to compare the original DV and the output MPEG in PowerDVD on a frame-by-frame basis. Instead, I burned on a DVD using various options and bitrates, and watched on my TV. I must say I can't see any of the artifacts that I was seeing before (macroblocks etc) at 7.5Mb/s. In particular, deinterlacing before encoding did not improve things on my TV (but it sure did in PowerDVD, which makes sense).

So HC works really well for me. At the bitrates I was using (about 6Mb/s) I couldn't tell the difference with procoder (but my TV isn't the best so take all this with a grain of salt).
Now my question would be (but this is getting OT), how can you compare interlaced encoding on a frame-by-frame basis??? It's OK in steady shots, but in moving shots (the most interesting to compare) the combing effect you see in vdubmod for example makes any comparison impossible (it masks macroblocks etc). This makes it a bit hard for me to select the right bitrate.
Do you guys have a way you recommend to compare interlaced material?

jeanl
P.S. Thanks for the help!

[FredThompson]

I must have an HC mental block...

Ignore my babbling above...well, the babbling part, that is...

@jeanl,

PowerDVD has its own internal deinterlacing routines.

NTSC DV uses a different form of data reduction for chroma (color) than does MPEG2. NTSC DV is one chroma value for a 4-pixel rectangle. MPEG2 is one chroma value for a 2x2 pixel square. Long story short, converting from one to another involves some loss and visual artifacting.

If you poke around in the AviSynth and VirtualDub areas you'll find explanations of how to display the fields as side-by-side displays, not interleaved. That would be a way to compare the post-encoding results.

[jeanl]

Originally posted by FredThompson

If you poke around in the AviSynth and VirtualDub areas you'll find explanations of how to display the fields as side-by-side displays, not interleaved. That would be a way to compare the post-encoding results.
Yes, that's what I'm looking for, a way to look at a single field so I can see blocking artifacts and things like that. I'll look around. Can you open an avs script in vdubmod? That would be one way to do that...
jeanl

[FredThompson]

Go poke around the VirtualDub areas. You just open the AviSynth script.

[Calca_P]

I am backing up a 3 and a 1/4 hr movie which the quality is shocking (obviously taken from Anologue source and put onto DVD)
I am using HC 12 beta GUI and I have just completed the first pass of a backup (DVD) via Avisynth.

The filter script Im using is Kasandro's? RemoveDirt and Didee's iip, so if you are familiar with it, you would know it is a 1 frame/second process.

My questions are,
* Does the second pass encode use the filtering process again? (Avisynth script)

I know that in the readme file, it is written that a 2 hr movie takes approx 3 hrs for 1st pass and 1 hr for the second pass but my second pass is reading 1 frame/s again which is certainly no quicker than the first pass encode.
( I thought the second pass is created from the information from the first pass)

* I also have "Scene Change" and "VBV" ticked, should these be "Unticked"? as I frames would already be present at the appropriate frames for the scene change.

I did notice that when testing with other Avisynth scripts that HC threw up an error" Cant find DGDecode.dll " when loading the Avs, so I copied it ( DGDecode.dll ) into the HC exe folder without changing the call in the script and it worked.

I apreciate the work and time going into this project by Hank315 and others and am impressed with the outcome and the writings of others, Good on yers.

Thanks