Different AviSynth output on AMD and Intel machines

[Lars2500]

Hi,

is it commonly known and accepted that certain AviSynth filters produce different output on AMD and Intel processors? I was unable to find any information about this.

A script as simple as:
ColorBars(pixel_type="YV12")
ConvertToRGB
KillAudio
Trim(0,199)
generates different output on AMD and Intel machines.

[Groucho2004]

Depending on the floating point accuracy of some inline asm functions I guess it would be possible.

How do you determine the differences?
Which processors did you compare?
Which version of Avisynth?

[Lars2500]

How do you determine the differences?
Which processors did you compare?
Which version of Avisynth?

To make sure the processor is really the cause, I ran extensive tests on several computers using different operating systems, x86 and x64, as well as single- and multithreading, and the result is clear: output is identical on all AMD machines as well as all Intel ones - but is different from each other.

Processors tested include both old single-core and recent multi-core AMD and Intel CPUs.

Software used: VirtualDub 1.8.8, AviSynth 2.6 MT 2013.09.28 by SEt. (Official AviSynth 2.6 ST exhibits the same behavior.)
Optional: Lagarith codec, which makes testing easier because you immediately see the difference in output file size.

In the above script it's the "ConvertToRGB" command that leads to different output. Removing that line or directly using ColorBars(pixel_type="RGB32") creates identical files on all systems. But other filters, like resizers, produce different output as well.

[StainlessS]

And did you compare results on a single machine (is not side by side on two separate machines with different graphics cards and associated stuff.

Edit: ignore this.

[Mounir]

virtualdub don't support multithreading if i'm not mistaken

[Groucho2004]

AviSynth 2.6 MT 2013.09.28 by SEt. (Official AviSynth 2.6 ST exhibits the same behavior.)
Try Avisynth+ (http://www.avs-plus.net/). The ancient mmx_YUY2toRGB* functions have been replaced in AVS+ with more efficient code.

[Lars2500]

Try Avisynth+ (http://www.avs-plus.net/). The ancient mmx_YUY2toRGB* functions have been replaced in AVS+ with more efficient code.

I already tried that, actually. Again the output is different on AMD and Intel, and on Intel it is even different from the output with regular AviSynth. Perhaps to be expected, but on AMD it is the same.

The "problem" I have is that video output becomes visibly different when using more complex scripts with a lot of filters (perhaps because some external plugins differ in output as well).

Here is an animated GIF which shows the difference in a frame output by AMD and Intel:
Animated.gif (http://www.larshederer.homepage.t-online.de/avisynth/Animated.gif)

As the effect is a bit exaggerated in the GIF because of 256-color conversion, here are the two original true color images:
AMD.png (http://www.larshederer.homepage.t-online.de/avisynth/AMD.png)
Intel.png (http://www.larshederer.homepage.t-online.de/avisynth/Intel.png)

The filter chain used in this example was:
- Load original m2v file with DGDecode (at this point the output is still identical on both AMD and Intel systems)
- ConvertToRGB
- MSU_Smart_Deblocking
- ConvertToYV12
- Color correction with MaskTools mt_lutxy
- Lanczos4 crop+resize

The differences obviously start again with "ConvertToRGB" and accumulate with each consecutive filter. In the end you get the result shown above.

That inevitably leads to another question: Which processor is better for AviSynth processing quality-wise? Speed-wise it would of course be Intel, but is it also the case if you only strive for best quality?

[Groucho2004]

If you want to properly compare the Avisynth output you'll have to exclude VirtualDub and any encoder (lossless or not).

[MeteorRain]

Comparing results by it's lossless encoding is not a bad idea. I used this to ensure binary identical of my refactoring, several kilobytes difference and you know something goes wrong.

This is interesting. I would suggest you debugging the ConvertToRGB function call to see where starts the difference in the variables. Side by side comparison could find the problem easily, although you have to compare the result by eyes not a loop.

[Lars2500]

In case anyone is interested, here is the 10-frame test clip I used in the above example (YV12 colorspace, compressed with Lagarith lossless codec):
video.avi (http://www.larshederer.homepage.t-online.de/avisynth/video.avi)

Compile this video with the following avs script on and AMD and Intel machine and compare the result:
LoadPlugin("mt_masktools-25.dll")
LoadVirtualDubPlugin("MSU_SmartDeblock_0.8.vdf","MSU_Smart_Deblocking",0)
org=AVISource("video.avi")
deblocked=org.ConvertToRGB.MSU_Smart_Deblocking(0,0,0,0).ConvertToYV12
temp=mt_lutxy(deblocked,org,"x y - 128 +",y=3,u=3,v=3) \
.mt_convolution("1 1 1 1 1 1 1","1 1 1 1 1 1 1",total=49,y=3,u=3,v=3)
mt_lutxy(deblocked,temp,"x y - 128 +",y=3,u=3,v=3)
Lanczos4Resize(720,576,5,4,-5,-4)

Frame 5 is the one shown in my previous post.

You need to put a recent version of mt_masktools-25.dll and MSU_SmartDeblock_0.8.vdf in the same folder as the script. Both can readily be found via Google.

[colours]

The claim that one brand of CPU would be better for quality than another is not a claim that is meaningful at all. If Avisynth was producing significantly differing results between Intel and AMD, then clearly Avisynth is buggy somewhere and you shouldn't trust the results regardless of whether the filters were run on Intel or AMD. (Edit: what I really meant to say was that processing quality is an intrinsic property not of a CPU, but of the software running on it.)

The correct way to evaluate this is to either write your own code as a reference or to compare against a trustworthy external implementation. Dither_convert_yuv_to_rgb exists and I sure hope Firesledge knows what he's doing, so I'll just take the lazy route.

I have an i5 on this computer, running Avisynth+ r1576 on Wine.

ColorBars(pixel_type="YV12")
addgrainc(1000,seed=1)
a=ConvertToRGB32(matrix="Rec601",chromainplacement="MPEG2",chromaresample="bicubic")
b=dither_convert_yuv_to_rgb(matrix="601",cplace="MPEG2",chromak="bicubic",mode=-1,output="rgb32")
subtract(a,b)
stackhorizontal(showred("y8"),showgreen("y8"),showblue("y8"))
mt_lut("x 128 - abs 1 - 255 *")


At least with this simplistic test clip, there's only a ±1 difference on the vast majority of pixels which can just be attributed to rounding error (and the ±2 differences are all near edges), so that gives some confidence to Avisynth+'s colour space conversion filters being correct on Intel. As for AMD… well, I don't have an AMD CPU to test with, so I'll have to defer that to someone else.

Unrelated note: you can replace mt_lutxy("x y - 128 +") with mt_makediff and mt_convolution("1 1 1 1 1 1 1","1 1 1 1 1 1 1") with AverageBlur for faster processing.