Results:
Code:
Version Error # Undersizing (as a fraction of clean output)
b4 128886 0.0092
b5 75865 0.0024
b6 232 0.0000039
b10 3 0.000000062
b15 3 0.00000000032
tsp 2 0 (though not bitwise identical)
Interpreting the last two rows above requires a recap & clarification of a few aspects of this test. Note that rounding error leads to a 'Variation' (see script below) of 0.000022 between identical frames, so I arbitrarily chose to log any variation greater than 0.0001 as a dubious frame.
Now for b<x>, x<=10, logged errors are typically 0.1 to 1 in magnitude & almost never below 0.01. The resulting artifacts shown by subtract are visible to the eye without any enhancement & resemble ghosting around moving edges, corresponding to incorrect buffers being accessed I assume that actually correspond to temporally nearby frames.
Recall the log from b10:
Code:
Tuesday, October 23, 2007 12:58:52
Frame Total Variation
15858 1 1.816673
15859 2 3.181405
15861 3 0.210538
Test complete.
Cases b15 & tsp1 are significantly different as the logs below show:
b15:
Code:
Thursday, October 25, 2007 01:44:06
Frame Total Variation
76888 1 0.000386
128332 2 0.000904
128331 3 0.001176
Test complete.
tsp1:
Code:
Thursday, October 25, 2007 02:07:57
Frame Total Variation
7037 1 0.001146
63052 2 0.003961
Test complete.
The few errors that have been noticed are unusually (though not exceptionally) small. Visually, I can't see them in a simple subtract. Subtract(c1,c2).Levels(124, 1, 132, 0, 255) renders them visible & shows them to be somewhat different to the usual. These five are all similar in character; tsp1 frame 63052 is a reasonable example:
By
digitalrat
They all occur on the right side & resemble a formless small patch of noise almost. Typically within a low contrast area of the video & subject to high motion.
Do you think these are indicative of the multithreading problems? I know Fizick said the b<x> variations should produce pixel wise identical output to each other when run without MT, which implies the errors in b15 must be the result of interaction with MT, but does that also apply to the tsp modified MVTools?
I'll run a non MT encode overnight using the tsp variant just to check.
Can anyone draw any conclusions, or likely conclusions, from the above?
Any comments? Anything more I can do?
For completeness, here's the script I used to look for differences:
Code:
SetMTMode(2,0)
leaf1="noSetMT"
leaf2="SetMT-t1-b10"
global c1=AVISource("E:\Work\test\hfyu_MVMT-longtest-"+leaf1+".avi")
global c2=AVISource("E:\Work\test\hfyu_MVMT-longtest-"+leaf2+".avi")
global total=0
global file="E:\Work\test\compare-"+leaf1+"-"+leaf2+".log"
BlankClip(c1, width=16, height=16) # maybe 15% faster than using c1 as our 'dummy' clip (& 100% faster than using subtract(c1,c2) with variation subtitled)
WriteFileStart(file, """ "vim:tabstop=6"+chr(10) """, """ Time("%#c")+chr(10) """, """ "Frame"+chr(9)+"Total"+chr(9)+"Variation" """, append=true)
WriteFileEnd(file, """ "Test complete."+chr(10) """)
ScriptClip( """
variation = LumaDifference(c1,c2)+ChromaUDifference(c1,c2)+ChromaVDifference(c1,c2)
# nb1 keeping writefile inside here allows us to store variation as local, reducing problems with running in MTMode 2
# nb2 aside: writefile doesn't want to when called inside FrameEvaluate; anyone know why?
# nb3 sometimes the running total is reported incorrectly in MTMode 2 as another thread updates the total before code writes out data to log;
# this isn't terribly important & can be corrected as is implicit in data set
# nb4 compare against 0.0001 instead of 0 to allow for rounding errors - 2 identical files will report a variation of 0.000022
WriteFileIf(file, "variation>0.0001", "current_frame", "chr(9)", "thistotal", "chr(9)", "variation")
global total = total + ((variation>0.0001) ? 1 : 0)
thistotal = total # massively reduce chance of MTMode 2 screwing up logging of total
return last
""" )