Strange behaviour with combination of "Crop" and "Convert"

[Syncroniza]

Hi!

I'm using AviSynth v2.07 and the newest VDubMod.
A few days ago I made some test-scripts, but I experienced some problems. Starting in the YUY2-colorspace, I made some conversions to RGB and back to YUY2 in these scripts. But it seemed to me that the ConvertToRGB-command always wanted a clip with a width dividible by 4.
I will post some examples:


LoadPlugin("F:\Video\Avisynth2\Addons\MPEG2Dec3.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\DecombLegacy.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\Dnr2.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\Convolution3D.dll")
video=mpeg2source("F:\temp\familyguy_03-02-17.pva.pf.d2v", CPU = 6, iPP = true, iConv = false)
audio=WAVSource("F:\temp\familyguy_03-02-17.pva.norm-wave.wav")
AudioDub(video, audio)
Telecide(guide=0, post=true, threshold=7, dthreshold=5, blend=true, show=false, reverse=false, firstlast=false)
ConvertToRGB32()
Crop(14,4,-12,-4)
DNR2(12)
ConvertBackToYUY2()
Convolution3d (preset="animeLQ")
BilinearResize(640,480)
Trim(5000,8000)

The script above, for example, worked.
Whereas the following script didn't work (at least not how I expected):


LoadPlugin("F:\Video\Avisynth2\Addons\MPEG2Dec3.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\DecombLegacy.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\Dnr2.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\Convolution3D.dll")
video=mpeg2source("F:\temp\familyguy_03-02-17.pva.pf.d2v", CPU = 6, iPP = true, iConv = false)
audio=WAVSource("F:\temp\familyguy_03-02-17.pva.norm-wave.wav")
AudioDub(video, audio)
Telecide(guide=0, post=true, threshold=7, dthreshold=5, blend=true, show=false, reverse=false, firstlast=false)
Crop(14,4,-12,-4)
ConvertToRGB32()
DNR2(12)
ConvertBackToYUY2()
Convolution3d (preset="animeLQ")
BilinearResize(640,480)
Trim(5000,8000)

The problem now is, that the second example was two or three times slower! :confused:
The other filters in these scripts should be no problem, so you shouldn't mind about unusual arguments (this was only for testing). You also shouldn't ask why I'm converting to RGB at all, only for the DNR2-filter (which would also work in YUY2). This is a different problem. :D
Fact is: The first script worked properly. In this script I first used ConvertToRGB32(), then I cropped (now in RGB-colorspace). The only difference in the second script is, that I first cropped (in YUY2-colorspace), and converted to RGB afterwards.
After some further testing, I found out, that this script worked again in normal speed:


LoadPlugin("F:\Video\Avisynth2\Addons\MPEG2Dec3.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\DecombLegacy.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\Dnr2.dll")
LoadPlugin("F:\Video\Avisynth2\Addons\Convolution3D.dll")
video=mpeg2source("F:\temp\familyguy_03-02-17.pva.pf.d2v", CPU = 6, iPP = true, iConv = false)
audio=WAVSource("F:\temp\familyguy_03-02-17.pva.norm-wave.wav")
AudioDub(video, audio)
Telecide(guide=0, post=true, threshold=7, dthreshold=5, blend=true, show=false, reverse=false, firstlast=false)
Crop(16,4,-12,-4)
ConvertToRGB32()
DNR2(12)
ConvertBackToYUY2()
Convolution3d (preset="animeLQ")
BilinearResize(640,480)
Trim(5000,8000)

Well, it seems that I has to crop with a width-value mod4, otherwise the conversion to RGB-colorspace is horribly slow. If I want to crop with e.g. only mod2-values, I have to do this after the conversion to RGB.

So, I have to aks now:
Did I miss here something? Has the ConvertToRGB-command some restrictions that I'm not aware of?
The cropping-command cannot be false. The only two limitations of cropping in YUY2, that I know, are:
- The left and right cropping-values should be mod2 (of course the resulting width should also be mod2 then).
- You have to regard the limitations of the filters which follow after the cropping.
With cropping in the RGB-colorspace, there should be no limitations, as far as I know.
But I'm no expert in colorspaces. If such a restriction in the ConvertToRGB-command is normal, someone should tell me (and I would feel sorry about wasting your time :( ).
So, a real restriction with the colorspace-conversion would be the first possibility.

Second possibility:
Is there a bug in AviSynth v2.07 which is perhaps solved in v2.08 or the 2.5x-versions? Well, I never read of such a bug in the version historys, but who knows..?

Third possibility:
The reason is within my system configuration. I think, the possibility of that is rather low due to the problem lying in a internal Avisynth-command. But if someone asks, I will post my system specs.
Hmm...or is it possible, that Avisynth uses external routines for the conversion into the RGB-colorspace? So that a crappy codec in my system can cause such a behaviour? Questions after questions...

Oh..perhaps this helps someone in identifying the problem:
When I searched the forum for a answer to this problem, I found one old thread:
http://forum.doom9.org/showthread.php?s=&threadid=41580
In this thread, a guy reports about "slow resizing" in AviSynth. Well, he thought that it was the resizing, but I think this guy had the same problem as me. He also used normal mod2-cropping-values (and not mod4) in his scripts and converted to RGB-colorspace right after.

I really want to know what the real reason behind this strange behaviour is. So, if someone has a hint (if someone is able to read this rather long text, filled with bad english :) ), I would be very happy.

Thanks for your help.

Syncroniza

[Shalcker]

In most cases reason behind such behavior is MMX/SSE optimization, which deals with several pixels at once (usually from 4 to 8). So i'd guess that when there is non-mod4 width ConvertToRGB32() will fall back to complete or partial non-mmx processing (a lot slower).

[sh0dan]

Shalcker is right. If width is not divideable by 4, the MMX routines in YUY2->RGB will not be used.

[Syncroniza]

Yeah...your answers sound reasonable. This would also match with one passage I found in the AviSynth-Docs (http://www.avisynth.org/index.php?page=DataStorageInAviSynth). In the section named "DataStorageInAviSynth" you can read that "most functions actually process 4 pixels at the same time" in RGB-colorspace. So if you have a clip with a width not divideable by 4, and you convert to RGB, then the optimization for MMX is not working anymore and the whole process will be relatively slow. I hope I understood this right...

So, thanks for the response. I think my main question is answered now.

But there is one more thing I have to report with this issue:
When I experienced this problem with the RGB-conversion, I made some further tests with simpler sripts. I just loaded a clip in the script, cropped it and then passed it to VirtualDub where the other work (deinterlacing, resizing) was done.
One example:


LoadPlugin("F:\Video\Avisynth2\Addons\MPEG2Dec3.dll")
video=mpeg2source("F:\temp\familyguy_03-02-17.pva.pf.d2v", CPU = 6, iPP = true, iConv = false)
audio=WAVSource("F:\temp\familyguy_03-02-17.pva.norm-wave.wav")
AudioDub(video, audio)
Trim(5000,8000)
Crop(14,4,-12,-4)
ConvertToRGB32()

Well, nothing new here. The width of the video after cropping was only divideable by 2 and not by 4, and so the conversion to RGB was veeery slow.
Next example:


LoadPlugin("F:\Video\Avisynth2\Addons\MPEG2Dec3.dll")
video=mpeg2source("F:\temp\familyguy_03-02-17.pva.pf.d2v", CPU = 6, iPP = true, iConv = false)
audio=WAVSource("F:\temp\familyguy_03-02-17.pva.norm-wave.wav")
AudioDub(video, audio)
Trim(5000,8000)
Crop(14,4,-12,-4)
#ConvertToRGB32()

Now...surprise, surprise: With this script, the whole process was at normal speed (at least when compared to the first script)!
The conclusion is:
When you convert from YUY2 to RGB within AviSynth, the width of your video has to be divideable by 4. But when this conversion is done in VirtualDub, there is no such restriction!
I have to conclude this because nothing else is done in the second script. I cropped (in YUY2) to a width not divideable by 4, but then didn't use the ConvertToRGB-command of AviSynth. No, i opened the script with VirtualDub, and VirtualDub did the conversion to RGB. And this was done (I have to repeat this once more) in normal speed.

I know that the routines of the RGB-conversion in AviSynth are different to the routines in VirtualDub. And yes, I also know that (e.g. when using a width divideable by 4) such a conversion is often a bit faster in VirtualDub than in AviSynth. But the difference should be (if at all) very very small. When using a width only divideable by 2, the difference is yet very huge!
Well, given the fact (as you explained) that the RGB-conversion in AviSynth is falling back to non-MMX processing. We must assume now that VirtualDub is able to stay in such a optimized processing.
But why is that? I hope that again someone can explain this behaviour...

Perhaps one finds it a bit annoying that I'm writing here these long posts about such a problem with the old Crop- and Convert-commands.
I can only say that:
If someone uses simple scripts with these normal commands, and suddenly the whole process is enormously slowed down and there seems no logical explanation, this can be quite a surprise!
So in my opinion, if this behaviour cannot be solved, at least such a restriction should be mentioned in one of the main FAQs or in the AviSynth Manual. (I'm sorry if that perhaps was already done, but I found nowhere such a passage except for the one small technical hint mentioned at the beginning of my post.)

Syncroniza

[sh0dan]

When you convert from YUY2 to RGB within AviSynth, the width of your video has to be divideable by 4. But when this conversion is done in VirtualDub, there is no such restriction!

Try zooming your picture in vdub - you are quite likely to see garbage at either the two leftmost or rightmost pixels.

There is close to 0 (zero) reasons for you to work with such resolutions. Few MPEG encoders will accept it - or at least give working results. HuffYUV has problems with them.

Your enthusiasm is appreciated, but you should use it in other areas, as there isn't much to be said about it. Crop before resize, and resize to mod 8 or mod 16 resolutions.

[Shalcker]

Originally posted by Syncroniza
Now...surprise, surprise: With this script, the whole process was at normal speed (at least when compared to the first script)!

Well, no surprise really. As VirtualDub deals with only one colorspace it is highly optimized for all conversions into that particular colorspace...

AviSynth is more general tool, therefore routines are optimized with regard to restrictions imposed by other colorspaces/filters/codecs/etc (most widespread and likely scenarios)... and with regard to programming simplicity too (there is often a lot more interesting things to do then creating partial mmx processing code or changing algorithm to process "more" resolutions) :)

You should also note that there is often problems with video codecs when they get non-mod4 width or even non-mod8 width... and some videocards had glitches which disabled overlay for anything less then mod16 horizontal resolution, resulting in great slowdown... so people generally try to avoid "bad" resolutions.

Well, given the fact (as you explained) that the RGB-conversion in AviSynth is falling back to non-MMX processing. We must assume now that VirtualDub is able to stay in such a optimized processing.
But why is that? I hope that again someone can explain this behaviour...
Shodan said that AviSynth code falls back to complete non-mmx processing, and that is resulting in great slowdown.

Well, obviously, for ConvertToRGB32() it should be possible to do partial MMX processing then deal with the rest by non-mmx means (and that wouldn't be _much_ slower - after all only 2-3 vertical lines will be processed in this manner in the worst case).
And since AFAIR AviSynth maintains image pitch as mod 8 we can probably process some "out-of-image" pixels with mmx code and then just discard them...

In other cases interleaving non-mmx code with mmx one or dealing with border conditions can be a lot more difficult, so people usually don't bother with that unless asked. ;)

[Syncroniza]

Originally posted by sh0dan
There is close to 0 (zero) reasons for you to work with such resolutions. Few MPEG encoders will accept it - or at least give working results. HuffYUV has problems with them.

Your enthusiasm is appreciated, but you should use it in other areas, as there isn't much to be said about it. Crop before resize, and resize to mod 8 or mod 16 resolutions.
I am aware of these attributes of the various codecs. I never said that I wanted to keep the mod2-resolutions till the end. I always resize to "normal" resolutions - either in AviSynth or in VirtualDub (and this was also done with every script I posted here). My remarks always referred to the cropping that can be done before the resizing.
But don't get me wrong... I am thankful for your answers as now I know much more about the working of the colorspace-conversions.
I also appreciate a lot your work for AviSynth, Shodan! :)

So, to both of you, Shodan and Shalcker:
Thanks for your answers and for your patience! hehe :D