25 :!: And GOP also 25.

8O
I just though about something. Could it be the on/off "switching" of the filters :?:
The way the filter works now is that if there's very low motion, only TemporalSoften is applied and ZERO blur with asharp. Then if there's some motion after a treshold, blur is applied and ZERO TemporalSoften :!:
So if we change the script to this:

ScriptClip("nf = YDifferenceToNext()"+chr(13)+ "nf > 2.5 ? asharp( -(fmin((nf/30), 1)), 0 ).TemporalSoften(0,0,0,0,2) : \
TemporalSoften(2,7,7,3,2).asharp(0, 0) ")

This will keep both filters active, no matter what the scene is :idea:
Just something to try :roll:

-kwag

does that mean the filters become static instead of dynamic again?

Hey :D . Thats a good idea. I've already done an encode without filters and it was matching near 1%. I've done this a long time ago but i will test your change of the script right now.

They become static, but with NULL values :)
Look at the script how I set the values to 0 ;)

Edit:
Meaning that the filters are present or active at all times, but operational depending on motion. So the motion adaptive filtering is still dynamic, with the difference that the filters are always one during the complete encode.

-kwag

Hmm :? . CQ remains exactly the same with

@kwag

Is this really correct?

Shouldn't this value read "0" instead of "2"?
Just wondering...

No, it's either 1 or 2. That's a "mode" value.

-kwag

Okay kwag, sorry to bother you :oops: . It's just that I haven't exactly figured out what the parameters stand for in TemporalSoften.
With this new (changed) line will we be able to use 1,00 for prediction factor in ToK? I mean, that is what we hope, right?
On to another thing... Since I live in Sweden (PAL country) I will try to predict and encode a couple of movies so we can compare them to each others encodes. I'm starting right away with "Enough" (J-Lo!) :wink: .

I'm seeing two things posted here one with

TemporalSoften(2,0,0,0,0)

and another with TemporalSoften(0,0,0,0,2)

Which is correct?

Great! I'm currently encoding K-Pax again, to see if the final size is lower than my previous >3%. I got exactly the same CQ with ToK, (67.33) with the changes to the script above, so we'll see if the file is smaller when the movie finishes.
I have a strong feeling that the problem throwing off the prediction was the on/off switching of the filters.
We'll see what happens in ~5 hours :!:
If the file is still the same as my previous encode, I'll dig a hole in the yard and crawl in it for some time :roll: :!:

-kwag

TemporalSoften(0,0,0,0,2)
The first line will give you an error.

-kwag

Exactly :!:, but if I'm correct and the on/off switching was throwing of compression, then the final encode should be close to the target.
BTW, the line should read: TemporalSoften(0,0,0,0,2)

-kwag

I've just started my encode of "Enough". In ~5 hours we'll see if there is any change in the prediction reliability with the new line kwag posted :) ! Hopefully it will be closer to target now... Anyway, I'll let you know how it turned out in the morning. Bedtime now. I'm dead tired. My band just got a record deal (at last!) so we're at our regular jobs at day and we're recording at night. If anyone was wondering... :roll: And in between I'm here at this EXCELLENT forum :D !!!
Good night to you all!

Hey guys. I'm getting the same CQ value also with the new script and video.en1 file. I"ll let my encode finish though and see what the final size turns out to be. I'm curious though if the CQ is the same how can the file size turn out bigger?

If the filter switching was throwing off prediction how would that have an effect on the file size after TMPGEnc gets done encoding? It seems that it is still predicting the same CQ thus TMPGEnc will still encode it the same and produce the wrong results.

make sense?

Actually I was thinking that the prediction was not thrown off, but it was the actual encode. But I just stopped my encode to do a quick test by encoding two 2 minute clips, one with the new line and one with the prior script line. The result :!: Same size :x
So that proves that it's definitely the prediction that is being thrown off. This also means that the on/off switching behaves correctly, and doesn't produce any glitches which is what I had suspected was happening. So back to prediction debugging :roll:

-kwag

Here are the final results:

Hi Krassi,

Your CQ was calculated with ToK 0.0.5.3 with the "SelectRangeEvery()" function right :?:

-kwag

Yes.
I'm @work now again but i've started one more encoding without any filters.

Did you read my other post about the use of "Sampler()" instead of "SelectRangeEvery()" :?: :!: :!:

-kwag

What thread do you mean? This one: Experimental Revised prediction :?:

Yep :)

Ahh. Now i see. But that was too late. I've already been dreaming about making KVCD's :D .
I'll test this later on.

Good morning, Friends,

My encode of "Enough" is now finished. The file size muxed and ready became 813MB with prediction factor set to "1,00". ~2% too large if I calculated the numbers correctly. So with a pred.fact. at "0,98" the file size should be just about right! At least for this movie... I think it's really sad :cry: that it's so difficult to get to understand file prediction for this new script. This new adaptive script is simply the best script ever :D ! I don't know if its's any idea for you guys to see my ToK log for "Enough". If you still want to see it I'll post it for ya, but only if you ask me to...

Good morning audioslave,

Check my other post in this forum. The problem is related to "SelectRangeEvery()" :)

-kwag

Forgive me kwag but where in the script do you use Sampler()? I used neither Sampler() or SelectEveryRange() in my last encode...
Could you please explain how to use the Sampler() thing again? Thankful if you could post some kind of example :wink: .

Check my last post in this page: http://www.kvcd.net/forum/viewtopic....r=asc&start=16

-kwag

Okay thanks kwag!
So I take my script and add Sampler() at the end, run it through TMPGEnc and change the CQ until I get the right sample size? In other words; the "old" manual prediction way? BTW, can I use Sampler-2.5.dll?

Here are the results without filters:
Now i'll try the manual prediction with Sampler() :P

Exactly :!: If you're on avisynth 2.52, then use sampler-2.5.dll :)

-kwag

Kwag,

I have something that I don't know if it has been piccked up before.

It relates to my earlier post of puting Gripcrop() ahead of the filters and Latexxx’s adding his comments. See here

http://www.kvcd.net/forum/viewtopic....508&highlight=

Gripcrop() removes the black edges of its input. Unfortunately with asharps’s blurring of block edges, and the situation with very dark scenes (credits!!) Gripcrop is having difficulty knowing where the black edges are! Consequently frame by frame it is rendering to Gripsize() frames with different resolutions. I checked it by looking at single frame clips straight after Gripcrop(). On 2 successive frames the resolution was 688x428 and 698x430 respectively!! Whilst Gripsize() and GripBorders() will correct the final resolution of every frame to be the same and where it needs to be for output, what you end up with is a black border that is changing and no doubt using extra bitrate because the encoder would see it as motion.

Could this extra variable of “Motion Adaptive Gripfit()” hinder the prediction process!!

Perhaps we should do some extra experiments going back to non-gripfit scripts where, due to pre-determined manual cropping, this problem will not exist.. Just a thought.

Ozjeff99

For this very reason I've never used the GripFit filters. I simply don't trust an algorithm that removes the borders frame by frame, if there's lots of noise in the border area, they may go by unnoticed.

EDIT: Excessive cropping should be avoided altogether. I think we've all seen bad transfers where cropping has removed essential details from the picture itself (take the R2 Blue Velvet for example). I often crop only the borders off and max 8 pixels to maintain correct AR, resizing accordingly using FitCD when needed.

for me the best is bicubic.
i see the image out the center using gripfit,
more border on the left,less border on the right.
only i got it?

A problem too is that the resizing in Gripsize() is using different parameters frame by frame and this will no doubt affect file size etc.

So it's better to use the other resizer that's in the earlier scripts? Don't remember what that resizer was though... Could someone please post those lines?

Hi Audioslave, I'm not suggesting abandoning Gripfit but it could be creating some probs that are worth checking out particularly accuracy of prediction and file size. What it could mean is that we compare with the standard values in Moviestacker after entering the crop values manually. Crop values can be got from either Vdub or Tmpgenc.
ozjeff99

No, it surely doesn't do that. The values are calculed at the first call of "GripCrop" and internaly stored into variables (GripFit_target_width, GripFit_resize_width...).

That is why we can have more than an occurence of "GripCrop" within the script.

hey Phil,

and what you think about the "image out of center" like i posted :?:
(more border on the left,less border on the right)

Dialhot..I hope you are right. But how much of the movie does it analyse to get the values. If it was on the basis of the first frame and it was black, what values would it pick? And if it picked an average value for the movie would this value be different if the clip was a sampler for prediction?
ozjeff99

This is due to round done in the calculation (from float to int).

AS the left border if computed before right, the left border is privileged (same for top vs bottom).

Example :
- dest width wanted : 352
- source width after resizing : 321
- number of pixel to share between left and top border : 31

Finaly, left border will have 16 pixels and right 15.

But the difference should'nt be so great as it is of 1 pixels max !