moving trim() command

[FredThompson]

Here's an example screenshot which shows the results of the first frame of a segment with the trim() command before the filters and after the filters. Ignore the posterization, that's only in this one frame and the light is pulsing so it's not seen during playback. Note, however, how the temporal filters affect the frame. If the trim() command is before the filters, any temporal processing can't happen becasue there isn't any "before" to reference.

Why should you care? You'll get a slight pulsing in the visual quality with the trim() command before the filtering because there will be a sequence of filtered frames, then a partially-filtered I-frame, then more filtered frames, etc. All things being equal, it's a good idea for the I-frame to be as similar to the neighboring frames as possible. The I-frame will be significantly different from the neighboring frames if they are all temporally filtered and it is not.

Ergo, move the trim() command to the end of the filter chain if you use temporal filters. It doesn't make any difference if you don't use temporal filters.

http://home.mindspring.com/~utils/trim%20&%20filters%20order.png

[jdobbs]

Interesting. I actually didn't think the filter would consider frames outside the specified range -- no matter where the trim() statement was... I can easily make DVD-RB put the trim statement after the filters.

[FredThompson]

There must be something with the precedence of how AviSynth filters are parsed that makes a trim() command limit the access of the commands which come after it. Seems odd but it does work as I mentioned. Try it yourself on something really dirty and you'll see how the post-DVD-RB will have an instantaneous burst of junk when the segment changes.

[FredThompson]

This is from an email I just sent to a buddy. It explains my perception of how/why this works a little better:

trim() interferes with temporal operations which come after it. You want to limit the frames which are evaluated by the expression, not limit the data which is available for the expression's calculations.

If you want the result to be filtered versions of frames (n..m), any backwards-looking function which operates on frame n will be prevented from access to that data if the trim command is before it in the filter definition. (That's oversimplified. AviSynth isn't a procedural language, carriage returns are one way of defining precedence inside AviSynth scripts.)

So, you do all your filtering and the last step is the trim() command, usually.

[spyhawk]

So if you have a script like so (line numbers are just for reference):

1.LoadPlugin("....")
2.mpeg2source("....")
3.undot().deen()
4.trim(0,42378)
5.SeparateFields().LanczosResize(720,240,0,30,720,180).Weave()
6.ConvertToYV12(interlaced=true)

Where would trim() be best placed at? Would this configuration best in terms of speed and quality?

[FredThompson]

AviSynth filters are functions. There is no appreciable speed difference. Does DVD-RB run slower near the end of a job? No. It does not. The functions are only evaluated for those data which are fed to them, not all the possible values. Your script doesn't bog down with trim(42370,42378), does it?

trim() specifies a range of values (frames) to be sent through the function. Precedence can let trim affect the data which is available for the evaluation of the function. You typically do NOT want it to do this if you have temporal filtering.

In your example, trim() is after deen(). "After" is not a step-by-step sequence of event, it is more akin to () in a math formula.

However, your trim starts with position 0 so you won't see any difference. There are no frames before frame 0 for temporal routines to reference.

Open avs files in the rb temp directory with VirtualDub and compare the result with the trim command at the beginning and after the filters. That's all I did. This particular filter is quite aggressive as the source is very dirty. Most of the time you probably won't see much difference but the effect on compression can be fairly harsh so it's usually better for the trim command to be the last in the chain.

[spyhawk]

Your script doesn't bog down with trim(42370,42378), does it?Not that I notice.

Most of the time you probably won't see much difference but the effect on compression can be fairly harsh so it's usually better for the trim command to be the last in the chain.So you're saying to put trim() after Weave()? Are undot() and deen() considered temporal filters?

I put trim() before and after filters and don't see any difference using trim(x,42378). Probably b/c it's a ok-clean source. Will try on a dirty source.

[Sir Didymus]

Mhhh. The argument is not totally convincing...

Maybe (as a counter-example to the nice FredThompson consideration) there is to say that DVD-RB is splitting its working segments at the cell boundaries, where the video content of the previous and following cells is (almost always) totally unrelated with the stream produced by the trim...

Into these circumstances (adding unrelated pictures to the stream to filter) it is probably worse than leaving the filter working without any heading or trailing pictures...

So even using temporal filters, it is probably better leaving the trim statement where it is actually placed, right ?

[FredThompson]

No. The vast majority of temporal filters detect change, they aren't simple averaging functions that smear the video. The frame immediately before the one from which I took the sample is a different scene.

The example I show at the top of this thread has even more pronounced effects in the next 2 or 3 frames with the trim() at the beginning. There are about 4 frames where the filter is "settling down" and there is a very visible burst of noise during playback.

You can test this yourself on a dirty source. The filter chain is on my website.

[raquete]

...The example I show at the top of this thread has even more pronounced effects in the next 2 or 3 frames with the trim() at the beginning. There are about 4 frames where the filter is "settling down" and there is a very visible burst of noise during playback.

You can test this yourself on a dirty source.
hi Fred.
i did exactly what you posted.
trim before and after deen(filter used to test) in .avs scripts are showing differents sharpeness and "focus" in vdubmod. running frame by frame show more detail.

good eyes and perception. :cool:

[Sir Didymus]

......You can test this yourself on a dirty source. The filter chain is on my website.

I see... Very nice, I would say... :)

Normally I do very little usage of filters (or no use at all, if possible...)...
So I started with a weak assumption, based on no experience...

Afraid for the raised doubts...

[FredThompson]

I've found LRemoveDust_YV12(10,1) does a great job of removing film grain with no noticeable difference to the actual image. Reducing the complexity of the images, as seen by the encoder, means you'll have higher quality.

This particular source, Heavy Metal, actually looks far better after being filtered and run through HC than it does on the original disc. How's that for nice?

As far as raised doubts, we'll squash 'em like a game of Whack-a-Mole!