AviSynth 2.6.0 Alpha3 [May 25th, 2011]

[Forteen88]

Why is AviSynth_090820.exe so small in size (1.06 MB) compared to Avisynth_258.exe (3.98 MB)? Better compression?
Thanks for AviSynth!

[IanB]

@Forteen88,

Originally Posted by IanB

Note this installer does not include any of the documentation. You should install 2.5.8 and then install this version over the top.

It also only includes 2.5.8.7 DSS and 1.0.0.6 TCPDeliver.


All,

Time is precious so I am skipping the frills for expedience sake. I am also restricting my participation in this forum, don't feel offended if I appear to be ignoring you, I am applying self discipline and not responding to anybody ( I am skimming the posts every few days for any active items). This way I actually have time to work on the code.

As I said

Originally Posted by IanB

The main pupose of this release is to confirm compatibility with version 2.5.8. For scripts using only 2.5.8 features the results should be identical.

And I guess the caveat is for scripts using 2.6 features what sort of collateral are we looking at.

[Wilbert]

Maybe I read the wiki documentation wrong, but are lots of filters out of traditional/compatibility reasons going to return YV12 instead of Y8? It seems a bit odd to me but maybe that part just hasn't been updated.

Which filters are you referring too (except greyscale for example)?

I know you want to keep as much compatibility as possible with all old scripts, but did you consider moving arcane pieces of code such as http://avisynth.org/mediawiki/FixLuminance and several others you can dig up to something like a separate 2.5 compatibility plugin? I don't see why you should keep the most obscure ones around.

That sounds like a good idea to me. Other ancient filters which nobody uses: FixBrokenChromaUpsampling, PeculiarBlend, Pulldown (?). Did i forget any?

[thewebchat]

While we're at it, why don't we unify AVISource, OpenDMLSource, and AVIFileSource into one source filter?

[Fizick]

There is an opinion to move all filters from core to separate plugin(s).

[morsa]

Yes please, that would make keeping the project up to date much easier.
I Guess that moving internal( now basic set of) filters to external plug-ins would help if we at last move to higher quality/precision color depth.

[mikeytown2]

morsa has a great point. This means that avisynth would no longer be able to say "batteries included", but with the big changes with color depth, ect... it might be the smart thing to do. Either way moving the never used functions to various plugins is 100% smart IMHO.

[Sagekilla]

I agree. It seems like the core could be simplified quite a bit if you just create a "legacy" plugin of sorts that contains older, underused filters, along with additional plugins that contain the more frequently used functions.

[10L23r]

Why doesn't sincresize work??

[kemuri-_9]

Hmmm there were originally a large portion of
function definitions that are useful for plugin writers were defined in avisynth.h

however with the latest 2.6 merge, avisynth.h has turned into purely prototype-based code
and the definitions wandered into interface.cpp

(For those nonprogrammers that don't completely understand what I'm saying,
basically means that avisynth.h was an all-in-one-package and is no longer so)

so are you changing it to that we should now have interface.cpp in the plugin code to be able to successfully write plugins with the new system?

[Wilbert]

Why doesn't sincresize work??

It's not in this alpha version.

Hmmm there were originally a large portion of
function definitions that are useful for plugin writers were defined in avisynth.h

however with the latest 2.6 merge, avisynth.h has turned into purely prototype-based code
and the definitions wandered into interface.cpp

(For those nonprogrammers that don't completely understand what I'm saying,
basically means that avisynth.h was an all-in-one-package and is no longer so)

so are you changing it to that we should now have interface.cpp in the plugin code to be able to successfully write plugins with the new system?

No. As I understand it, all that code in the old avisynth.h was baked into every plugin. So it can't be changed without recompiling the plugin. Now you need to link your plugin to avisynth.lib and the code will be called from avisynth.dll (or something else which is able to load AviSynth plugins).

I'm sure i will be corrected if i got it wrong.

[MfA]

I don't think it's ready yet (still hard coded, no function pointers) but yes, in the future you are meant to add an extra source file to your plugin projects (or link a LIB, but really just adding the file is easier and less prone to getting out of date ... a LIB would just be an useless extra build step). I told them they could just make it an .ICBIAH (I can't believe it's a header) file and #include it in avisynth.h ... but they didn't agree with me

The intention is to have the stubs in interface.cpp use function pointers passed from avisynth proper (the DLL, so the functions can be changed in future versions and have the plugins use them).

[IanB]

As Wilbert said, except linking to avisynth.lib is not a serious contender. The 2 leading contenders for plugin linkage are funktors or stub routines, with a struct of function pointers, either packaged as macros in avisynth.h or a new module for plugins to include. I have an awk script to generate the initial text but I have another dose of additions/changes to apply to avisynth.h before I commit the function linkage, so it will be a few weeks before this last part gets some CVS cycles.

Refer to the "Baked Code" thread in the "Avisynth Development" forum for previously discussed details

Oh! Snap MfA

[SEt]

I think there should be no imports in plugins from avisynth core. More importantly i think that plugin source recompilation from 2.5 to 2.6 must not be trivial as there should be requirement for 2.6 filters to be thread safe and specify themselves correct MTMode, setting video cache hints also should be mandatory (but probably in different notation than now).

[juGGaKNot]

Just installed it

AVIsource("C:\theora\x.avi")
ConvertToYV24(matrix="PC.601")
LoadPlugin("C:\x264\bin\autocrop.dll")
AutoCrop(0, 16, 16, threshold=0)

Would this + avs2yuv.exe x.avs -o x.y4m make sure that i get a 4:4:4 0-255 yuv ?

[Wilbert]

Would this + avs2yuv.exe x.avs -o x.y4m make sure that i get a 4:4:4 0-255 yuv ?

Nope. It's not supported in avs2yuv. avs2yuv converts everything to YV12.

Perhaps i will add this in Immaavs or Imagewriter.

[juGGaKNot]

Originally Posted by Wilbert

Perhaps i will add this in Immaavs or Imagewriter.

Would be nice, theora only takes yuv

tried rgb2yuv but it does not work.

[IanB]

Okay, the Alpha 2 release. See post 1 above for full details.

Highlights
* New Softwire.
* Massive speed up in Vertical resizer on all platforms.
* ConditionalReader/WriteFile full refactor.
* Nearly all experimental branch code reviewed and imported. (One more push should do it)

Get AviSynth_090927.exe (1.1MiB) from SourceForge.
------------

Originally Posted by 7ekno

Nice work, does this include SEt's MT and memory leak fixes?!?

There is no MT in either the Alpha 1 or 2 releases. I have noted SEt's changes for a subsequent release. I will very probably not be doing threading the messy SetMTmode() way. If people have ideas crack open a thread and discuss them. Now is the right time.
------------

Originally Posted by tin3tin

I hope that this writefile issue could be adressed in the next alpha:

Originally Posted by IanB

...Optimizations
* WriteFile() now supports 32 unlimited strings. (was 16 by 254 byte strings).

------------

Originally Posted by Fizick

1. I see you merged 2.6 branch to main at CVS.
So, today (or 20 august?) source code at CVS main is correspondent to released alpha?

Yes, the CVS MAIN branch (20th August and 27th September) contains the code corresponding to the released versions.

2.

SoftWire ?

Oops, yes Softwire! FastWire is an internal product where I work

3. And yes, if will will be nice if you trim (or crop ) the changelog posted by Wilbert to the correspondent state of released alpha.

Originally Posted by tin3tin

Very nice. Is there a changelog somewhere?

It takes a surprising amount of time to maintain the changelog. But this time there is one and it should be pretty close to correct.

[kemuri-_9]

i noticed the update last night when i did a CVS pull, some minor compilation-based issues that should be fixed with the next push are:

convert_planar.cpp:
PVideoFrame __stdcall ConvertToY8::GetFrame() {
...
const srcMod = srcPitch + (vi.width * pixel_step);

should instead be

const int srcMod = srcPitch + (vi.width * pixel_step);


conditional_reader.h:
class ConditionalReader : public GenericVideoFilter {
...
CleanUp(void);

should instead be

void CleanUp(void);


conditional_reader.cpp:
ConditionalReader::CleanUp(void)

should be

void ConditionalReader::CleanUp(void)

[Wilbert]

* Bugfix SelectRangeEvery audio snafu (Gavino)

Hopefully i've some time to document some new stuff this week ...