AviSynth 2.5.8 Alpha 2 [September 19th] - Release!

[Wilbert]

work fine with VirtualDub v1.7.7 (Decompressor: YCbCr 4:2:0 Planar YV12)
VirtualDub uses its own YCbCr -> RGB converter (for display) since a while.

Same problem than you using VirtualDubMod v1.5.10.2 (Decompressor: Xvid MPEG-4 Codec)
VirtualDubMod doesn't. So set this vidc.yv12 thingie in your registry to xvidvfw.dll or whatever MPEG-4 ASP codec you have installed. See YV12 FAQ.

[Fizick]

Yes, new VirtualDub has option in preferences "directly uncompress YCrCb (YUV) sources".

I reinstall HelixYUV codec, and now all is correct.
(without Color Converter in Graphedit)
But the Helix was installed previously, probably some "smart" program partially disabled it.
Thanks to all. :)

May be some moderator can cut this part of posts and merge to YUV12 faq http://forum.doom9.org/showthread.php?t=37276

[Fizick]

One more suggestion :)
Converttoyv12 gives throw exception error (''matrix...."), if I try convert YV12 to YV12 or YUY2 to YV12 with matrix=XXX option.
It is really not error, but sort of warning (matrix will not be used, of course). I suggest to remove the message.

[IanB]

@Fizick,

Yes there are a number of these "Warning" level exceptions throughout Avisynth.

For the Novice user I think they help them avoid a lot of pitfalls, but for the Advanced user they tend to cripple usage inside library functions.

We probably need to implement a graded error level, a bit like the compiler warning/error level concept.

For maximum usefullness I think being able to "Push" and "Pop" as well as just setting the tolerance level could be nice.

Thoughts?

[Fizick]

warning level is great idea. Somewhat similar to:

if (OPT_ErrorLevel > WARNING_LEVEL) ThrowError (...)

[Wilbert]

I saw that Avery is creating an 'Directshow Input Driver' for VirtualDub. I noticed the following comment of him:

Avisynth's DirectShowSource() uses PulseEvent(). This is a no-no, as PulseEvent() has known bugs in the Windows kernel with losing wakeups if a kernel APC happens at the wrong time. Thought I'd told someone about this, but I guess it couldn't hurt to go file a bug.
http://forums.virtualdub.org/index.php?act=ST&f=7&t=15093&

What does PulseEvent do, and is there a way to avoid it?

Oh, when reading the remainder of that thread, i see that you have been participating in it :)

[Fizick]

v2.5.7

script:


testcard = ColorBars()
BlankClip(clip=testcard, color=$0f0fb4)


---------------------------
VirtualDub Error
---------------------------
Avisynth open failure:
Script error: the named argument "clip" was passed more than once to BlankClip
(F:\Internet\080222\AviSynth Script.avs, line 4)
---------------------------

[Fizick]

addition: the scipt above works well in Avisynth v2.5.5, but does not in 2.5.6 and above.
It is example from "overlay" documentation.

Probably is was canged in:

Revision 1.14 - (view) (download) (annotate) - [select for diffs]
Tue Jan 25 04:53:58 2005 UTC (3 years, 1 month ago) by ianb1957
Branch: MAIN
Changes since 1.13: +7 -4 lines
Diff to previous 1.13
BlankClip() not use implicit Last clip as Template

[squid_80]

Using it without the argument name works...

[IanB]

Okay, it's bug in the parser, you cannot name the 1st argument (bad boundary code).

[DeathTheSheep]

Alpha 2 has been out for a very long time, and its directshowsource is hopelessly broken. Please tell me there's some hope of an alpha 3 with fixed directshowsource--or a fixed directshowsource with the new features for alpha 2.
The entire alpha 2 is utterly useless without the power of directshowsource; has nobody cared to fix it? Or is the fixed dll/binary just not posted on sourceforge?


IanB, any word on this?

[Didée]

Oh, I didn't even note that DSS is broken. Seems I don't use it that often.

The entire alpha 2 is utterly useless without the power of directshowsource
Isn't there someone utterly exaggerating? I mean, example, now that we have seen the potential of VAQ 2.0 for x264, you could as well say that x264 is utterly useless with any earlier versions of VAQ. Would you please immediately stop using x264 for anything, until VAQ 2.0 is out!! :p

[DeathTheSheep]

Well said, indeed. But as they say, strong words are oft necessary for small change. ;)

And as regards your VAQ comment, VAQ 0.45 is very, very good--perhaps significantly more so than 0.48 (and that is no exaggeration, see the test). So I'm not always the promoter of the most modern, you see. :p

But I'm not exactly sure I should sit here silently with a broken alpha 2 when all the cool new dshowsource features have been announced but...failed to deliver. So why not let'em know somebody at least wants it working!

[Wilbert]

@IanB,

I was looking at ImageWriter, because I needed it :)

From the docs of ImageWriter:

# Write frame 5 to "C:\000000.PNG"
ImageWriter("", 5, 5, "png")
# note: prior to v2.56 the output filename would be "000005.PNG"

I'm not sure how that comment got there, but the frame is still saved as "000005.PNG", which is good as far as i'm concerned. So i will correct that example.

Also:
start and end are the frame range that will be written. They both default to 0 (where end=0 means last frame)
This behaviour is non-consistent (and worse it's not possible to save only the first frame using start/end). When setting start=end=0 it would be consistent to save only the first frame (as "C:\000000.PNG"). Replacing the code

// check bounds (where end=0 implies no upper bound)
if (n < start || (end > 0 && n > end))
...
AVSValue __cdecl ImageWriter::Create(AVSValue args, void*, IScriptEnvironment* env)
{
return new ImageWriter(args[0].AsClip(),
env->SaveString(args[1].AsString("c:\\")),
args[2].AsInt(0),
args[3].AsInt(0),
env->SaveString(args[4].AsString("ebmp")),
args[5].AsBool(false), env);
}

by

// in constructor:
// check bounds
if (end>vi.num_frames-1)
env->ThrowError("ImageWriter: make sure that end<framecount(clip)");
if (start>end)
env->ThrowError("ImageWriter: make sure that start<=end");

// in GetFrame:
// check bounds
if ((n<start)||(n>end))
...
AVSValue __cdecl ImageWriter::Create(AVSValue args, void*, IScriptEnvironment* env)
{
return new ImageWriter(args[0].AsClip(),
env->SaveString(args[1].AsString("c:\\")),
args[2].AsInt(0),
args[3].AsInt((args[0].AsClip()->GetVideoInfo().num_frames)-1),
env->SaveString(args[4].AsString("ebmp")),
args[5].AsBool(false), env);
}

corrects that problem.

[IanB]

@Wilbert,

Yes, this Last=0 concept I really do not like, but it is what has become the "Avisynth Way".

What is missing here (and in other places, I am sure, as well) is the -1 case processing.

[Wilbert]

@Wilbert,

Yes, this Last=0 concept I really do not like, but it is what has become the "Avisynth Way".
The behaviour among filters is not consistent. In Trim(x,0) it means the end of the clip, but in Loop(times,x,0) it means Loop(times,x,x). I guess it's too late to change any of this :)

What is missing here (and in other places, I am sure, as well) is the -1 case processing.
So (start=0, end=-1) should return frame 0, and (start=0, end=0) the whole clip?

[IanB]

I guess it's too late to change any of thisSigh! :(
So (start=0, end=-1) should return frame 0, and (start=0, end=0) the whole clip?Yes, in the general case end=-N should return N frames

edit mod: removed new feature request, see: http://forum.doom9.org/showthread.php?t=137991

[mikeytown2]

The behaviour among filters is not consistent. In Trim(x,0) it means the end of the clip, but in Loop(times,x,0) it means Loop(times,x,x). I guess it's too late to change any of this :)

So (start=0, end=-1) should return frame 0, and (start=0, end=0) the whole clip?

You could make 2.6 break it. 2.0 to 2.5 broke some stuff. How would you fix it, which way would you consider to be the "correct" way?

[Manao]

The proper way imho is trim(x,y) keeping frames [x, y[, ie includes x and excludes y. That way, trim(x,y) + trim(y,z) gives trim(x,z), which is practical and avoid headaches.

[IanB]

@Manao,

This is as per Stickboys Trim2() function?

[Manao]

Yes. The other nice thing is that trim2(x, y) does return y-x frames, not y-x+1.