AviSynth 2.6.0 Alpha5 [Sep 18th, 2013]

[Myrsloik]

Originally Posted by foxyshadis

Myrsloik has pointed out that he'd like to support avs+'s final 2.6 (or whatever) API in VS as well, the current lack of compatibility is mainly because it's been changing constantly. With any luck this situation won't last much longer.

...

Just to make it clear, there are actually two obstacles. One is that the 2.6 API changes a bit now and then but that's no big issue since it has kinda settled now (due to slow development in general).

The real problem is that memory offsets for frame data are stored in ints and not a 64 bit type in the x64 version of the API. This is insane, ultim knows about it, and prevents all compatibility ever since VS allocates each plane of a frame individually which means that the "offsets" can be too big to fit.

Summary: 32bit avisynth 2.6 alpha 5 api is easy but I'm a bit lazy, everything else is a mess that's better not supported for now. Avs+ will most likely be cleaner to support once it finishes its api since it's internally closer to VS.

[StainlessS]

Seems to be a bug in AviSource as previously posted here: http://forum.doom9.org/showthread.ph...62#post1675662

Concerns techSmith TSCC2 codec, decoder only, found here: https://support.techsmith.com/entrie...andalone-codec

2007 Thread with same unresolved problem here: http://forum.doom9.org/showthread.ph...ce#post1062041

and a 27MB HD sample that exhibits the problem here : http://www.mediafire.com/download/7v...r+avisynth.avi
(courtesy of user eduardobedoya, thank you)

DirectShowSource successfully loads and plays clip, AviSource produces lots of black frames, presumably drop frames.

Vdub current and VdubMod have no problems loading/playing/seeking sample.

[Nevilne]

Not sure where to post this but TCPServer doesn't work with YV24 clips, it only transmits 1/4 cut of chroma to TCPSource but still marks clip as YV24. RGB, YV12 and YV24 planes in RGB (which is expensive for hi res clips) work fine.

[StainlessS]

Bug ChromaUDifference returns NaN indeterminate for Y8. (EDIT: Presumably ChromaVDifference also, untested)

Blankclip(pixel_type="Y8")
ScriptClip("""subtitle(string(ChromaUDifference(Last,Last)))""")
return last.convertTorgb

shows "-1.#IND00".

[TheFluff]

What behavior would you expect? It's an invalid operation, NaN seems like a perfectly reasonable thing to return to me. Throwing an exception would probably be a better idea though.

[StainlessS]

Originally Posted by TheFluff

Throwing an exception would probably be a better idea though.

Exactly.

[Wilbert]

Bug ChromaUDifference returns NaN indeterminate for Y8.

I guess the proper behaviour is to output an error message right? Holds for all its variants too.

edit: too late

[Groucho2004]

Originally Posted by StainlessS

Bug ChromaUDifference returns NaN indeterminate for Y8. (EDIT: Presumably ChromaVDifference also, untested)

Blankclip(pixel_type="Y8")
ScriptClip("""subtitle(string(ChromaUDifference(Last,Last)))""")
return last.convertTorgb

shows "-1.#IND00".

Yes, it's a division by zero in "ComparePlane::CmpPlane()" (in this particular case). Checking the (float) return value with something like this:

 if (_finite(f) == 0)
  env->ThrowError("Return value infinite or NaN");

would catch it. However, installing a local/global FP exception handler would be nicer although it could impact performance.

[StainlessS]

If called with RGB, shows error "Plane Difference: Only Planar images (As YV12) supported!".
No reason why Y8 could not be detected before division by zero occurs.

EDIT: Simlar failures on AverageChromaU, UDifferenceToNext (probably UDifferenceFromPrevious)

UPlaneMax returns 0
UPlaneMin/UPlaneMedian/UPlaneMinMaxDifference return 255

and probably same for V variants.

[ARDA]

Originally Posted by StainlessS

If called with RGB, shows error "Plane Difference: Only Planar images (As YV12) supported!".
No reason why Y8 could not be detected before division by zero occurs.

I guess is cause Y8 is also planar. Some testing is lacking.

[Gavino]

Originally Posted by StainlessS

If called with RGB, shows error "Plane Difference: Only Planar images (As YV12) supported!".
No reason why Y8 could not be detected before division by zero occurs.

Yes, the obvious place to catch these errors is in the sanity checks at the start of each function, where the input clip properties are already being checked.

[vcmohan]

Is Avisynth 2.6 natively multithread capable. I find that there are various levels of multithreading. One post of avisynth+ states that plugins should specify which level of multithreading is required. If so how to specify this in 2.6? Or one need to call Avisynth.MT specifically?I am confused as a thread Avisynth.MT is also in the forum.

[turbojet]

This build isn't capable of multithreading. AvisynthMT and latest "test" build of Avisynth+ are. Plugins can have internal multithreading, nnedi3 is one of these and should fully load cpu no matter how many cores or avisynth is used.

[vcmohan]

Avisynth+ for parallel processing specifically advises the plugin authors not to multithread internally themselves in the plugin.

[turbojet]

I think it's because they want to be able to handle all threads internally, which makes sense but also requires very stable and complex threading. If all plugins had multithreading there'd be no need for a custom avisynth build. While I know its avisynth+ focus for internal multithreading I think it's too soon to say what's really going to happen since all that's been released is a test build and development seems to be on hiatus.

If I was a plugin developer I'd still try to multithread plugins, after all all that's needed to disable it is to set threads=1.

[huokok]

Hi, I'm a beginner using avisynth and noticed, should I say a minor problem.
I am handling with an anomophic video, after resizing and adding subtile, I noticed that avs behaves differently from normal playing back. Here I mean using Lav and xy-vsfilter for normal palying back.
By default, xy-vsfilter disables PAR compensation, which is exactly the same in Aegisub, as well as normal playing back. I have checked that the VSFilter plugin contained in meGUI (I am using meGUI for encoding) is actually the same with my installed xy-vsfilter (VSFilter.dll).
May I ask why avs deals with .ass files in such way? Or am I misunderstanding something?

[StainlessS]

@huokok, This is the developer forum, try Newbie or Usage forums.

Not sure if this is a caching bug, but it seems weird.

AVISource("D:\AVS\JurassicPark.avi")
ORG=Last
DEL=3

A=ClipBlend(delay=DEL,exponential=true)     	 # Every 30 frames requests frame twice from this clip.
B=ClipBlend(delay=DEL,exponential=false)         # but not this one
D=Subtract(A,B)
Q=Stackvertical(ORG,D)
R=StackVertical(A,B)
StackHorizontal(Q,R)
return Last

Requests same frame twice, every 30 frames from clip A, but not from clip B.
The ClipBlend filters are not relevant, its just that I have debugging enabled in them right now.

Is this expected behaviour ?

EDIT:

D=Subtract(B,A)

Requests twice from clip B instead of clip A.

Perhaps does in place subtract rather than NewVideoFrame, but still, should cache not jump in here when MakeWritable called ?

Why every 30 frames, SetMemoryMax(256) and SetMemoryMax(1024) make no difference.

EDIT: Script producing same results

TWICE = True

AVISource("D:\AVS\FlashTest.avi")
ORG=Last
Global A_Frame = -1
Global B_Frame = -1

Function A_fn(clip c) {
    c.ScriptClip("""
        (current_frame == A_Frame) ? RT_debugF("%d] A called twice",current_frame)  : NOP
        Global A_Frame=current_frame
        return (TWICE) ? Last.invert : Last
    """,after_frame=true)
}

Function B_fn(clip c) {
    c.ScriptClip("""
        (current_frame == B_Frame) ? RT_debugF("%d] B called twice",current_frame) : NOP
        Global B_Frame=current_frame
        return (TWICE) ? Last.invert : Last
    """,after_frame=true)
}

A=A_fn()
B=B_fn()
D=Subtract(A,B)
# Return D                    # On about 7300 frames does not request any frame twice
L=Stackvertical(ORG,D)
# Return L                     # On about 7300 frames does not request any frame twice
R=StackVertical(A,B)
#Return R                     # On about 7300 frames does not request any frame twice (D and L play no part in output clip)
StackHorizontal(L,R)          # Request frame twice every 30 frames
return Last

EDITED: Changed to After_Frame=True

Results:

00000001    0.00000000  RT_DebugF: 0] A called twice      # ???
00000002    0.02283134  RT_DebugF: 1] A called twice      # ???
00000003    1.13505709  RT_DebugF: 29] A called twice
00000004    2.33850622  RT_DebugF: 59] A called twice
00000005    3.53572321  RT_DebugF: 89] A called twice
00000006    4.73558807  RT_DebugF: 119] A called twice
00000007    5.93475008  RT_DebugF: 149] A called twice
00000008    7.13609219  RT_DebugF: 179] A called twice
00000009    8.33965588  RT_DebugF: 209] A called twice
00000010    9.53348637  RT_DebugF: 239] A called twice
00000011    10.73409081 RT_DebugF: 269] A called twice
00000012    11.93526363 RT_DebugF: 299] A called twice
00000013    13.13406563 RT_DebugF: 329] A called twice
00000014    14.34332275 RT_DebugF: 359] A called twice
00000015    15.53387451 RT_DebugF: 389] A called twice
00000016    16.73608208 RT_DebugF: 419] A called twice
00000017    17.93279266 RT_DebugF: 449] A called twice
00000018    19.13314247 RT_DebugF: 479] A called twice
00000019    20.33571243 RT_DebugF: 509] A called twice
00000020    21.53307343 RT_DebugF: 539] A called twice
00000021    22.73343849 RT_DebugF: 569] A called twice
00000022    23.93457794 RT_DebugF: 599] A called twice
00000023    25.13291740 RT_DebugF: 629] A called twice
00000024    26.33256149 RT_DebugF: 659] A called twice
00000025    27.53370094 RT_DebugF: 689] A called twice
00000026    28.73566055 RT_DebugF: 719] A called twice
00000027    29.93317223 RT_DebugF: 749] A called twice
00000028    31.13321686 RT_DebugF: 779] A called twice
00000029    32.33431244 RT_DebugF: 809] A called twice
00000030    33.53618240 RT_DebugF: 839] A called twice
00000031    34.73554611 RT_DebugF: 869] A called twice
00000032    35.93282318 RT_DebugF: 899] A called twice
00000033    37.13544846 RT_DebugF: 929] A called twice
00000034    38.33409500 RT_DebugF: 959] A called twice
00000035    39.53222275 RT_DebugF: 989] A called twice
00000036    40.73387527 RT_DebugF: 1019] A called twice
00000037    41.93296814 RT_DebugF: 1049] A called twice
00000038    43.13276672 RT_DebugF: 1079] A called twice
00000039    44.33391953 RT_DebugF: 1109] A called twice
00000040    45.53221130 RT_DebugF: 1139] A called twice
00000041    46.73321152 RT_DebugF: 1169] A called twice
00000042    47.93227768 RT_DebugF: 1199] A called twice
00000043    49.13507843 RT_DebugF: 1229] A called twice
00000044    50.33272552 RT_DebugF: 1259] A called twice
00000045    51.53367996 RT_DebugF: 1289] A called twice
00000046    52.73460770 RT_DebugF: 1319] A called twice
00000047    53.93500900 RT_DebugF: 1349] A called twice
00000048    55.13346863 RT_DebugF: 1379] A called twice
00000049    56.33296204 RT_DebugF: 1409] A called twice
00000050    57.53406143 RT_DebugF: 1439] A called twice
00000051    58.73265076 RT_DebugF: 1469] A called twice
00000052    59.93371201 RT_DebugF: 1499] A called twice
00000053    61.13440704 RT_DebugF: 1529] A called twice
00000054    62.33270264 RT_DebugF: 1559] A called twice
00000055    63.53389740 RT_DebugF: 1589] A called twice
00000056    64.73960876 RT_DebugF: 1619] A called twice
00000057    65.93464661 RT_DebugF: 1649] A called twice
00000058    67.13314819 RT_DebugF: 1679] A called twice

Checked on three machines, 1st 3GB ram, 2nd 1.5 GB, 3rd 1.GB, same results, every 30 frames called twice.
Tested on 720x576 PAL and 640x400 PAL, same results.

Tested on 32x32 YV12 25 FPS, same again, called twice every 30 frames, memory seems not to be the issue.

Affects:- Avisynth v2.6Alpha4, Avisynth v2.6Alpha5, Avisynth v2.6+r1576
Not Affected:- Avisynth v2.57, Avisynth v2.58, Avisynth v2.6Alpha3

This has to be a bug.

[StainlessS]

Can someone please verify above post as a genuine bug.
Thank you in advance.

Could have bad consequences for any temporal filter that relies on
playing through from start to end without jumping about on the timeline.
(Even those filters that can scroll both forwards or backwards 1 frame at a time,
but dont expect to be asked for the same frame twice, as cache usually works most of the time).

[TheFluff]

Why do you care? Making assumptions about caching behavior is a terrible idea. If your implementation of GetFrame isn't idempotent you deserve everything terrible that could possibly happen to you and if Avisynth actually had a real API you'd be violating it. Making assumptions about frame request order is also an incredibly horrible idea.

[StainlessS]

So everything is Okey Dokey then, you're such an excessively jovial fellow (as usual).