Log in

View Full Version : Quick question about applying filters to ranges


wonkey_monkey
28th September 2011, 17:17
Hi all,

Does anyone know, would there be much of a difference speed/memory wise between trimming a video with script, and then applying a filter, or alternatively writing the filter so that all out-of-range frames are immediately returned unaltered, like this:

if (n<CRAWL_START || n>CRAWL_END) return child->GetFrame(n, env);


I'll be overlaying several bespoke filters, so could doing it the second way (which would simplify my AVS script) cause much of an overhead? I've tried applying the one filter I've written several times, and it doesn't seem to have made a dent in FPS on the unfiltered frames, but are there any other reasons not do it this way?

David

IanB
28th September 2011, 23:13
This is what effectively happens when you express this idea in a script. e.g....Source(.....)

A=Trim(0, 1234)
B=Trim(1235, 2345).SomeFilter(...)
C=Trim(2346, 0)
A++B++C

In terms of absolute efficiency putting the code in your filter is better by a very very small margin, the script parser/compiler does not do any optimising, it just chains filter objects together as the script describes.

The number of cpu cycles involved in making the child->GetFrame(n, env); call is microscopic compared to any filter that actually manipulates the image data.

Filters that just make forking decisions based on N in their GetFrame routine are traditionally called zero cost filters. Typically they cost 10's of cpu cycles compared to processing filters which may cost 10's, 100's or 1000's of cycles per pixel. Trim(), *Splice(), Select*(), Apply*() are typical of this type of zero cost filter.

The other type of zero cost filter are those that just do pointer arithmetic on the PVideoFrame, Crop() is typical of this type of zero cost filter.

You may find it instructive to use a debugger to single step your way down the GetFrame chain for some trivial scripts.

dragon_warrior
4th October 2011, 17:28
ConditionalFilter and ConditionalReader work for me, and they are more memory-wise than Trim and its relatives (i.e, ApplyRange(), ReplaceFramesSimple....)