AviSynth 2.6.0 Alpha3 [May 25th, 2011]

[Mini-Me]

The intent is yes, I have tested the new code, but I also wrote it, so may have a blinkered view. ;) Report any bugs here.

According to my tests, YV12/YUY2 conversion is still broken in Alpha3 (I also doublechecked with Version() that I was using the newest alpha). A good way of testing is getting Gavino's routines from the relevant thread (http://forum.doom9.org/showthread.php?t=147629) and running the following test script:

function ConvertCore(clip c, int times)
{
times == 0 ? c : c.ConvertToYUY2(interlaced = True).ConvertToYV12(interlaced = True).ConvertCore(times - 1)
}

function ConvertGavino(clip c, int times)
{
times == 0 ? c : c.YV12ToYUY2_26(interlaced = True).YUY2ToYV12_26(interlaced = True).ConvertGavino(times - 1)
}

bars = ColorBars(pixel_type = "YV12")
core = bars.Animate(0, 500, "ConvertCore", 0, 500)
gavino = bars.Animate(0, 500, "ConvertGavino", 0, 500)
return StackHorizontal(core, gavino)

The difference is still very apparent after just a few iterations, and it keeps getting worse as you iterate.

Note that I transcribed the script by sight from another computer, so there might be typos. :p

[IanB]

Comparing Apples with Apples seems to work fine.function ConvertCore(clip c, int times)
{
times == 0 ? c : c.ConvertToYUY2(interlaced=True, chromaresample="Bilinear").ConvertToYV12(interlaced=True, chromaresample="Bilinear").ConvertCore(times - 1)
}

[IanB]

The routines isse_yv12_i_to_yuy2, mmx_yv12_i_to_yuy2, isse_yuy2_i_to_yv12 and mmx_yuy2_i_to_yv12 are unchanged from 2.5.8 (and older)

[Mini-Me]

Comparing Apples with Apples seems to work fine.function ConvertCore(clip c, int times)
{
times == 0 ? c : c.ConvertToYUY2(interlaced=True, chromaresample="Bilinear").ConvertToYV12(interlaced=True, chromaresample="Bilinear").ConvertCore(times - 1)
}

Sometimes I just like oranges better. (I'm such an amateur. :p)

Thanks for pointing out that parameter. I just checked with Subtract and Levels, and no matter how many round trips I take, your new code works exactly the same as Gavino's with chromaresample = "Bilinear." Good work! :)

[Ziddy76]

Need help with AviSynth 2.6. The performance with Yatta is just too slow for me.

I downloaded Alpha 3 and Yatta now crawls. Now I know 2.6 and Yatta work as it seems I'm alone with this issue, everyone else I've talked to say no problems. I don't think it's a hardware issue as others with lesser hardware are having no issues.

So I'm asking AviSynth developers, any idea what could be going on? As soon as I replace the AviSynth.dll with the 2.5.8 version in SysWow64, the performance of Yatta skyrockets. Replace with 2.6, it's a slideshow.

Thanks.

The Rig I'm using:
Windows 7 Ultimate 64, all updates installed.
Intel i7 720QM (HT, 1.9-3Ghz)
HD5870M (815/1125, running WHQL 11.6 Drivers)
8GB 1333 DDR3
Latest Intel Chipset drivers instaled

[IanB]

@Ziddy76, :script:

[Ziddy76]

@Ziddy76, :script:

It's not a script, it's YATTA.

[Groucho2004]

It's not a script, it's YATTA.

From the YATTA thread:

YATTA, from a technical standpoint, is essentially a very complex AVS script which calls telecide to provide a visual interface to the patern matching process while creating a total encode override file.

Apart from that, it's 8 years old. Are you still using the old plugins with it?

[IanB]

@Ziddy76,

You are not giving us a great deal to work with here. YATTA is a monster set of scripts that beat up on a fist full of IVTC plugins.

Try a big SetMemoryMax()

In my testing 2.6 is the same or faster than 2.5.8 when running 2.5 scripts and plugins. The major difference is 2.6 has much better self control about blindly grabbing excess memory beyond the specified MemoryMax limit. 2.5.X can easily be tricked into grossly exceeding the MemoryMax limit. With 2.6 it obeys the limit.

[Ziddy76]

@Ziddy76,

You are not giving us a great deal to work with here. YATTA is a monster set of scripts that beat up on a fist full of IVTC plugins.

Try a big SetMemoryMax()

In my testing 2.6 is the same or faster than 2.5.8 when running 2.5 scripts and plugins. The major difference is 2.6 has much better self control about blindly grabbing excess memory beyond the specified MemoryMax limit. 2.5.X can easily be tricked into grossly exceeding the MemoryMax limit. With 2.6 it obeys the limit.

Uh, no that can't be the problem. No one else who has 2.6 and Yatta working has to setmemorymax. I know it runs supposedly faster and it does run with Yatta fine with other useres. I'm trying to figure out why it's not running at similar performance as it is for me. Is there anything I could be missing from the install or anything that avisynth 2.6 needs that I didn't install?

I have not written any script. It's just a d2v and .yap file with metrics collected from ymc. Where am I placing this setmemorymax? It's just the Yatta program. It's driving my nuts because all I have to do is copy 2.5.8 into syswo64 and the performance is back. No script written. Copy 2.6 alpha 3, and it's a slideshow again. I feel that I am missing something that is prevent from 2.6 and Yatta from functioning properly.

All the plugins are up to date. And using the last version of Yatta which was released about a week ago. And no it's not a problem with Yatta being 8 years old. I've already said it works fine with other users, they don't seem to have any problems. I'm missing something. Has to be something.

[IanB]

@Ziddy76,

Where exactly did you download your copy of Yatta from (Exact URL please). The old one I found on my disk works perfectly.

The SetMemoryMax goes in the Avisynth scripts created by Yatta. You could create a special Script.AVSI in your Avisynth plugin folder with the required script line to auto-load first so you don't need to stuff around with Yatta.

[JEEB]

Newest version of YATTA at the moment is available from here (http://ivtc.org/yatta/) (I would guess Ziddy76 uses one of those 131 builds there). Surprisingly, Myrsloik has taken the time lately to update it and fix certain bugs as well as bring it up to the times in certain things.

[IanB]

@JEEB,

I know you are trying to be helpful but, please don't prompt for inexperienced user. I want to know exactly where Ziddy76 got there copy from. So many times people download "improved" versions of product that expose issues that the standard version never does. Fine if Ziddy76 got it from ivtc.org, but I need it to be stated. Something about Ziddy76's setup is exposing a problem I would like to get to the bottom of the problem.

[Mounir]

Not sure if it's a v2.6 problem but i find the convertion YUY2 to YV12 blurry !
yuy2: http://www.sendspace.com/file/jlakv8
YV12 (convertion) : http://www.sendspace.com/file/v55p4v

Take a look at the end of the large magenta bar for instance, is this normal ?

zoom-in (gives a better idea)
YUY2: http://www.sendspace.com/file/jwsq53
YV12: http://www.sendspace.com/file/xpvn4f

[Wilbert]

@IanB,

Could you describe a bit how this dithering works for Levels, RGBAdjust & Tweak. Then i will add it to the documentation.

[LaTo]

@IanB,

Could you describe a bit how this dithering works for Levels, RGBAdjust & Tweak. Then i will add it to the documentation.

It's a simple ordered dithering (using pattern) but I haven't checked which matrix is used (maybe "Bayer").

[IanB]

@Wilbert,

It is ordered input dithering with a 02/31 recursive Bayer pattern (contrast normal 13/42 pattern) modified for equal sums in both rows and columns. Avery Lee described the recursive generation in his blog a while ago on Dithering. I modified the resultant pattern for equal summing to eliminate an obvious pattern visible in 16x16 cells.

The dithering is added as an extra lower 8 bits (4bits for chroma) on the input pixels, making 16bit data. This is then used as an index into a 65K LUT to get the output 8 bit pixel. The dither pattern effectively replaces the 0.5 rounding term in generating the LUT.

A non-dithered TV->PC levels translation i.e. O=(I-16)*255/219, results in only 219 distinct output values and causes banding. With dithering the output is evenly distributes with all 256 output values used. E.g input values 128 would like output value 130.41. Without dithering this is always rounded to 130. With dithering 41% of pixels become 131 and 59% become 130. The distribution is based on spatial position. This implementation is very fast. A better model might be error diffusion but this cannot be done with a simple LUT.

LUT code without dither. for (int y=0; y<vi.height; ++y) {
for (int x=0; x<vi.width; ++x) {
p[x] = map[p[x]];
}
p += pitch;
}

LUT code with dither. Additional operations in Blue. for (int y=0; y<vi.height; ++y) {
const int _y = (y << 4) & 0xf0;
for (int x=0; x<vi.width; ++x) {
p[x] = map[ p[x]<<8 | ditherMap[(x&0x0f)|_y] ];
}
p += pitch;
}

[Ziddy76]

@JEEB,

I know you are trying to be helpful but, please don't prompt for inexperienced user. I want to know exactly where Ziddy76 got there copy from. So many times people download "improved" versions of product that expose issues that the standard version never does. Fine if Ziddy76 got it from ivtc.org, but I need it to be stated. Something about Ziddy76's setup is exposing a problem I would like to get to the bottom of the problem.

I don't mod or build anything. I just get it from ivtc.org. The latest version, whenever Myrsolik releases it. Currently using beta 5. I just used the installer for 2.6 from SourceForge, and run the .yap file in YATTA, I don't use any special AVS script with it. No special filters in the presets or anything. And it is a slideshow, going frame by frame. All I do is replace the avisynth.dll from 2.5.8 into SysWow64, reload the .yap in YATTA, and it's like 30X faster, smooth and fast. I'm a simpleton when it comes to AVS and YATTA, so I don't do anything complicated.

[IanB]

@Ziddy76,

Not to be pedantic, please state the exact version you are running!

[pbristow]

@Ziddy76, just in case you're starting to feel persecuted... [SYMPATHETIC GRIN]

The reason IanB needs to know exactly which version you're using is so that he can try to recreate and investigate your problem. Otherwise, he'd have to just guess at which version, do tests with that, and if (after probably a lot of work) he couldn't find anything wrong he wouldn't even know if that was because he was testing the wrong version (i.e. one that doesn't interact with the new AViSynth alpha the same way yours does) or because the problem is caused by something else entirely. You need to help IanB to help you (and thereby to help everyone): Be as precise as you can about the set-up you're using.

[Ziddy76]

@Ziddy76,

Not to be pedantic, please state the exact version you are running!

yatta_7-131-beta5

[Mounir]

Not sure if it's a v2.6 problem but i find the convertion YUY2 to YV12 blurry !
yuy2: http://www.sendspace.com/file/jlakv8
YV12 (convertion) : http://www.sendspace.com/file/v55p4v

Take a look at the end of the large magenta bar for instance, is this normal ?

zoom-in (gives a better idea)
YUY2: http://www.sendspace.com/file/jwsq53
YV12: http://www.sendspace.com/file/xpvn4f


Anyone please ??

[IanB]

@Mounir,Join Date: Nov 2006
Posts: 281And you don't know that YV12 has half the vertical chroma resolution of YUY2. Start here. (http://avisynth.org/mediawiki/Color_spaces)

The "Avisynth Development" forum is quite low traffic, some members only browse once a week, so be patient. And is really for development related discussion. As such if you really had a 2.6 specific issue I would expect you to at least have done comparison tests between other versions, and for bonus points quote the relevant source code.

[Mounir]

Yes i know but it never crossed my mind it could be this blurry

[Ziddy76]

yatta_7-131-beta5

AviSynth 2.6 Alpha 3. DgDecode 1.5.8, nnedi3 0.9.2.

Do you suppose this could be affected by the GPU? It's an AMD Juniper architecture, HD5870M.

When using System Monitor, CPU usage is around 10% with Yatta. So doesn't appear to be a CPU bottleneck and since it works fast with AviSynth 2.5.8.

[IanB]

@Ziddy76,

I take it you when you say it is slow you mean sluggish navigating the timeline in Yatta. :confused:

Perhaps you had better explain what you are doing in Yatta, start with the Open button, and explain where it is slow. Is it slow with all source files or just this one?

[TheRyuu]

@Ziddy76,

I take it you when you say it is slow you mean sluggish navigating the timeline in Yatta. :confused:

Perhaps you had better explain what you are doing in Yatta, start with the Open button, and explain where it is slow. Is it slow with all source files or just this one?

First time I tried to reproduce this bug with yatta I couldn't do it (was a dvd with mpeg2dec3 source).

I decided to try something else, a transport stream with dgdecode 1.58 (dvd2avi barfs with this transport stream for some reason) and was able to reproduce the problem as described above (maybe it's specific to dgdecode? mpeg2dec3 seemed unaffected). I suppose dgdecode with any source (doesn't have to be a transport stream) might trigger the problem but this is what I was able to reproduce it with since it's the only thing I really had on hand that I had already saved a dgdecode project with (I generally use dvd2avi for all mpeg2 stuff).

Everything you need:
http://warpsharp.info/random/gosick-avs26-slow.7z

Adjust paths in d2v/yap file then load with yatta (latest 7-131 beta). Hold down the right arrow key (which advances it forwards by 1 frame at a time, holding it down will seek forward) and watch it go really slow (try it again with 2.58 and it'll be fast). Drag around the seek bar too if you want, that'll be slow too. Also, if you hit the preview button (brings up the preview of what it would look like if you loaded the generated script in vdub or something) that preview seems unaffected for some reason.

Although we kind of skipped the ymc step (since I provided the yap for you) it's slow with the preview windows in that as well (cutter and crop, I can't tell if tfm/telecide's preview are affected as they are about the same speed). Avsp and vdub preview seem unaffected and work ok (with loading the avs generated with this yap file (right click anywhere in the video, save all overrides if you like to try it yourself)).

You can find me on Rizon and Freenode (Ryuuchin/TheRyuu) if you want to talk with something a bit more real time than this (i'm in #avisynth on freenode).

[Chikuzen]

when I open a .d2v directly with yatta, yatta goes slow as hell.
however, when I write an .avs like mpeg2source("foo.d2v") and open it with yatta, it seems not to happen.

[Ziddy76]

First time I tried to reproduce this bug with yatta I couldn't do it (was a dvd with mpeg2dec3 source).

I decided to try something else, a transport stream with dgdecode 1.58 (dvd2avi barfs with this transport stream for some reason) and was able to reproduce the problem as described above (maybe it's specific to dgdecode? mpeg2dec3 seemed unaffected). I suppose dgdecode with any source (doesn't have to be a transport stream) might trigger the problem but this is what I was able to reproduce it with since it's the only thing I really had on hand that I had already saved a dgdecode project with (I generally use dvd2avi for all mpeg2 stuff).

Everything you need:
http://warpsharp.info/random/gosick-avs26-slow.7z

Adjust paths in d2v/yap file then load with yatta (latest 7-131 beta). Hold down the right arrow key (which advances it forwards by 1 frame at a time, holding it down will seek forward) and watch it go really slow (try it again with 2.58 and it'll be fast). Drag around the seek bar too if you want, that'll be slow too. Also, if you hit the preview button (brings up the preview of what it would look like if you loaded the generated script in vdub or something) that preview seems unaffected for some reason.

Although we kind of skipped the ymc step (since I provided the yap for you) it's slow with the preview windows in that as well (cutter and crop, I can't tell if tfm/telecide's preview are affected as they are about the same speed). Avsp and vdub preview seem unaffected and work ok (with loading the avs generated with this yap file (right click anywhere in the video, save all overrides if you like to try it yourself)).

You can find me on Rizon and Freenode (Ryuuchin/TheRyuu) if you want to talk with something a bit more real time than this (i'm in #avisynth on freenode).

Yes, exactly. Thanks for confirming that I'm not alone with this issue and describing it so efficiently and detailed. I'm also on Rizon, Zymphad/Zifnab.

[StainlessS]

I came upon this snippet, in the v2.6 header.

#if 0
#define MAX_INT 0x7fffffff
#define MIN_INT -0x7fffffff // ::FIXME:: research why this is not 0x80000000
#endif

This seems to go back some time and possibly written by Ben Rudiak-Gould, himself.
(EDIT: apart from the ::FIXME:: )


Signed Int System Equivalent meaning Result of
under system -0x7FFF,FFFF
of 0x8000,0000

Twos Complement (-MAX_INT) - 1 0x8000,0001 ie -MAX_INT

Ones Complement -MAX_INT 0x8000,0000 ie -MAX_INT

Sign & Magnitude -0 0xFFFF,FFFF ie -MAX_INT


The above "#define MIN_INT -0x7fffffff" is portable across all three positional
number systems regarding signed integers whereas the 0x8000,0000 one is not.

It is only when "Sign & Magnitude" is considered that the reasoning becomes evident.

EDIT: Under Twos Complement, 0x8000,0000 is troublesome anyway with
-(0x80000000) == 0x80000000

[leeperry]

when trying to convert YV12 to YUY2 using "ConvertToYUY2(chromaresample=spline)", I get an error msg saying "too few arguments for spline"...any idea what I'm missing? the wiki isn't too clear on what's expected: http://avisynth.org/mediawiki/ConvertToYUY2

I'm using SEt's 2009.09.19 build and it seems that "ChromaInPlacement" isn't supported in it :(

[IanB]

@leeperry, please don't cross post, the development forum is not that busy that we don't read all the active threads. SEt's build problems should be reported in the SEt thread. Only problems that happen in the versions associated with this thread should be reported here.

For the current official build :-
..., chromaresample="Spline16") # "Spline36" or "Spline64"

[leeperry]

And that works, thanks a lot for the swift reply! Yes I did move my post, as I wasn't sure whether anyone would answer me in the other thread, sorry for that :o

It's a shame that ChromaInPlacement="MPEG1" is no workee in the last 2.60 beta from SEt that supports MT(), though :(

[leeperry]

BTW, all that chroma placement isn't too clear to me :o

rgb3dlut()'s manual says:
cplace - Specifies horizontal chroma placement... used when input is yuy2. Possible settings:

0 - chroma is aligned with left pixel in each pair (mpeg2, mpeg4, h264)

This would be the case if during 4:4:4 -> 4:2:2 conversion odd pixel chroma values were simply dropped, or if an odd length FIR filter centered on the even pixels was used, such as a [1 2 1] kernel.

1 - chroma is centered between each pair of pixels (h261, h263, mpeg1)

This would be the case if during 4:4:4 -> 4:2:2 conversion the chroma of every two pixels was averaged together, or if an even length FIR filter centered between each pair of pixel values was used, such as a [1 4 4 1] kernel.

default: 0

and yv12toyuy()'s manual says:
cplace - Specifies vertical chroma placement. Possible settings:

progressive input (interlaced=false, progressive upsampling):

0 - chroma is aligned with top line of each two line pair within the frame

This would be the case if during 4:2:2 -> 4:2:0 conversion the chroma values of odd lines were simply dropped.

1 - chroma is centered between lines of each two line pair within the frame(*** h261, h263, mpeg1, mpeg2, mpeg4, h264 standard progressive conversion)

This would be the case if during 4:2:2 -> 4:2:0 conversion the chroma from every two line pair was averaged, or if an interlaced 4:2:2 -> 4:2:0 conversion was performed by using 75/25 averaging of top field pairs and 25/75 averaging of bottom field pairs.

I think YUY2 samples chroma once in every 2 pixels in a row, YV12 samples chroma once in every 2x2 pixel block..so if I use ConvertToYUY2(chromaresample="Spline64") + rgb3dlut(lutfile="BT601_SMPTE-C.3dlut",cplace=1) then MPEG1 is all good? I guess "ChromaInPlacement" is only useful when outputting RGB then :o

[IanB]

As the help says :-ChromaInPlacement (added in v2.60): This determines the chroma placement when converting from YV12. It can be "MPEG2" (default), "MPEG1" and "DV".
...
ChromaOutPlacement (added in v2.60): This determines the chroma placement when converting to YV12. It can be "MPEG2" (default), "MPEG1" and "DV".
The assumption for YUY2 is the chroma is always sited with the left luma. Of course if this is incorrect there are tools to correct it.

[leeperry]

I'm mostly asking if going ConvertToYUY2(chromaresample="Spline64") + rgb3dlut(lutfile="BT601_SMPTE-C.3dlut",cplace=1) will provide correct MPEG1 chroma upscaling? from what tritical says, it would very much appear so :o

[IanB]

ConvertToYUY2(chromaresample="Spline64") + rgb3dlut(lutfile="BT601_SMPTE-C.3dlut",cplace=1)

Should be the same workflow as

ConvertToYUY2(chromaresample="Spline64", ChromaInPlacement="Mpeg1") + rgb3dlut(lutfile="BT601_SMPTE-C.3dlut",cplace=0)

How well each flow implements the Mpeg1 chroma correction, you will have to test (or read the code).

Spline64 for a chroma resampler is probably a bit over the top.

[leeperry]

OK, thanks for the confirmation!

Well, I've compared bicubic/spline36/64 for the YV12>YUY2 upsampling, and subjectively I prefer the latter..OTOH, I upscale the chroma from YUY2 to RGB32 in rgb3dlut() using 1.0/0.0 bicubic coeffs as it only supports bicubic and the default 0.0/0.75 rings too much to my taste. madshi advised to try a few other coeffs, I'll do it again soon: http://forum.doom9.org/showpost.php?p=1276180&postcount=426

PS: humm, I think my fav is 0.33/0.33 :)

[leeperry]

Hi again, I can read "Add dither option to Levels" at http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/

How do you do that please? The wiki doesn't say anything :o

[Wilbert]

How do you do that please? The wiki doesn't say anything
I have been lazy lately ;)

Just use Levels(..., dither=true). This holds for RGBAdjust and Tweak as well.

[jmac698]

Bug in crop?

crop(0,0,4,0)
gives me an error with avspmod2.2, "error loading avisynth" which I take to mean that it crashed.

crop(0,0,6,0) gives me a 6x480 image (from 720x480 in YV12)

2.6a3

[Chikuzen]

Bug in crop?

crop(0,0,4,0)
gives me an error with avspmod2.2, "error loading avisynth" which I take to mean that it crashed.

crop(0,0,6,0) gives me a 6x480 image (from 720x480 in YV12)

2.6a3

I think that it's avspmod's bug.
Did you try also VirtualDub?

[jmac698]

Correct,

colorbars(pixel_type="YV12",width=720)
pointresize(crop(0,0,4,0),width,height)

works. Whew!

[Robert Martens]

Bug in crop?

crop(0,0,4,0)
gives me an error with avspmod2.2, "error loading avisynth" which I take to mean that it crashed.

crop(0,0,6,0) gives me a 6x480 image (from 720x480 in YV12)

2.6a3

Crop values are treated as left, top, width, height unless you enter negative numbers as the last two arguments, which treats them as left, top, right, bottom. I think you'd want Crop(0,0,-4,-0) to remove four columns from the right edge of a clip.

[jmac698]

Nope, I want the first 4 pixels of the entire left edge.
It turns out that avsPmod2.20 crashes if displaying 4 pixel wide YV12. However, 6 pixel wide YV12 and 2,4 pixel wide YUY2 work. RGB works at any size.

But that brings up another point. My height should be 0. In fact negative or 0 is treated as difference from border.

[Robert Martens]

Yeah, I just saw your post in the other thread; didn't realize that's what you were trying to do, I thought you were getting unexpected image dimensions, sorry!

[Gavino]

But that brings up another point. My height should be 0. In fact negative or 0 is treated as difference from border.
As stated in http://avisynth.org/mediawiki/Crop.

[jmac698]

Ok,
I can't do subpixel resizing in some resizers, yet the docs say float src_left

#Ideal interpolation demo
#requires masktools v2a48

Global signalwidth=16
blankclip(width=signalwidth,height=8,pixel_type="YV12",length=80)
#sine2(clip template, float "freq", float "phase", float "amp", float "offset")
y=sine2(last.pointresize(signalwidth*2,last.height),2,0,100,128)
#Animate (clip, int start_frame, int end_frame, string filtername, start_args, end_args)
x=animate(0,80,"sine2",last,1,0./signalwidth*360,100,128,last,1,8./signalwidth*360,100,128).mt_lut(u=-100,v=-212)#red
y=animate(0,80,"shift",y,0.,0,y,8,0).crop(0,0,signalwidth,0).mt_lut(u=-212,v=-114)#blue rec601
stackvertical(x,y).pointresize(256,100)
ScriptClip("""
ph=current_frame/10.
subtitle("shift="+string(ph))
""")

function shift(clip v, float x, float y) {
v#shift an image, x>0 shifts left, y>0 shifts up
#bilinearresize(last.width,last.height,x,y,last.width,last.height)
sincresize(last.width,last.height,x,y,last.width,last.height)#subpixel shifting not working!
}

function sine2(clip template, float "freq", float "phase", float "amp", float "offset"){
arg="sin((x*2*pi)*freq+phase/180*pi)*amp+offset"
expr=StrReplace(arg,"amp",string(amp))
expr=StrReplace(expr,"offset",string(offset))
expr=StrReplace(expr,"freq",string(freq))
expr=StrReplace(expr,"phase",string(phase))
expr=mt_polish(expr)
mt_lutspa(template,mode="relative",yexpr=expr)#relative doesn't include 1
#subtitle("phase="+string(phase))
}

Function StrReplace(string base, string sought, string rep){
pos = FindStr(base, sought)
return (sought == "") || (pos == 0) \
? base \
: StrReplace( \
LeftStr(base, pos - 1) + rep + \
MidStr(base, pos + StrLen(sought)), \
sought, rep)
}

[Gavino]

I can't do subpixel resizing in some resizers, yet the docs say float src_left
Does it give an error, or simply not work the way you expected?

Note that different resizers have different edge behaviour, depending on the filter support (ie no of taps).
As I explained in this reply to an earlier query of yours:
To shift left/right by an arbitrary float x pixels (x<0 for right shift), using black beyond original edge, you can do this:
w = width
AddBorders(t, 0, t, 0)
xxxResize(w, height, src_left=x+t, src_width=w)
where t is no less than the number of 'taps' of the resizer used (eg 1 for Bilinear, 3 for Lanczos) - or just fix it at some suitable even number (to cope with YUV constraints), say t=4.

[jmac698]

Just as I said, sinc can't do subpixel resizing. It only does integer increments.