Native bob(0,1) different in AviSynth 2.6 (32 bit) and AviSynth+ 3.7.5 64 bit

[lollo2]

The contest: I am writing a (very complex) script to automatically detect the shifted fields in a video (PsF, interlaced, phase-shifted, mix of all)
as described in this thread: https://forum.doom9.org/showthread.php?t=186211

The problem: when testing the script with avs2.6 (32 bit) and avs+3.7.5.64 64 bit (but should be the same in 32 bit version) I find different
outcomes, and after investigation the reason is bob(1,0), which has been redesigned in avs+!

Some results:
bob = tff ? c.AssumeTFF().bob(0,1) : c.AssumeBFF().bob(0,1)
global dfs4_f1 = bob.selectEven().aBlur(5, blurV=0)
global dfs4_f2 = bob.selectOdd() .aBlur(5, blurV=0)

bob() is SeparateFields plus a bicubic resize. Every measurement column in the csv -- d_org, d_best, ratio, mean1, mean2, dc, base_d, base_m -- descends from f1 and f2, hence from bob.

window inside an excluded sector? rows with a verdict FRAMES with a different decision
10800-11100 no 33 0
115000-115999 no 256 0
118000-118999 no 248 0
128000-128999 no 155 0
5000-5999 YES (0-10803) 211 1
85000-85999 YES (83727-86598) 238 18

3301 frames OUTSIDE the excluded sectors -> no decision changed at all
2000 frames INSIDE -> 19 changed, 12 of them entering or leaving SHIFT
(121 differing cells in the decision columns in total, spread over those 19 frames)



No one else has ever experienced a difference with avs+ bob() or any of its native functions?

[johnmeyer]

I cannot remember the details right now, but I do remember having issues with bob() when trying to do a similar thing. FWIW, I have copied my simple field shift script below, in case it helps.
# Script to both detect, and then fix, video in which one field has been shifted up by one line.
# June 4, 2013
# John Meyer

source=AVISource("e:\fs.avi").killaudio().assumetff().bob(0,1).ConvertToYV12()

#Perform the shift on bobbed source by first cropping and then adding border
Hshift = 0
Vshift = 2
even = selecteven(source)
odd = selectodd (source)

even = crop(even,Hshift,Vshift,0,0)
even = addborders(even,0,0,Hshift,Vshift)

output = interleave(even,odd)

#The next several lines are used during debugging to make sure YDifference metrics
#really do detect field shift reliably

#script = """Subtitle("\nsource = " + String(YDifferenceFromPrevious(source)) + \
# "\noutput = " + String(YDifferenceFromPrevious(output)), lsp=0)"""
#Scriptclip(output, script)

fixed = output.scriptclip("""YDifferenceFromPrevious(source) > \
YDifferenceFromPrevious(output) ? output : source""")

#Convert back to interlaced
evenbob = selecteven(fixed)
oddbob = selectodd(fixed)
EvenOrig = separatefields(evenbob).selecteven()
OddOrig = separatefields(oddbob).selectodd()
interleave(EvenOrig,OddOrig)
weave()

[lollo2]

Thanks John. In fact the bob(0,1) approach works very well in my script, and I am able to detect if a field is shifted, if is the even or the odd field, in which direction and by how many pixels.

The problem I face is that I have 1 or 2 frames (out of >130K) where the procedures in avs give a different results than the procedures in avsplus 64bit (for instance in the first at frame x a -3 pixel shift is detected in the even field, while in the last the same frame x reports a +3 pixel shift in the odd field, which is tricky, because the frame is rebuilt sane, but not aligned to the rest).

Nothing really serious, just wondering why bob() has changed across the years...

[wonkey_monkey]

Possibly differences in rounding where code has been updated to SSE/AVX? Or maybe chroma handling has been improved. Try a clip with no chroma and see if there are still differences.

[lollo2]

Possibly differences in rounding where code has been updated to SSE/AVX?

Mekes sense.

Or maybe chroma handling has been improved. Try a clip with no chroma and see if there are still differences.

Will try that out, thanks!

[lollo2]

Or maybe chroma handling has been improved. Try a clip with no chroma and see if there are still differences.

No difference, same results when processing luma only.


comparison bands differing max diff mean diff
x86 with chroma vs x86 luma only 0 / 10836 0.0000000000 --
x64 with chroma vs x64 luma only 0 / 10836 0.0000000000 --
x86 luma only vs x64 luma only 10836 / 10836 0.20347163 0.02999702
(for reference: with chroma vs with chroma) 10836 / 10836 0.20347163 0.02999702

[MeteorRain]

AviSynth 2.6 old implementation
Engine: SoftWire runtime MMX/SSSE3 JIT dynamic code generation.
Precision: 14-bit rounding.

New implementation
Engine: SSE2/AVX2/AVX512 intrinsics.
Precision: 14-bit/16-bit/32-bit rounding.

Old implementation was worse due to lower precision.