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.