AviSynth 2.5.7 Alpha 3 [April 22nd]- DIAG Release!

[IanB]

AviSynth 2.5.7 Alpha 3 (April 22nd):

Special diagnostic build!

Notice: This build has the debug messages from src/core/main.cpp enabled to interrogate the interaction with various packages and the windows COM environment. Use DebugView (http://neuron2.net/dbgv.zip) or the debugger to access these messages. Apart from this diagnostic feature this is a normal fully functional release build with a normal installer.
Notice: User who experience installer problems could you please run the previous 2.5.7 Alpha 2 release in order to gather additional information about your problem. Please take screen grabs with both message boxes arranged to be non-overlapping.

Features

DirectShowSource() enhancements.
Added KillVideo() verb.
TimeStretch SoundTouch library update, fixes and tuning parameter.
File input/output support for WAVE_FORMAT_IEEE_FLOAT audio.
File input more than 2 channels in the audio stream.
Installer enhancments.
Avisynth_c interface enhancments.
Hack for Fraunhoffer MP3 codec to work when wBitPerSample==16.
Added Portugese translation by RoLon.
Partly updated French translation by JasonFly.
Subtitle multi line text.
xxxFPS("preset") string preset FPS values.
Fixed Negative int arg handling for ApplyRange() and Animate().
Fixed SaveString memory block overrun.
Fixed $Plugin!Functionname!Param$ bug.
Fixed Various resource leaks.
Fixed runtime mixed SEH/C++ exception handling for XPsp2.
Fixed CAVIStreamSynth::Read audio buffer overrun.
Fixed Assert("...%...") crash.
Fixed Number parser returning inaccurate float conversions.
Fixed resizer subpixel shifting functionality.
YUV ColorBars now match BT.801-1.
TCPDeliver updates, crash fixes and enhancments.
Fixed Turn*() YUY2 mod 2 height test.
Fixed AVISource() corrupted error messages.
Fixed AVISource() direct input drop frame handling.
Remove 50 plugin auto prescan load limit.
Bracketless call of argless function now get a cache.
xxxFPS(float) now uses continued fraction to generate a minimal rational pair.
ConvertFPS() blend mode works for all pixel formats.
SaveString memory blocks are now 32 bit aligned.
Default planar chroma planes mod 16 aligned.


As usual download from Sourceforge (http://prdownloads.sourceforge.net/avisynth2/AviSynth_220406.exe?download).

Seeing the anon CVS server is presently not being sync'd here are source zipfiles of the modified source files, AviSynthSrc+257.zip (http://prdownloads.sourceforge.net/avisynth2/AviSynthSrc+257.zip?download) and modified doc files, AviSynthDocs+257.zip (http://prdownloads.sourceforge.net/avisynth2/AviSynthDocs+257.zip?download)

[Mug Funky]

sweet! thanks.

TimeStretch SoundTouch library update, fixes and tuning parameter.

this looks interesting. what's changed? or should i check soundtouch site for that?

[IanB]

Yes check the site for the nitty gritty of the library. It's mostly bug fixes and accuracy enhancments. From the AVS side you can now set the tuning parameters. I always found the defaults way to long to do good speech speedup.

[Fizick]

IanB,
What do you want to test with debug build (messages)?
How we can help? What to do?

[Dreassica]

Tried using a dehalo_alpha on a simple tivtced d2v, no resize, plain dvd resolution, using this build i get Diagonal white/black stripes on the video, 2.5.6 doesnt have that.


used avs

function DeHalo_alpha(clip clp, float "rx", float "ry", float "darkstr", float "brightstr", float "lowsens", float "highsens", float "ss")
{
rx = default( rx, 2.0 )
ry = default( ry, 2.0 )
darkstr = default( darkstr, 1.0 )
brightstr = default( brightstr, 1.0 )
lowsens = default( lowsens, 50 )
highsens = default( highsens, 50 )
ss = default( ss, 1.5 )

LOS = string(lowsens)
HIS = string(highsens/100.0)
DRK = string(darkstr)
BRT = string(brightstr)
ox = clp.width()
oy = clp.height()
uv = 1
uv2 = (uv==3) ? 3 : 2

halos = clp.bicubicresize(m4(ox/rx),m4(oy/ry)).bicubicresize(ox,oy,1,0)
are = mt_lutxy(clp.mt_expand(U=uv,V=uv),clp.mt_inpand(U=uv,V=uv),"x y -","x y -","x y -",U=uv,V=uv)
ugly = mt_lutxy(halos.mt_expand(U=uv,V=uv),halos.mt_inpand(U=uv,V=uv),"x y -","x y -","x y -",U=uv,V=uv)
so = mt_lutxy( ugly, are, "y x - y 0.001 + / 255 * "+LOS+" - y 256 + 512 / "+HIS+" + *" )
lets = mt_merge(halos,clp,so,U=uv,V=uv)
remove = (ss==1.0) ? clp.repair(lets,1,0)
\ : clp.lanczosresize(m4(ox*ss),m4(oy*ss))
\ .mt_logic(lets.mt_expand(U=uv,V=uv).bicubicresize(m4(ox*ss),m4(oy*ss)),"min",U=uv2,V=uv2)
\ .mt_logic(lets.mt_inpand(U=uv,V=uv).bicubicresize(m4(ox*ss),m4(oy*ss)),"max",U=uv2,V=uv2)
\ .lanczosresize(ox,oy)
them = mt_lutxy(clp,remove,"x y < x x y - "+DRK+" * - x x y - "+BRT+" * - ?",U=2,V=2)

return( them )
}

function m4(float x) {return(x<16?16:int(round(x/4.0)*4))}
mpeg2source("G:\file.d2v")
TFM(order=1,mode=0,d2v="G:\filey.d2v")
tdecimate(1)
DeHalo_alpha(brightstr=1.0,darkstr=1.0, lowsens=50, highsens=70, rx=2.0, ry=2.0)
limiter()

[foxyshadis]

Upgrade masktools, it caused that before the latest version. In case it's something else, try using SetLegacyPlanarAlignment() after the function call.

[keep forgetting that avisynth works backwards...]

[ChronoCross]

the alpha's break support with mencoder for me. reverting to the latest 2.5.6 restores functionality in mencoder. The mencoder issue does not effect x264 cli or xvid_encraw.

[matrix]

I'm getting this error all the time I try to open a script. Once I close the message, the script opens OK.
If I leave ImgLib.dll in the plugins folder, avisynth won't work at all.
I've been using 2.55 for a very long time, because of this problem.
Is there something I'm missing?

[IanB]

@Fizick,

Principally the problem fccHandler reported with M$ MediaEncoder9 where it won't exit completly and holds onto gobs of resources. (the posts are about 3/4 of the way down the old 2.5.6 thread). But any issue to do with the way the COM (aviFile) interface works (or doesn't ;) )

Does anyone have a current email for fccHandler, he seems to be off on sabatical and not reading his PM's.

@Dreassica,

I have complained before about superdupercinamascopewidescreen code blocks in posts! Please edit your post so it fits comfortably inside a 1024 pixel screen width (or narrower).

@ALL,

If a post is to hard to read I won't answer it!

@Dreassica, foxyshadis, ChronoCross,Default planar chroma planes mod 16 aligned.1. Put SetLegacyPlanarAlignment() After the call to your broken pluggin, (last line if you are slack :D ).

2. Upgrade to a pluggin version that doesn't make invalid assumptions about plannar alignment / Complain to the pluggin author about the issue, they need to have this fixed before 2.6 hit's the streets.

@matrix

You are missing one of the .DLL libraries imgLib is dependant upon. Install the missing files. :search: (Also a new version was release just a few days ago).

[squid_80]

I believe his email is fcchandler at comcast.net but he says he doesn't check it often.
Also this:
http://forums.virtualdub.org/index.php?act=ST&f=2&t=11999&hl=&#entry48743

If I were a conspiracy nut, I might suggest MS "took care" of him for adding wmv and asf support to vdub-mpeg2. :sly:

[ChronoCross]

Well then it's one of these...

DGDecode
ColorMatrix
crop( 4, 0, -4, -2)
LanczosResize(720,480) # Lanczos (Sharp)
Convolution3D("movielq") # Heavy Noise

my bet is on convolution3D. However I don't think it will ever be updated. which is too bad cause it works nicely on things plus it's a filter used in megui so that could lead to a future problem.

[ChronoCross]

Unless someone knows how to update it

[Zarxrax]

Regarding the framerate, why is there "pal_video" and "pal_film" values, if they are both the same thing? It would be much simpler to just simply have a "pal" value.

Reasoning for this is for when telling other people what to use... you tell them to use one or the other, and then they will come back with "whats the difference, i thought pal doesnt have a difference between film and video", and then you have to say, "yea, well, there isn't any difference between them, avisynth just has two different framerate values for pal, but they are both exactly the same, so it doesnt matter which you use."
And then they end up all confused :\

[IanB]

@ChronoCross,

I had a quick look at the source for Con3D and it looks pretty healthy. Most likely you are not using the most recent DGDecode, it was fixed only recently.

@Zarxrax,

A bit late to squeak now, I loaded the initial release with every possible verb I could think of, the intention being to provoke discussion and then cull it down to a small rational selection. The response was pretty mediocre. So the cull was pretty arbitary.

My rational was to be able to incrementally build selector strings easily. i.e. ["ntsc", "ntsc_round", "pal"] + "_" + ["video", "film", "double", "quad"]

[ChronoCross]

I'm using DGindex 1.47 b5. I see nothing in b6's changelog that would seem to indicate otherwise. hmm what to do. I'll see about removing each filter individually. it'll take a few days due to me being busy but I'll get it done.

Edit: it seems it is DGINDEX. but SetLegacyPlanarAlignment() is not a function in avisynth so I can't test if that fixes it.

[IanB]

You say you are running DGDecode 1.4.7, this was fixed in 1.4.0, I will check it.

And opps the code seems to have lost a default, I will add "True" as the default. In the mean time this should fit the bill.Mpeg2Source("file.d2v")
SetPlanarLegacyAlignment(True)
...other stuff.

[tritical]

@ChronoCross
I think the issue is probably with mencoder's avisynth demuxer. I only looked at demux_avs.c for a minute or two but I already see:

curr_frame = AVS->avs_get_frame(AVS->clip, AVS->frameno);
if (!curr_frame)
{
mp_msg(MSGT_DEMUX, MSGL_V, "AVS: error getting frame -- EOF??\n");
return 0;
}
if (avs_has_video(AVS->video_info))
{
dp = new_demux_packet(curr_frame->vfb->data_size);
sh_video->num_frames_decoded++;
sh_video->num_frames++;

d_video->pts=AVS->frameno / sh_video->fps; // OSD

memcpy(dp->buffer, curr_frame->vfb->data + curr_frame->offset, curr_frame->vfb->data_size);
ds_add_packet(demuxer->video, dp);

}

which seems doomed to failure... but its 2a.m. so I might be missing something ;).

[IanB]

Pitch, what pitch? Planar data, what planar data? Well thats certainly an accident waiting to happen.

And you just can't tell some people. Here is a snippet from avisynth_c.h// AVS_VideoFrameBuffer is layed out identicly to VideoFrameBuffer
// DO NOT USE THIS STRUCTURE DIRECTLY
typedef struct AVS_VideoFrameBuffer {
BYTE * data;
int data_size;
...Gee I wonder how it copes with the effect of an ordinary Crop() or SeparateFields()

[fccHandler]

@IanB:
Thanks for trying to fix the problem with WME9!

I installed Avisynth 2.5.7 Alpha 3, then I tried a quick test using the VC6 debugger (Build->Start Debug->Attach to Process->wmenc).

Unfortunately, just as I started encoding, a "protection error" message box popped up stating that a debugger was detected and I would have to shut everything down and restart. (I believe this crap comes from the old DivX 5.1.1 codec.)

I copied the VC6 output anyway; maybe it will help you:
http://fcchandler.home.comcast.net/Debugger.zip

[IanB]

Thanks for the dump, apart from the evil protection wrapper it looks pretty normal.

And yes DivX dabbled with these wretched protection wrappers about then, I think Avery had a bit to do with them coming to their sense in latter versions.

The other dopey paranoids are Nero. They are still seriously inconvieniencing the general developer world. Unfortuanatly you will have to regsrvr32 /unload all the NE*.AX modules.

[Zarxrax]

The fps presets don't work inside of things like directshowsource. Could this be implemented in there as well?

Example: DirectShowSource("file.wmv", fps="ntsc_film")

[foxyshadis]

I had some insight while thinking about VFR and avisynth tonight, and I was wondering whether it's possible for avisynth to include some sideband info on frame timings, so most of the messy hacks to get vfr from avisynth can just go away.

Basically my ideal is that tdecimate's output can be returned in the avistream itself, I suppose as some kind of private header, that can be saved in vdub's output avi for the benefit of muxers, or transmitted directly to the output module for more advanced encoders. Perhaps even loading from directshowsource can benefit from this, no more having to force vfr formats into cfr and reprocess them afterward. I wouldn't mind hunting down other programs' pain points if it'd ease the transition. Basically, it's just to make vfr as painless as possible.

Does avistream support any kind of extra data per-frame? (Because not all types of vfr can be loaded beforehand.) If not, that might shut the sideband idea down quickly, unless you want to play dirty games like using hints (again), named pipes, or whatever...

I guess this is probably a 2.6 issue, but this thread is current, so.... I just want to hear whether it's a feasible idea.

[Fizick]

Small request:
Add explicit matrix="Rec601" parameter string value to ConverttoYUY..
Now it must be omitted for default.

[TheFluff]

@foxyshadis: An interesting idea, but the obvious problem would be to get the encoding program to do anything useful with the timecodes. The only program that I'm aware of that goes directly from Avisynth to a VFR-capable format is x264. An alternative would be to output a separate timecodes file together with the video output. Making Avisynth VFR-aware opens up for some interesting possibilities:

avisource("foo.avi").LoadTimecodes("bar.vfr.txt")
#CFR video is now VFR
selectevery(2,0)
#timecodes are now modified
textsub("something.ssa")
#you don't need to vfrtransform subs before hardsubbing!
TimecodeFormat("v2")
#default is output format == input format?
TimecodesOutput("X:/bar/foo.txt")
#gotta tell it where to put them
directshowsource("glarch.mkv")
ConvertToCFR(23.976)
#like "directshowsource(convertfps=true)"?
directshowsource("foo.mkv")
AssumeCFR(23.976)
#might be useful for something, I dunno...

The possibilities are endless...

[foxyshadis]

Well, I know virtualdub would never do anything useful with it, but I hoped other engines (like x264 or xvid_encraw, for instance) could. However, for those that can't, a timecode input/output would be a decent solution as well.

I do realize there are some hard questions about importing video (probably have to read the entire file and record timecodes somewhere) and how trim and others would work. One thing I would not want is to replace everything frame-based with time-based, except as a possible alternative.

[Wilbert]

@IanB,

About clips starting with non-key frames and SegmentedAviSource. Is there an easy way to fix the following problem:

http://forums.virtualdub.org/index.php?act=ST&f=6&t=7377

When capping with ffvfw using segments, the second (and third, fourth, ...) segment starts with a delta frame, making it impossible to use SegmentedAviSource to load all segments. I think it's a VDub bug, but i'm not sure avery will fix it anytime soon.

Sh0dan gave the following comment about it:

http://sourceforge.net/tracker/index.php?func=detail&aid=1005602&group_id=57023&atid=482676

[IanB]

@Wilbert,

I had a look at this a while ago and although the code has been pinched from VDub, someone has done a real good job on it to remove the stream level splicing and I couldn't see an easy way to readily put it back. It is a pity because this code knew how to auto find the next segment. It's removal is also the reason why AVS has a 60 to 70 file segments limit.

I have on my to do list to reimport the VDub code to pick up all of Avery's bug fixes but it will be a big project. Doing this properly could kill a lot of problems and create a lot of new ones.

[Mug Funky]

on a slightly different matter, i was wondering if antialiasing could be optionally turned off in "subtitle()"?

i ask because when i get some spare time i'd like to write an stl subtitle importer inside avisynth. multiline subs are a real help, and i can get 90% there with that.

however, .stl (DVDmaestro's sub format) allows bitmaps to be loaded as well. naturally these aren't antialiased, and it'd look weird to combine antialiased subs with nonantialiased ones.

the only way i have currently to get stl subs into avisynth is to compile the feature with subs in Spruce, then rip with vobsub...

it probably isn't a big deal - i might be able to fudge an antialias on the bmp subs for now without it looking too weird.

[IanB]

@Mug Funky,

Sorry, the antialiasing can't be just switched off. Writing a companion filter would not be very hard, mainly shreading the existing code.

Add a Feature Request on SourceForge so it won't get forgotten, also ask for variable aspect ratio text in the same request.

If you can generate your .BMP's very large, say 8 times big. You could simulate some of the antialiasing algorithm with aLanczosResize(Width()/8, Height()/8, taps=8)Getting the 0.5 pixel shadow border as well will require some ingenuity with layer/overlay.

[Zarxrax]

Someone just brought this to my attention, and I took a look at it, and it seems wrong to me.

If I load a file through MPEG2Source and then do a ConvertToRGB on it, I have the option of choosing from the various color matrixes, to specify if the color should be pc scale or tv scale.

Choosing either of the 2 pc scale matrixes results in a more "gray" image with less contrast than if I use a tv-scale matrix. Shouldnt it be exactly the other way around, with the pc-scale matrixes offering more contrast?

[foxyshadis]

PC:
YUV 16-235 -> RGB 16-235
RGB 0-255 -> YUV 0-255 -> RGB 0-255
TV:
RGB 0-255 -> YUV 16-235 -> RGB 0-255
YUV 0-255 -> RGB ??? (blown extremes)

So no, the presets are correct.

[Mug Funky]

If you can generate your .BMP's very large, say 8 times big

sadly no... these are DVD subtitles, so 4 colour, 720*XXX size is how they come out. i could fudge an antialias by edi upsize, then downsize. it's not a big thing though - i can live without it.

Add a Feature Request on SourceForge so it won't get forgotten
done :)

[Wilbert]

@IanB,

In Color::YUV2RGB (used in ColorYUV):


void Color::YUV2RGB(int y, int u, int v, int *r, int *g, int *b, int matrix)
{
if (matrix==0) {
const int cy = int((255.0/219.0)*65536+0.5);
const int crv = int(1.596*65536+0.5);
const int cgv = int(0.813*65536+0.5);
const int cgu = int(0.391*65536+0.5);
const int cbu = int(2.018*65536+0.5);
int scaled_y = (y - 16) * cy;
*b = ((scaled_y + (u-128) * cbu) + 2^15) >> 16; // blue
*g = ((scaled_y - (u-128) * cgu - (v-128) * cgv) + 2^15) >> 16; // green
*r = ((scaled_y + (v-128) * crv) + 2^15) >> 16; // red
} else {
// ITU-R Recommendation BT.709
const int cy = 19077;
const int crv = 3960 * 2;
const int cgv = -4363 * 2;
const int cgu = -1744 * 2;
const int cbu = 17307 * 2;
const int shift = 14;
int scaled_y = (y - 16) * cy;
*b = ((scaled_y + (u-128) * cbu) + 2^13) >> 14; // blue
*g = ((scaled_y - (u-128) * cgu - (v-128) * cgv) + 2^13) >> 14; // green
*r = ((scaled_y + (v-128) * crv) + 2^13) >> 14; // red
}
}

should be

void Color::YUV2RGB(int y, int u, int v, int *r, int *g, int *b, int matrix)
{
if (matrix==0) {
const int cy = int((255.0/219.0)*65536+0.5);
const int crv = int(1.596*65536+0.5);
const int cgv = int(0.813*65536+0.5);
const int cgu = int(0.391*65536+0.5);
const int cbu = int(2.018*65536+0.5);
int scaled_y = (y - 16) * cy;
*b = ((scaled_y + (u-128) * cbu) + (1<<15)) >> 16; // blue
*g = ((scaled_y - (u-128) * cgu - (v-128) * cgv) + (1<<15)) >> 16; // green
*r = ((scaled_y + (v-128) * crv) + (1<<15)) >> 16; // red
} else {
// ITU-R Recommendation BT.709
const int cy = 19077;
const int crv = 3960 * 2;
const int cgv = -4363 * 2;
const int cgu = -1744 * 2;
const int cbu = 17307 * 2;
const int shift = 14;
int scaled_y = (y - 16) * cy;
*b = ((scaled_y + (u-128) * cbu) + (1<<13)) >> 14; // blue
*g = ((scaled_y - (u-128) * cgu - (v-128) * cgv) + (1<<13)) >> 14; // green
*r = ((scaled_y + (v-128) * crv) + (1<<13)) >> 14; // red
}
}

right?

In some places in the code it uses "shift / 2" which can be replaced by "shift>>1".

[IanB]

@Wilbert,

Technically maybe, but the code is only used for debug and 2^15 is just as much a constant to the compiler as 1<<15 so the change would make no difference.

[kypec]

@IanB

maybe I'm completely wrong but I think that in C language the ^ operator's effect is bitwise exclusive or therefore the constant expressed as 2^15 would equal 13=0x0D instead of 32768=0x8000 as expected.

[IanB]

@kypec,

ahem.... Well yes... thats probably a reason to fix it. Leaving bad debug code lying around only encourages bugs to breed. :o

[Fizick]

may be it is a time to release v2.5.7 alpha4 or beta1 or even RC1 ?