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 !