Another hint .... do downgrade to avisynth 2.55 stable. Maybe its another bug as its known that 2.56b is quite tricky in its actual state.

The only change that I make is to add the converttoYV12() statement rest remains the same and I can see the speed difference apart from it I only use Lremovedust() and Resize() + Addborders() in the script and the slowness is only for some files.....not all....even though they all show YV12() colorspace.

I have both divx6 and xvid 1.1.0 codecs installed...........can that possibly cause these vague problems ????

If youre still talking about using Lremovedust() in your scripts, then it doesnt matter if your source is already YV12 or even crop(.......,true) was used. The Memory alignment bug comes from a filtercall within LRemovedust. Maybe its CPU Constructionset "build" specific, I dunno.

So do

ImportYourYV12Source()
ColorCache=last
ConvertToYUY2().ConvertToYV12()
LRemovedust(17,x)
MergeChroma(ColorCache)

Also if you first resize and then use LRemovedust(), it often also helps on the speed-issue, as also here the bytes do get realigned.

what I can say is that I don't have to use your double colorspace convertion to solve the problem on my SSE2 P4. The Crop(...,true) is enought.
Did you tried ?

I will have to disagree with you in this statement based on pure facts that I have experienced.

the sequence that I follow in the script is :

and this does increase the speed, whereas you have stated that its the filtercall within Lremovedust which causes the problem(In that case the converttoYV12() should be ineffective in the speed increase).

Anyways, I will try the crop() as suggested by Boulder\dialhot and see if that helps, instead of converttoYV12().

Same goes for me.

supermule: if ConverttoYV12() causes some changes in memory alignment, LRemoveDust might benefit from it - even if ConverttoYV12() actually does nothing on the video. It could be that it loads a frame in cache or something like that. In any case, it has to get the source colorspace from somewhere.

Are you suggesting that I keep using converttoYV12() since it works for me or I use both crop() and converttoYV12() or I use only crop() ???

Try with Crop only, I'm quite positive it'll fix the issue.

@ Phil & Boulder

Seems both of you got Intel Pentium SSE2 capable CPUs? Im on AthlonXP, so SSE only.
A simple crop(....,true) doesn't work for me as said above

If the issue is actually framecache-related, the colorspace conversion trick you use will fix it. Apparently realigning is enough on P4's since I've never had to do more than that. And I've only had to do the zero-crop when LRemoveDust has been called immediately after loading the source.

That's sad. But I understand that it should not be easy for a designer to master all the optimization for all instruction sets (MMX, SSE2, SSE3...). At least you found a workaround.

Hi,

I'm also using an AthlonXP, but with avisynth 2.5.5, and with a DVD source, I don't see any speed gain with this change...

I tried with this avi file, and no change: with the convertXXX lines, it's even a bit slower... (because of the conversions)

Salu2
Fabrice

@Fabrice

interesting, .... where do you apply the LRemovedust? BEFORE a "resizing" or after? I dont mean only crop() but resizing.

Okay, but is the convertion damn slow or not ?

Exemple on my PC : with Deen, a conversion takes 5 h, with LRemoveDust it takes 20 h if I do not use any fixing trick, and 5h again if I use one.

Edit : The 2.5.5 is probably not affected by the problem. This can explain that you don't see any diff

And what is the trick?

Tired Luis ?

There are two tricks that work or not depending the CPU you have :
- Crop(0,0,0,0,true)
- or the "double convert" implemented by Inc.

Read the thread completly, all in there !

Hi,

I tried with LRemoveDust just after the mpeg2source or avisource line, and also after resizing, and it last a bit more putting the LRemoveDust before resizing (I mean, for this clip, it last in both case less than 2 minutes without adding border).

And conversions with LRemoveDust last 5/6 h with hc for a 1h30 movie, at 704x576, so I assume that the 2.5.5 version is 'bug' free

Salu2
Fabrice