Peachsmoother and SelectRangeEvery

[DDogg]

As I understand it, PS is adaptive. Lately I have been doing a lot of 1% predictive sampling with SelectRangeEvery(1200,12). I am wondering if throwing this quick changing data at PS will have an adverse impact on its abilities and whether the results of the sampling run will accurately reflect the results when PS is run on the full source. Any opinions?

P.S. I very much appreciate the new 2.5x version and can live with the converttoyuy2(). I would like to use it before resizing so the convert would effect speed quite a bit more. Any chance of the YV12 version happening?

[High Speed Dubb]

That would confuse Peach Smoother pretty badly, even if you specify NoiseLevel and Baseline by hand. Peach accumulates evidence for motion over time. When there’s a big jump in the frame number, it tosses the accumulated motion evidence and pretends that the previous frame didn’t have any motion at all.

So that will probably reduce the quality for the first ~second after each jump. With just 12 frames after each jump, the filter will be pretty close to useless. Also, if it’s estimating the noise level automatically, that estimate is likely to be much too high.

I think you’ll have similar (but not nearly as obvious) problems with Grape Smoother, or with any other feedback based filter. (i.e., TemporalCleaner)


By the way — What’s predictive sampling?

[High Speed Dubb]

Oops — I forgot to answer the second part of that.

A YV12 Peach is possible, but it isn’t very likely to show up. It would take a complete rewrite of the filter.

[DDogg]

Lindsey, thanks for the reply. I suspected that. Drat! (re:YV12 too, :) )

As for the predictive sampling, CCE 1-Pass VBR and TMPG are quantizer based encoding methods. They are quality based and the final file size ends up being based upon the complexity/compressibility of the source which of course is a pain in the backside as one has no darn idea what the final size of the encode will be.

The work around is that you can do some x% passes and then predict the final file size based upon the size of the sample and the percentage used. Normally you can get pretty close predicting the final file size, like within 1-3 % assuming the filters react the same way in the sample run and the full encode, hence the reason for my question. I guess PS would have a problem with this.

Thanks again for the reply and I hope you may continue to consider a YV12 version. PS is pretty cool. OT, I get a heck of a kick from watching the green dot. Maybe I should get a life :)