Why to use Converttoxxx() multiple times
 

I have seen in many scripts that ppl use the same converttoXXX() after loading the source and then at the end of the script.

What is the benefit ??

What is the disadvantage ??

Does it degrade video quality using the colourspace conversion two times ???

Why not use it only once ...either in the begining or at the end ????

Re: Why to use Converttoxxx() multiple times
 

Each color space conversion degrade final quality a little bit.
As a general rule, you only must to do color space conversion only when it is needed.
Some filters works in a color space and not in another, so you will need to change it before to apply the filter.
If your encoder works with a specific color space (cce = yuy2, HC encoder = yuv12, tmpgenc = rgb) maybe you will need to change the color space twice in same script.

Re: Why to use Converttoxxx() multiple times
 

Here ? No way.
The only color convertion you can have is in the very last line of the script. A convertion before that is often due to lazyness of people that don't wan't to install the correct codecs, except in rare case (old codecs that do not output in YV12).

Avisynth 2.5 works in YV12 and you have a 15-30% gain in speed if you are in this mode. That explains the first convert (when you don"t have other choice).
The last convert is based on nothing really established : the encoders works with YUY2 (CCE) or RGB24 (tmpgenc). Some people tells that convertting to this colorspace at the end of the script is better than to let the encoder do the conversion itself. I don't think someone ever did a comparitive test on this.

A conversion is not lossless. The less you have, the better it is.

Yeap.

See above.

He probably means the silly-speeduptrick when using LRemovedust?


In here imho the Conversion from YV12 to YUY2 and back to YV12 is lossless as above we do finally apply the original chromaplanes back. But this results in Lumadenoising only.

YV12 and YUY2 do have the same 8bit Luma Y Plane
But YV12 chroma does have the half of the YUY2 choma vertical resolution.

I was thinking about rounding in the maths. All operations are done in integers so you can loose a lot. But I don't know what "formula" is used for YUY2 <-> YV12

I was refering to this little Command ---> mergechroma(last,a)
Shure there is an interpolation in the chromasubsampling when going from YV12toYUY2backtoYV12 but with mergechroma(Denoised,Colorcache) I do apply the chroma of the UV from the "Colorcache" YUV clip, means the original --> Colorcache = last

Ah! its gets so confusing sometimes.........if I check the info() on the source, I find its YV12, but if I dont use the converttoYV12(), I get extremely, extremely slow processing by TMPGEnc on some sources and normal processing on others (both show YV12()).

I have experimented and found that adding the converttoYV12() to the script improves the processing speed (from appx 28 hrs to 5 hrs) of the TMPGenc encoder.(thanks to dialhot for this suggestion in one of the earlier posts)

Now now where's the catch ????

The info() is bugged ? :lol:

Seriously, if the convertion speeds up your script then you can have this memory alignment problem that Inc fixed with the "tricky trick" (:-)) he gives few post above.

Note: when you use info(), just do a script with the source load + the info line. No filters, nothing.

Well I did that but buggily I still found that although info() shows YV12() colorspace, if i still add converttoYV12() it increases the speed (in some to a gr8 extent, as i wrote in my previous post) + it enhances the colors + adds to the compressibility of file(i.e lower file size).

Therefore based on my tests, I have decided to add converttoYV12() in all my scripts.

If the colorspace is already YV12 at the corresponding part of the script, Avisynth does no colorspace conversion when you use ConverttoYV12().

That should suppose then that the "Info()" command has a bug :idea:

I'd say that if supermule has a source which shows YV12 with Info() but still processes faster with ConverttoYV12(), he should upload a few frames somewhere for analysis. I find it quite hard to believe that Info() is buggy since it cannot be too complicated. At the moment Avisynth supports only YUY2, YV12 and RGB.

Avisynth always asks for YV12 first, then falls back to YUY2 if YV12 cannot be delivered by the decoder. It sometimes even does a colorspace conversion without asking, I have to state pixel_type="YUY2" in AviSource in my capture processing scripts to avoid conversion to YV12.

My personal guess is that the performance problem would be solved by Crop(0,0,0,0,true) at the beginning of the script.

Then you suspect that he just have a memory alignment problem. So do I.
So there si two possibilities:

1/ The info is not buggy, the source is really YV12, but a ConvertYV12() still processes the source. The command is not as optimized as we thought.

2/ The info is buggy, the source is not YV12 and then the Crop won't solve anything.

I bet for the first one but who knows ?

Then it does not harm at all, used only when required, which is good ...huh!

Then so be it, I will upload a clip from the same source for analysis.

What does this do btw..........

So here's the clip.....


http://rapidshare.de/files/6093600/clip.avi.html

Happy Testing ;)

This "re-align" the memory words. Nothing else.

There's nothing wrong with Info(). The file is an XviD file which means that it is YV12 already. ConverttoYV12 doesn't change the video in any way and that's the way it should be. The problem lies within your script or your system.

Boulder, the commands speed up his script ! That means that the ConvertToYV12 process the clip either if it is already YV12.
Perharps it just realign the words like the Crop line, but it's not accurate to tell the it does not change the video in any way.

ColorYUV shows no change so there is no colorspace conversion. Also the script can load both the stream without ConverttoYV12 and with it simultaneously. Therefore, logic states that there's something else than a colorspace conversion - memory alignment is the most probable reason. I just had to put Crop(0,0,0,0,true) right after MPEG2Source in my last encode because LRemoveDust was dead slow. I remember the same happening with FluxSmooth long time ago. It could also be some cache issue.

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 :wink:

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?

:lol:
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