Is the full frame processed after cropping?

Phantasmagoriat · Post by **Phantasmagoriat** » Fri Mar 30, 2007 11:55 am

this may be an odd question, but say my script looks like this:

lanczosresize(960,720)
crop(0,180,0,-180)
deen("a3d",4)

since the deen comes after the crop(), I would assume deen()is only applied to the portion left behind after being cropped. However, if the whole frame is processed, that's effectively double the processing... and double the time :\

I'm asking because from <a href="http://avisynth.org/index.php?page=Crop">this page</a> it says some stuff that popped out at me:

If an image has been cropped, they will sometimes be placed unaligned in memory - "align = true" will copy the entire frame from the unaligned memory placement to an aligned one. So if the penalty of the following filter is larger than the penalty of a complete image copy, using "align=true" will be faster. Especially when it is followed by smoothers.

I don't really get what It's trying to say, but the last part interests me for obvious reasons.

CrackTheSky · Post by **CrackTheSky** » Fri Mar 30, 2007 2:11 pm

My guess would be that the filter would only apply to the cropped portion, as the scripts are read - and applied - in order. For example, if I wrote a script like this:

Code: Select all

avisource("blahblah.avi")
converttoyv12()
deen("a3d",4)
mftoon()
converttorgb32()

Deen and mfToon would work on the video because they need the video to be in YV12 colorspace. However, keeping the video in YV12 colorspace messes up the colors (at least, it does for me sometimes), so I add the ConvertToRGB32() script on the end. The filters don't stop working because the final output is in the incompatable RGB32 colorspace, but are applied while the video is still in YV12. After the filters are applied, the ConverToRGB32() script changes the video back to RGB32.

I hope that makes sense.

Gepetto · Post by **Gepetto** » Fri Mar 30, 2007 2:20 pm

Yeah, that's what happens... but the full frame is still loaded onto memory.

Phantasmagoriat · Post by **Phantasmagoriat** » Fri Mar 30, 2007 7:19 pm

sky, yeah that makes sense; that's what I guessed too, and for that reason I always consider the order I place filters.

gepetto, so only the portion is processed, but the full frame is in memory... aligned or unaligned...

I guess what irks me is that the last part says I can make it go faster using "align = true", but I don't really understand the conditions

Zarxrax · Post by **Zarxrax** » Fri Mar 30, 2007 8:47 pm

Deen will only operate on the part left behind after cropping, regardless of whether you have align set to true or false.

This setting only has to do with how the frame is stored in the computers memory, it has nothing to do with which parts of the frame processing will occur on.

Phantasmagoriat · Post by **Phantasmagoriat** » Fri Mar 30, 2007 10:01 pm

Zarxrax wrote:Deen will only operate on the part left behind after cropping, regardless of whether you have align set to true or false.

This setting only has to do with how the frame is stored in the computers memory, it has nothing to do with which parts of the frame processing will occur on.

okay thanks

, so it still processes the same frame size in the end (whatever is left behind), so according to that... I would assume it would take the same time :\ ...

...as far as the 'align' thing goes...

>.>
..

I think I'll just leave that alone

..

<.<

..

badmartialarts · Post by **badmartialarts** » Sat Mar 31, 2007 5:51 pm

I can try to explain the 'align' to you.

Think of your frames the way your computer does. It doesn't see it as any different than anything else: it's just a long list of 1s and 0s. Like this:

00001010101011101010101010101110101

You get the idea. Now, your programs realize that this stream of 1s and 0s represents video data, so they process it as such. The way this data is processed is that it thinks about a chunk of this data at a time, and applies mathematics to that section, and then sends it on to a driver that eventually displays it. The mathematics it applies is your various filters. Now, the reason you want this data aligned is because certain filters, especially filters like deen, msmooth, etc, need to process this data in certain sized chunks and by cropping the frame, you might make the frame end up with a tail end that isn't quite big enough for the filter to work with. When this happens, the filter will throw a handled exception (at least, that's what I guess happens...it might do some sort of precheck before it starts) to another part of the filter that adds enough blank data to fill out the chunk so the filter can go back and do it's job on that last section. This wastes time, since the filter is basically doing the little last piece of every frame twice or more depending on how it works. Insteade of forcing the filter to do the adding of the extra, you can make the crop command do it with the align=true parameter. This way it speeds it up a little bit.

badmartialarts · Post by **badmartialarts** » Sat Mar 31, 2007 5:54 pm

Never mind my above post, I am a moron.

align=true doesn't do that, it makes sure the video stays 32-bit aligned so the special memory handling MMX/SSE/SSE2 instructions work with it faster. I think. In fact, just ignore me.

Phantasmagoriat · Post by **Phantasmagoriat** » Sat Mar 31, 2007 9:36 pm

>.>
..
<.<
..

Okay, so the first explanation makes sense if smoothing filters do indeed process by packets [I'm not good with terms..]... and I could totally buy that answer.

for explanation #2... I'm slightly concerned since I'm using an AMD... ...
slightly.

...with respect to a parameter that accounts for 64-bit alignment. [again, terms...]

slightly.

>.>

...but I don't want to lose sleep over this...

<.>