AviSynth 2.6.0 Alpha3 [May 25th]

[IanB]

An interim patch release. I'll do a proper update of this first post when I get some more spare time.

Get AviSynth_110525.exe (4.9MiB) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/AviSynth_110525.exe/download) from SourceForge.

========================

Here is the 2nd official release of Avisynth 2.6. Again a purpose 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.

This version now contain most of the features in the experimental 2_6 CVS tree. It supports Y8, YV24, YV16 and YV411 colour spaces in most existing filters.

It contain Sh0dans latest SoftWire updates and his SSSE3 code enhancements. In addition to his SSSE3 version, I have rewritten the MMX code for the vertical resizer which now does 8 pixels per cycle and also written an SSE2 version which does 16 pixels per cycle. And for the vertical PointResizer there is an ultra fast code path which does 64 bytes per cycle.

Due to limits in my available programming cycles, not all the new code has had my normal fastidious testing, so I am trying something new. I am putting up this version for you to use while I continue the testing and development. Next release will have the bug fixes for whatever I find and you report. Be aware!

Note this installer also does not include any of the documentation. You should install 2.5.8 and then install this version over the top. The next release should have at least the English 2.6 doco.

Get AviSynth_090927.exe (1.1MiB) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%202%20%5B090927%5D/AviSynth_090927.exe/download) from SourceForge.

========================
Changelist

Additions
* Added support for argument passing and EAX return value to SoftwireHelper.
* Added "Global OPT_VDubPlanarHack=True" to flip YV24 and YV16 chroma planes for old VDub's.
* Added ContinuedDenominator/ContinuedNumerator(f[]i[limit]i) script functions. [undocumented]
* Tweak: fix MaskPointResizing + put back Dividee ISSE code (use sse=true, can't use all settings in that case). [undocumented]
* Added ChromaPlacement and ChromaResample options to planar colour conversions.
* Added MaskHS.
* Minor tweaks to get ready for VC8.
* Add Y8 for DevIL, planarize EBMP.
* Planar support for many filters.
* Added Info() time indicator on audio length and video (current frame & total). (2.5.8)
* Added UtoY8 and VtoY8.
* Added more info to Info(). (2.5.8)
* ColorYUV: Added all adjustment parameters as conditional variables "coloryuv_SETTING". Enable by setting conditional=true. [undocumented]
* ConditionalReader: Added support for type String. [undocumented]
* ConditionalReader: Added offset keyword to offset all frame numbers after the keyword. [undocumented]
* Added SincResize() with optional taps parameter (default is 4).
* Added Custom band setting to SuperEQ to allow all 16 bands to be set from script. Usage: SuperEQ(clip,band1, band2, band3....) values are dB in float.
* Added fast 0-1-0 kernel for YV24 to ConvertBacktoYUY2().
* Added formats: YV24, YV16, Y8, YV411.

Bugfixes
* Fixed MonoToStereo with stereo sources.
* Fixed MergeChannels with only 1 input clip.
* Fixed support for negative height DIB format AVI's. (Oops still not quite right yet)
* Fixed Audio cache crashes.
* Fixed resize with YV411 missing code.
* Fixed ConditionalReader rounding with integer Interpolation.
* Fixed Softwire SSE2 bugs.
* Fixed SSSE3 CPU detection.
* Fixed SSSE3, SSE4.1 & SSE4.2 detection.
* Fixed Fastwire encoding of instructions that are >2 opcodes (SSSE3+4).
* Fixed _RPT5() macro for debug builds

Optimizations
* WriteFile() now supports 32 unlimited strings. (was 16 by 254 byte strings).
* SuperEQ: Improve channel unpacking/packing code.
* H-Resize: Use SSE4.1 (movntdqa) loads for use once memory access.
* H-Resize: Added SSE2 horizontal unpacker.
* Resize: Use SSE3 (lddqu) loads for unaligned memory access.
* Added ultra fast vertical PointResizer (64 pixel/cycle).
* Added dynamic SSSE3 vertical resizer (16 pixel/cycle) ~ twice as fast as old MMX.
* Added dynamic SSE2 vertical resizer (16 pixel/cycle).
* Added dynamic MMX vertical resizer (8 pixel/cycle).
* Added SSSE3 version for RGB<->YV24 conversions.
* Added dynamic compiled MMX/iSSE for RGB<->YV24 conversions. Speed is approx 200% of C-code.

Changes
* ConditionalReader/WriteFile: Full refactor.
* SoftwireHelper: explicit hardware exception handling.
* Resize: Moved GetResampleFunction into Resamplefuntion, to allow overrides.
* Resampler: Removed dead stlf code.
* Updated Soundtouch to 1.31 (2.5.8)
* Put dynamic matrix conversion into separate file.
* Moved chroma subsampling to image_type section.
* Added specific error reporting when requesting chromasubsampling with Y8.
* Split up merge and plane Swappers.
* Split up Plane transfers into separate classes.
* Added automatic destination colorspace detection on planar YtoUV.
* Took out greyscale and RGB32<->RGB24 from convert.cpp and placed them in separate files.
* All code assuming UVwidth = Ywidth/2 and similar should be gone.

Documentation can be found online (and in the 2.6 cvs tree).

[sneaker_ger]

VirtualDub 1.9.5 is already out: (http://www.virtualdub.org/blog/pivot/entry.php?id=268)
Reversed order of UV planes for YV16 and YV24 formats to match YV12. (Note: This does not affect filters.)

[scharfis_brain]

The next release will have an option to enable this hack on demand.

Without testing the new AVS 2.6...
SwapUV() should do the trick, shouldn't it?

[lych_necross]

Woo-hoo!! I can't wait to test it later this week when I have time. :D

[7ekno]

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

His build is running fine for me at the moment, just trying to anticipate whether this one is a forward or backward step !!

7ek

[Revgen]

^TSP submitted his MT code for avisynth 2.6 a couple years ago. Official MT support is supposed to happen once it's released.

[tin3tin]

Very nice. Is there a changelog somewhere? :)

[SEt]

Can we have clear trunk/stable svn repositories for Avisynth 2.6? I want to see major MT/cache changes you have in mind submitted asap as i have several thoughts myself but would rather modify new version.

PS: And why on Earth it's compiled with VS 6? I again suggest dropping this deprecated many years ago compiler with poor standards support and many code generation bugs.

[Wilbert]

Nice job! I will move the docs to the main tree.

The changelist (note this is with respect to the cvs tree, and i'm not sure which ones are included in the alpha build). It might also be that some of the fixes are already in 2.58.

Additions
* Tweak: v2.58 catchup + fix MaskPointResizing + put back Dividee ISSE code (use sse=true, can't use all settings in that case). [undocumented]
* Added chromaplacement and chromaresample options to color conversions.
* Added MaskHS.
* Made VC8 project files.
* Minor tweaks for VC8 compile. All changes should be compatible with VC6 - there are two Soundtouch libraries for the same reason.
* Made VC8 projects for DirectshowSource and TCPDeliver.
* Add Y8 for DevIL, planarize EBMP.
* Planar support for many filters.
* Added time indicator on audio length and video (current frame & total).
* Added specific error reporting when requesting subsampling on Y8.
* Added MultiThreading support, including ScriptEnvironment::SetMTMode and ScriptEnvironment::GetMTMode.
* Added UtoY8 and VtoY8.
* Added more info to Info().
* ColorYUV: Added all adjustment parameters as conditional variables "coloryuv_SETTING". Enable by setting conditional=true. [undocumented]
* ConditionalReader: Added offset keyword to offset all frame numbers after the keyword. [undocumented]
* Added SincResize(). Optional taps parameter (default is 4).
* Added Custom band setting to SuperEQ to allow all 16 bands to be set from script. Usage: SuperEQ(clip,band1, band2, band3....) values are dB in float.
* Work in progress, Add fast 0-1-0 kernel YV24 back to YUY2. (status ?)
* Added formats: YV24, YV16, Y8, YV411.
* Added SoundOut plugin. It is a GUI driven sound output module for AviSynth (it exports audio to several compressors).

Bugfixes
* MT related fixes by SEt
* ColorYUV: Removed (unused) debug information code.
Resize: Use SSE3 (SSSE3 ??) loads for unaligned memory access.
* Resize: Free aligned horizontal resizers.
* Resize: Moved GetResampleFunction into Resamplefuntion, to allow overrides.
* TCPClient: Fixed uncompressed client not passing correctly through.
* TCPServer: GetFrame is now ensured to only be called by a single thread, if client should request frames.
* Fixed Softwire SSE2 bugs.
* Removed dead code from horizontal resizer
* Commented dynamic vertical resizer better.
* TCPDeliver: Fixed VC8 compilation on latest SDK.
* TCPDeliver: Image decompression is now done in client fetch thread to enable better multithreading
* TCPServer: Removed Secure printf's for VC6
* TCPDeliver: Using TCP_NODELAY, this will kill latency on client request packets, and server replies.
* Increment sequencecount in MakeWritable to avoid crash when calling GetFrame between MakeWritable() and GetWritePtr().

Optimizations
* Resize: Added SSSE3 horizontal unpacker.
* Added dynamic horizontal MMX resizer.
* Added dynamic SSSE3 horizontal resizer ~ twice as fast as MMX.
* Optimized horizontal SSSE3 resizer; approx 2.5 x speedup (38.1fps vs 14.2fps on test)
* Added dynamic compiled MMX/iSSE for RGB<->YV24 conversions. Speed is approx 200% of C-code.

Changes
* Fixed SSSE3, SSE4.1 & SSE4.2 detection.Softwire: Fixed encoding of instructions that are >2 opcodes (SSSE3+4).
* Fixed SSSE3 CPU detection.
* Resampler: Removed dead stlf code.
* Threading in TCPDeliver does not use AFX anymore.*
* Updated Soundtouch to 1.31
* Put dynamic matrix conversion into separate file.
* Moved chroma subsampling to image_type section.
* Added a synchronization class IClipLocalStorage and smartpointer PClipLocalStorage to handle synchronisation between class instances when using MTMode 2 and 4.
* Split up merge and plane Swappers.
* Split up Plane transfers into separate classes.
* Added automatic destination colorspace detection on planar YtoUV.
* Took out greyscale and RGB32<->RGB24 from convert.cpp and placed them in separate files.
* All code assuming UVwidth = Ywidth/2 and similar should be gone.

Documentation can be found online (and in the 2.6 cvs tree).

[Fizick]

IanB, thanks for release!
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?
2. The next release will contain Sh0dans latest FastWire updates...
SoftWire ?
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.

[tin3tin]

I hope that this writefile issue could be adressed in the next alpha: http://forum.doom9.org/showthread.php?t=147536

:)

[hanfrunz]

maybe a little bit OT, but are there any plans to move the avs-repo to a "modern" versioning system like git or mercurial?

hanfrunz

[a451guy451]

Awesome stuff. Any chance we'll see a release with setmtmode anytime soon?
Thanks for the great work guys.

[Alex-Kid]

These are great news, as long time has passed since last version and many new features were expected.

The main pupose of this release is to confirm compatibility with version 2.5.8.
Must be assumed that multithreading is not implemented yet and we'll have to wait until its final release? Just to know if I install it or not.

Everyday I like Avisynth more and more. Nice job guys, I salute you! ;)

Saludos

By ALEX-KID

[BigDid]

Awesome stuff. Any chance we'll see a release with setmtmode anytime soon?
Hi,

I have not tested the 2.6 rev but unless I am mistaken it is already integrated see:
...
The changelist (note this is with respect to the cvs tree, and i'm not sure which ones are included in the alpha build). It might also be that some of the fixes are already in 2.58.
Additions
...
* Added MultiThreading support, including ScriptEnvironment::SetMTMode and ScriptEnvironment::GetMTMode.
...
Bugfixes
* MT related fixes by SEt
...

See also this post:http://forum.doom9.org/showthread.php?p=1319282#post1319282
The test I made (with MT 2.58) show that using setmtmode() or not changes very little -speedwise- when your avisynth.dll (not the MT.dll that goes in the plugin directory) is multithreaded, which should be the case with this new 2.6 rev.

Also, until a specific MT.dll is dedicated for 2.6 (or a new way to MT), the 2.58 MT.dll should/could be used with the 2.6...

Please test and confirm or infim :D

Did

[a451guy451]

Well, I'd been previously running and older pre-alpha of avisynth 2.6 (Avisynth_120806.exe) on a dual core machine for quite some time, and setmtmode almost doubled the speed of alot of my scripts (especially some really rigorous mvtools framerate conversion stuff). It never really gave me any problems whatsoever.

But, I recently upgraded to a quad core processor and that build of 2.6 did not like it at all (when using setmtmode that is, even if I limited it to two threads). It would run for a while on all 4 cores, but then would seem to crash (where upon I'd see all the core activity go from evenly distributed to to maxing out a single core without really continuing to render out the file). I repeated this on an 8 core machine a friend of mine has with the same result (I saw a slightly diminished return speed wise as compared to the quad core, but it was still significantly faster before it would crash).

So, I was hoping that this new release build would solve that issue, but it doesn't seem to have setmtmode as an active function (I just tried it out again to make sure). As I understand, that change list posted by Wilbert is from the CVS tree and he said he didn't know which features were actually included in this build. It makes sense that it's not there, cuz the point of this one is to test compatability with 2.5.8, which thus far seems to be perfect for me in all my tests.

It's not a big deal, I was just all excited about my quad core cpu and a little bummed I couldn't use this one yet (and now I'm just on the edge of my seat for the final release build;]). Before the scripts crashed though, I was definitely getting a really significant speed increase from 3 to 11fps with 4 threads on my mvtools script as compared to using one thread. I really haven't tried the mt.dll for a long time, as the setmtmode has been working well for me and I like that it processes frames as wholes, as opposed to split into 4 pieces.

[BigDid]

Hi,

You are right, it is not (yet) included; my bad.
In the meanwhile I will test SET 2.6 build ( 08/08/2009) which seems functional and multithreaded (setMT and MT with the 2.58 MT.dll); at least for my 2 cores.

Did

[hoboX10]

I can't even begin to imagine how you begin to code such a thing like AviSynth... Amazing.

[aegisofrime]

I don't think the alpha has multithread enabled, SetMTMode returns an unknown function error.

It does work with Jeremy Duncan's 2.58 MT.dll though.

[Myrsloik]

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.

In the same spirit of making the core smaller (and more manageable in general), you should really separate out the imagereader/writer/source to reduce the compilation dependencies.

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.

[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,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 saidThe 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 :search:

Oh! Snap MfA :D

[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]

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) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%202%20%5B090927%5D/AviSynth_090927.exe/download) from SourceForge.
------------
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.
------------
I hope that this writefile issue could be adressed in the next alpha:...Optimizations
* WriteFile() now supports 32 unlimited strings. (was 16 by 254 byte strings).
------------
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.The next release will contain Sh0dans latest FastWire updates...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.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 ...

[Gavino]

* ConditionalReader/WriteFile: Full refactor.
By some wierd trans-oceanic telepathy, I was looking at this just yesterday thinking it could do with a tidy-up, with code in the header file and other oddities.
* WriteFile() now supports 16 unlimited strings. (was 8 by 254 byte strings).
Actually, it was 16 and it's now 32.
But why limit it to 32 when it's very little extra work to make the array dynamic?
struct exp_res {
const char* expression;
const char* string;
};
exp_res* arglist;
...
arglist = new exp_res[args.ArraySize()]
Or, if retaining the limit, at least throw an error if too many args are supplied, rather than silently ignoring them.

Other minor coding points in Write:
- DoEval and FileOut could be private rather than public;
- 'mode' is unnecessary (and confusing), since file opening can just use APlusT outside the constructor, which is where the file is truncated if necessary.

[IanB]

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:
Ta! :cool:
_________* Bugfix SelectRangeEvery audio snafu (Gavino) :)
* Bugfix SelectRangeEvery(..., audio=false) audio has start missing. (Gavino)
_________Actually, it was 16 and it's now 32.Oops! :o
But why limit it to 32 when it's very little extra work to make the array dynamic?
Didn't see the wood for the trees :p Done!
Other minor coding points in Write:
- DoEval and FileOut could be private rather than public;
Yep! :sly:
- 'mode' is unnecessary (and confusing), since file opening can just use APlusT outside the constructor, which is where the file is truncated if necessary.
There is a subtle effect with WriteFileEnd() where the file will get truncated in the constructor and retruncated at the actual end of the script time in the destructor. But yes carrying mode around is crappy.:cool: Gone!

[Gavino]

There is a subtle effect with WriteFileEnd() where the file will get truncated in the constructor and retruncated at the actual end of the script time in the destructor.
My thinking was that the second truncation was unnecessary - or is it still intended to be done? That seems inconsistent with WriteFile where append=false means truncate at time of evaluation (not at time of writing).

BTW Why do WriteFileStart/End set current_frame (to -1 and -2)?
This seems pointless and interferes with the error check on using run-time functions outside the run-time environment.

[IanB]

My thinking was that the second truncation was unnecessary - or is it still intended to be done? That seems inconsistent with WriteFile where append=false means truncate at time of evaluation (not at time of writing).
I would agree, but in reality the 2 events could happen hours apart in a long running script. I am not sure if anybody makes use of this quirk, but I am not in the habit of changing boundary behaviour without a really good reason.

I guess it would also be nice if WriteFileEnd() could run DoEval() in the Destructor, but having the world collapsing at the time makes this a tad impractical.


BTW Why do WriteFileStart/End set current_frame (to -1 and -2)?
This seems pointless and interferes with the error check on using run-time functions outside the run-time environment.
I don't know it's just the way it works. Sh0dan added this in 2004 and I think it was originally written or at least proposed by Ernst Peché aka Warpenterprises. Maybe someone with a long memory can unwrap the original thought process.

What value would you suggest current_frame be given here? I guess to maintain backwards compatibility it could be overridden as an optional argument on the WriteFileStart/End() commands for those who have other needs.

[Gavino]

I guess it would also be nice if WriteFileEnd() could run DoEval() in the Destructor, but having the world collapsing at the time makes this a tad impractical.
Yes - a pity, as it would give a way of getting some final values out of a run-time script, although this can be done with the trick of ScriptClip("WriteFile(..., append=false)").
What value would you suggest current_frame be given here? I guess to maintain backwards compatibility it could be overridden as an optional argument on the WriteFileStart/End() commands for those who have other needs.
Perhaps we're stuck with it for backwards compatibility, but ideally I think it should not be given any value at all, since current_frame should not be defined outside the run-time environment.
Does anyone rely on this? The only possible use could be to signal that you are in WriteFileStart or WriteFileEnd, but you already know that when writing the script. :confused:

I think WriteFileStart/End are badly specified anyway.
They should take raw values rather than expression strings, since they are evaluated immediately, a frequent source of confusion (even to you, as I recall ;)). Nor do they need to take a clip, which is not used correctly anyway:
WriteFileStart(c, ..., "Framecount()")
does not print the Framecount of 'c' (as it would with WriteFile), but the Framecount of 'last'. (intentional or an oversight?)

[juGGaKNot]

ffmpeg2theora.exe -o "Movie.ogv" --first-pass dummy -v 8 -V 5000 --optimize --framerate 30 --keyint 300 --no-oshash --title "asd" --contact "asd" --noaudio "Movie.avs"
[avs @ 0x3ec470]MAX_READ_SIZE:5000000 reached
Input #0, avs, from 'Movie.avs':
Duration: 00:00:16.66, start: 0.000000, bitrate: 0 kb/s
Stream #0.0: Video: YV24 / 0x34325659, 1184x666, 567751 kb/s, 30 tbr, 30 tbn
, 30 tbc
[audio disabled].
swScaler: Unknown format is not supported as input pixel format

No video or audio stream found.

Is this a ConvertToYV24() problem or theora ?

[Wilbert]

Is this a ConvertToYV24() problem or theora ?
It looks like ffmpeg2theora (or theora itself) doesn't accept YV24.

[juGGaKNot]

Yes, ffmpeg's swScaler does not do it

Clean theora does allow y4m 4:4:4, as you said "My plan is to add support for "y4m" so i guess avsutil x.avs play when it is done.

[foxyshadis]

I think WriteFileStart/End are badly specified anyway.
They should take raw values rather than expression strings, since they are evaluated immediately, a frequent source of confusion (even to you, as I recall ;)). Nor do they need to take a clip, which is not used correctly anyway:
WriteFileStart(c, ..., "Framecount()")
does not print the Framecount of 'c' (as it would with WriteFile), but the Framecount of 'last'. (intentional or an oversight?)

I'd rather deprecate WriteFileStart/End and specify new functions if you really want to clean up the syntax.

[turbojet]

Directshowsource changes fractional framerates (23.976, 29.97, 59.94, and even 18.34, 22.75, etc.), avisource and import does not have the problem. Can someone look at it?

[Gavino]

I'd rather deprecate WriteFileStart/End and specify new functions if you really want to clean up the syntax.
Yes, I agree. That would be necessary for backwards compatibility.

[tin3tin]

A thing I noticed about writefile is that if a script with writefile is interupted and the file operation isn't finished(closed) and then the script is run again it sometimes fails at doing the writefile thing. So maybe if it fails, if could try to "close" writing to the file before opening it again for the writefile operation?

Thank you checking up on the writefile function(and string length).

[Keiyakusha]

Directshowsource changes fractional framerates (23.976, 29.97, 59.94, and even 18.34, 22.75, etc.), avisource and import does not have the problem. Can someone look at it?
I saw this in previous versions of avisynth too so I'm using AssumeFPS() almost always just to be safe. But problem can be not in directshowsource but in some DSfilters. Maybe even Haali splitter...

[IanB]

DirectShow works in time units of 100 nanoseconds.

Many stream formats only work in millisecond time units i.e. ASF/WMV.

In DirectShowSource() the FPS is calculated by setting the denominator to the value in VIDEOINFOHEADER.AvgTimePerFrame or VIDEOINFOHEADER2.AvgTimePerFrame, and setting the numerator to 100000000. The rational fraction is then normalised.

This of course leads to rounding errors.

E.g. True FPS = 30000/1001
. --> DS AvgTimePerFrame = Round(100000000*1001/30000) = Round(3336666.66.) = 3336667
. --> DSS FPS = 100000000/3336667 = 29.9700269760

[turbojet]

Is there any way to correct that by for example using avisource's framerate calculation?

[EuropeanMan]

Ever since I downloaded & installed the latest build...27th Sep...I've had problems with MeGUI - it crashes xvid_encraw and x264.exe. Therefore, I cannot encode via either codec in MeGUI, nor VirtualDub. I uninstalled everything, went back to 2.5.8...and still those same errors came - crashing. I can't encode anymore.

So WHAT EXACTLY DID 2.6 DO TO MY SYSTEM where I can't encode anymore and what do I do to fix this short of formatting my hard-drive and going back to square one? Thanks.

Refer: http://forum.doom9.org/showthread.php?t=149979

[levi]

Just check your system32 / syswow64 for avisynth.dll & delete it. Then reinstall the older version.

[EuropeanMan]

That didn't do the trick either. Still encoding crashes.

[canuckerfan]

you tried encoding without avisynth? just to see if avisynth is the culprit...

[IanB]

Clear (rename) your plugin directory.

Roll your whole windows back to before you did all your current batch of fiddling. (i.e. System Restore point)

[dansrfe]

At this point AviSynth 2.6 may mess up some stuff still unknown to developers. That is why this is called an alpha and not a final. Reinstalling previous versions still might let you encode but random crashes or failure to even start encoding can occur. You will probably have to do a system restore.

[IanB]

The Avisynth installer for 2.6 does exactly the same as the installer for the previous versions of Avisynth. It has not changed!

It installs avisynth.dll, devil.dll and if you do not already have one, msvcp60.dll, into the Windows 32bit system directory. It write the exact same set of registry keys that all versions of Avisynth have always used. It then puts all the support and documentation files into the chosen Installation directory (default C:\Program Files\AviSynth 2.5). That's it!

If you have a problem with 2.6, installing an earlier version of Avisynth over the top will correctly revert to that version, as long as that install completes normally. If the problem remains then you have a problem with something other than Avisynth.

And if you are having problems with the 2.6 alpha releases you should be accurately reporting the problem with adequate information to allow the problem to be reproduced and fixed. I do not want to see lame "my system just crashes" reports without all the relevant details ever in this thread.

[dansrfe]

The Avisynth installer for 2.6 does exactly the same as the installer for the previous versions of Avisynth. It has not changed!

It installs avisynth.dll, devil.dll and if you do not already have one, msvcp60.dll, into the Windows 32bit system directory. It write the exact same set of registry keys that all versions of Avisynth have always used. It then puts all the support and documentation files into the chosen Installation directory (default C:\Program Files\AviSynth 2.5). That's it!

If you have a problem with 2.6, installing an earlier version of Avisynth over the top will correctly revert to that version, as long as that install completes normally. If the problem remains then you have a problem with something other than Avisynth.

And if you are having problems with the 2.6 alpha releases you should be accurately reporting the problem with adequate information to allow the problem to be reproduced and fixed. I do not want to see lame "my system just crashes" reports without all the relevant details ever in this thread.

true :o

[Monamona]

As below, some chroma decording error of 720x480 MPEG2-TS
by MPEG2Source(DGIndex) with 'cpu=1' option.

http://upload.jpn.ph/upload/img/u51143.png

Please see attached MPEG-TS and d2v files for the detail.

http://rapidshare.com/files/297252118/Sample.zip.html

The bug could be caused by MPEG2Source(DGIndex),
but no problem with Avisynth 2.5.8.

BTW, this does not happen with other 1440x1080 MPEG2-TS sources.

[GrofLuigi]

As below, some chroma decording error of 720x480 MPEG2-TS
by MPEG2Source(DGIndex) with 'cpu=1' option.


I've noticed the same error too on some DVDs (full PAL, 720x576). The script is only MPEG2Source ("filename.d2v", cpu=N). It looks to me it's some kind of alignment issue.

My observations:

- 'cpu2' parameter is also affected - if there is only one 'x' among all 'o'-s, the bug appears.

- It cannot be reproduced on half-res DVDs (recorded on a standalone) 352x576, no matter what 'cpu' parameters.

- I haven't reverted Avisynth version yet from Alpha2, and dgmpgdec is 155, maybe the bug is there, but I doubt it...

GL

[IanB]

MPEG2Source("Sample.d2v", cpu=1)

SetPlanarLegacyAlignment(True)Does not have the problem, there is obviously still some recalcitrant code that assumes UVpitch = YPitch/2; and/or YPitch = (Rowsize+15)/16*16;

In 2.6 all planes have SSE2+ friendly mod 16 alignment.

For all code :-
. UVPitch=PVideoFrame->GetPitch(Planar_U);
. YPitch=PVideoFrame->GetPitch(Planar_Y);

You may not assume any relationship between vi.width and pitch or between the pitch of the various planes.

:Edit: PostProcess.cpp...
128 : // adjust for chroma
129 : if (!is422) vertical_size >>= 1;
130 : horizontal_size >>= 1;
131 : src_stride >>= 1;
132 : dst_stride >>= 1;

[Keiyakusha]

Just noticed that SoundTouch 1.4.0 is out. Will it be updated? Did not found the changelog, but current version released something like 4 years ago...

[Leak]

Just noticed that SoundTouch 1.4.0 is out. Will it be updated? Did not found the changelog[...]
http://www.surina.net/soundtouch/README.html:
5.1. SoundTouch library Change History

1.4.0:

* Improved sound quality by automatic calculation of time stretch algorithm processing parameters according to tempo setting
* Moved BPM detection routines from SoundStretch application into SoundTouch library
* Bugfixes: Usage of uninitialied variables, GNU build scripts, compiler errors due to 'const' keyword mismatch.
* Source code cleanup

[IanB]

Not a lot for us here (library wise), awful lot of white changes and compiler pacification, the auto calcs in TDStretch.cpp may help the novice, but is still no substitute for hand crafting the best values for your individual material, the uninitialized vars stuff doesn't effect us, but the fix is the right thing to do.

Keep an eye on their SVN repository for anything revolutionary or critical.

[Wilbert]

I'm trying to document the new feature:

ColorYUV: Added all adjustment parameters as conditional variables "coloryuv_SETTING". Enable by setting conditional=true. [undocumented]

As i understand it, it works as follows. The settings from ColorYUV (cont, gain, gamma and off) can be used inside conditional invironment (so they can be set framewise in FrameEvaluate, ConditionalReader, etc... and used in ColorYUV when conditional=true). For example:

coloryuvoffset.txt:

Type float
Default 0.0

I 25 50 0.0 255.0
R 75 225 128.0
I 250 275 255.0 0.0


the script:

colorbars(512,256).ConvertToYV12.Trim(0,20)
#colorbars(512,256).ConvertToYV12.Trim(0,299)
ColorYUV(cont_y=10, conditional=true)
ConditionalReader("coloryuvoffset.txt", "coloryuv_gain_y", false)
ShowFrameNumber()


So up to frame 25 gain_y is equal to the default (which is 0.0), for frame 25 up to 50 the gain_y is increased from 0.0 to 255.0, etc ... Correct me if i'm wrong!

However when trimming as Trim(0,20), it seems that a gain_y of 255 is applied to the final frame, while it should be the same as the previous frames. Any idea what the cause of this?

[Gavino]

However when trimming as Trim(0,20), it seems that a gain_y of 255 is applied to the final frame, while it should be the same as the previous frames. Any idea what the cause of this?
I'm not at my usual computer, so can't check the source code, but I suspect it's because ConditionalReader clamps all frame numbers to the range [0, framecount-1]. In your case, all framenumber entries will be taken as 19, and the last one will take precedence, giving a value of 255.

[IanB]

Yes the "Range" mode clamps the start and stop frame numbers, so it can effect the setting for the first/last frame. It probably should not do this, the other modes ignore out of range frame numbers.
void ConditionalReader::SetRange(int start_frame, int stop_frame, AVSValue v) {
int i;
start_frame = max(min(start_frame+offset, vi.num_frames-1), 0);
stop_frame = max(min(stop_frame+offset, vi.num_frames-1), 0);
...
So in your example frame 20's value is 128.0, where it probably should be 0.0.

[Wilbert]

Yes the "Range" mode clamps the start and stop frame numbers, so it can effect the setting for the first/last frame. It probably should not do this, the other modes ignore out of range frame numbers.

Ok, thanks. I'm in favour of ignoring out of range frame numbers. It seems undesirable behaviour in this case. Could you remove those conditions?

[IanB]

Fixed!void ConditionalReader::SetRange(int start_frame, int stop_frame, AVSValue v) {
int i;
start_frame = max(start_frame+offset, 0);
stop_frame = min(stop_frame+offset, vi.num_frames-1);

[Wilbert]

Thanks!

[tin3tin]

Is there a full install of 'AviSynth 2.6.0 Alpha2' out yet?

[Wilbert]

Is there a full install of 'AviSynth 2.6.0 Alpha2' out yet?
It's the one in the first post. alpha3 is not out yet.

[tin3tin]

That's just an install-over-older-version and not a full install. If you know what I mean. :)

[kemuri-_9]

Just a thought, but it would probably be useful for debugging programs that use avisynth if all OutputDebugStrings were disabled in 'release' avisynth.

it's quite annoying to have to filter through potentially thousands of avisynth messages to find the desired output string in debugview or gdb

[XhmikosR]

I would like to see some cosmetics changes in the NSIS installer.

WriteRegStr HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\AviSynth" "DisplayName" "AviSynth ${VERSION}"
WriteRegStr HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\AviSynth" "UninstallString" '"$INSTDIR\Uninstall.exe"'
WriteRegStr HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\AviSynth" "Publisher" "The Public" (or whatever AviSynth devs find better)
WriteRegStr HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\AviSynth" "DisplayIcon" "$SYSDIR\AviSynth.dll,0"
WriteRegStr HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\AviSynth" "DisplayVersion" "${VERSION}.${ISSUE}"
WriteRegStr HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\AviSynth" "URLInfoAbout" "http://avisynth.org/"

Now, some issues I'm having compiling the latest AviSynth CVS with MSVC 2008 SP1. (the number of warnings is much bigger I removed some depreciated switches and added _CRT_SECURE_NO_WARNINGS and WINVER=0x0600 for TCPDeliver)

http://pastie.org/private/rrwwsfdfshrovhdzwurg


EDIT1:
After yesterday's changes, I get the following errors/warnings:

http://pastie.org/private/vnrmnjohugj0yqgy5l56fg


EDIT2: After yesterday's changes:

http://pastie.org/private/ffudnyx8j17uhqvqsvwa5g

Also how about updating UPX and devil lib and dlls?

[Wilbert]

I was looking at the color conversions (for the documentation), and my head is spinning a bit ;) Are the following statements correct:

* ChromaPlacement and ChromaResample options are only available for the 'planar conversion parts' of a conversion
** example1: YV16 -> RGB goes as follows: YV16->YV24 (options above are used); YV24->RGB
** example2: YV411 - > YV12
* YUV planar -> RGB via YV24
* YUV planar (except "YV12 and options disabled") -> YUY2 via YV16
* Both for C++ and the ASM code ConvertToRGB the missing chroma samples are interpolated (using a [1 1] kernel) [C++ sampling was different in previous versions]
* RGB -> YUV planar via YV24
* YUY2 -> YUV planar via YV16
* conversions to and from YUV9 are not implemented yet

[IanB]

@Wilbert,

Yes, what you have said looks right. Expressing it another way :-

There are the 2.5 core conversions, these are still in place when they are the most direct path.
* YV12 -> YUY2 (Interlaced option)
* YUY2 -> YV12 (Interlaced option)
* YUY2 -> RGB {0,1,0}/{1,0,1} Kernels (Matrix option)
* RGB -> YUY2 ConvertToYUY2 {0,1,1} Kernel (Matrix option)
* RGB -> YUY2 ConvertBackToYUY2 {0,1,0} Kernel (Matrix option)

For 2.6 there are new core conversions.
* YUY2 -> YV16 (lossless)
* YV16 -> YUY2 (lossless)
* Planar -> Planar (Uses resizer core on UV planes, ChromaPlacement, ChromaResample options, Interlaced option)
* YV24 -> RGB (Matrix option)
* RGB -> YV24 (Matrix option)

As for YUV9, YV411, etc I will probably bury these in a user generic planar umbrella where the user can specify the desired chroma subsampling.

So the explicit core formats will be Y8, YV12, YV16, YV24, YUY2, RGB24 and RGB32. Everything else will be User Generic YUV Planar with 1,2 or 4, H and V subsampling. Thorts?

[XhmikosR]

Has anyone compiled AviSynth 2.60 from CVS with Windows SDK v7.0? I found out that I get the errors posted in my previous post if I use the Windows 7 SDK. If I use SDK v6.0A which ships with MSVS 2008 then AviSynth 2.6 compiles fine. Here (http://pastie.org/private/yi8u1c569nagtnhkymf6dw) are the rest of the warnings I get with /W3 and _CRT_SECURE_NO_WARNINGS. And here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca5d770fd2dc6da976) is a fresh build of AviSynth 2.60 with a full installer for anyone interested.
BTW, I thought the MT was included in AviSynth 2.6, but apparently it's not.

[tin3tin]

And here is a fresh build of AviSynth 2.60 with a full installer for anyone interested.

Thanks :)

[BTW. it is still installing in a folder called '2.5' - but you properly already know this, for the purpose of overwriting the old version.]

[kemuri-_9]

BTW, I thought the MT was included in AviSynth 2.6, but apparently it's not.

iirc it's only in the avs 2.6 branch as of yet, from not yet having merged its way to the main/head branch

[XhmikosR]

Thanks :)

[BTW. it is still installing in a folder called '2.5' - but you properly already know this, for the purpose of overwriting the old version.]
Everything is as it is in the CVS. But I suppose that's the reason.

iirc it's only in the avs 2.6 branch as of yet, from not yet having merged its way to the main/head branch

I'm sorry but I cannot find any 2.6 branch.

[Wilbert]

I'm sorry but I cannot find any 2.6 branch.
http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/?pathrev=avisynth_2_6

[XhmikosR]

Thanks a lot Wilbert. Is there any particular reason why it hasn't been merged in the head branch?

[Wilbert]

Thanks a lot Wilbert. Is there any particular reason why it hasn't been merged in the head branch?
Two reasons:
* I think IanB wants to add this functionality in some other way.
* Other things (like the new plugin api) are also needed to be done before going beta.

I'm sure he responds if above is not correct.

[Wilbert]

@IanB and others,

* YUV planar (except "YV12 and options disabled") -> YUY2 via YV16
To get some consistency, perhaps it's good to change this to:

* YUV planar (always) -> YUY2 via YV16

So the explicit core formats will be Y8, YV12, YV16, YV24, YUY2, RGB24 and RGB32. Everything else will be User Generic YUV Planar with 1,2 or 4, H and V subsampling. Thorts?
Sounds fine. I guess we need two generic planar formats: YUV and PRGB. Also:

the conversions:

ConvertToPRGB(sample_bits=8/16/32, dither=true/false)
ConvertToYUV(sample_bits=8/16/32, h_subs=1/2/4, v_subs=1/2/4, dither=true/false)

and the functions:

IsPRGB(sample_bits=8/16/32)
IsYUV(sample_bits=8/16/32)

When doing a conversion from RGB to YUV (vice versa likewise):
(1) interleaved RGB -> planar RGB (if source is interleaved);
(2) planar RGB -> planar YUV (sample_bits constant)
(3) planar YUV -> planar YUV (dithering to the target sample_bits if necessary)
(4) planar YUV -> planar YUV (subsampling if necessary)
(5) planar YUV -> interleaved YUV (if target is interleaved)

What do you think about this? Or do you want to leave this for v2.61? I can take a stab at the functions above. I got planar RGB (just 3x8 bit) already working (also in BlankClip for example).

I also asked Tom about his dithering filter: Dither16to8Bit(): http://forum.doom9.org/showthread.php?p=1023134#post1023134 . Hopefully he will respond and we can use that.

There were discussions in the past about whether it should be 15bit, 16bit signed, 16bit unsigned. I don't think there was an agreement on something. Thoughts, anyone?

[IanB]

Why has fracking vBulletin® stopped nesting quoted replies again :devil: * YUV planar (except "YV12 and options disabled") -> YUY2 via YV16To get some consistency, perhaps it's good to change this to:

* YUV planar (always) -> YUY2 via YV16
Except that would change the existing YV12<->YUY2 behaviour.

Maybe we should announce the legacy conversions will retire in say 2.6.2


Sounds fine. I guess we need two generic planar formats: YUV and PRGB. Also:

the conversions:

ConvertToPRGB(sample_bits=8/16/32, dither=true/false)
ConvertToYUV(sample_bits=8/16/32, h_subs=1/2/4, v_subs=1/2/4, dither=true/false)

and the functions:

IsPRGB(sample_bits=8/16/32)
IsYUV(sample_bits=8/16/32)I haven't really thought to much about script presentation yet. My thrust is to have consistent usage of bits in the Pixel_type so you get IsRGB(), IsYUV(), IsPlanar(), IsInterleaved(), Is8Bit(), Is16Bit(), etc then build higher concepts like IsRGB32() and IsYUY2().

There were discussions in the past about whether it should be 15bit, 16bit signed, 16bit unsigned. I don't think there was an agreement on something. Thoughts, anyone?At the moment it doesn't matter until we actually have map between pixel formats. The API currently just chucks 8, 16 or 32 bit chunks at you, what they mean is mostly undefined. We assume if it is 8 bit RGB then all 0 is black and all 255 is white and for 8 bit YUV then black is 16, white is 235 and chroma is [-112, +112], except when someone plays with PC levels. The interpretation can depend on the pixel type, not sure it is a great idea to actually do it this way but ...

Likewise while in deep thought mode, what about 32bit pixels. Are they float, int32 or uint32. Is black 0.0 or 16.0 or another value. Is white 1.0, 235.0 or another value.

Also in 16 and 32 bit pixel formats do we undo gamma and make the values linear. My personal opinion is a very strong yes. Currently almost every avisynth filter will average 64 and 192 to get 128 and this is visually acceptable most of the time, but in a purely linear intensity case it should be around 119. Sometimes it matters sometime it does not, e.g. when doing antialiasing there is a vary significant improvement when including gamma in the calculations.

Thorts!

[Didée]

Thorts!
Sir! Yes, Sir!

Also in 16 and 32 bit pixel formats do we undo gamma and make the values linear. My personal opinion is a very strong yes.
If so, there should be some sort of boolean switch for that. Not all clips' data represent actual image data. Some clips might be masks or difference-maps or whatnot, and ... Currently almost every avisynth filter will average 64 and 192 to get 128 and this is visually acceptable most of the time, but in a purely linear intensity case it should be around 119.
... especially when working with differences, it's usually preferable that (64+192)/2 gives 128, not 119. ;)

[IanB]

Also in 16 and 32 bit pixel formats do we undo gamma and make the values linear. My personal opinion is a very strong yes.If so, there should be some sort of boolean switch for that. Not all clips' data represent actual image data. Some clips might be masks or difference-maps or whatnot, and ...Yes, there is an implied assumption that there will be some script control over the gamma value used, i.e. ConvertToYV96(Gamma=2.2)

Currently almost every avisynth filter will average 64 and 192 to get 128 and this is visually acceptable most of the time, but in a purely linear intensity case it should be around 119.... especially when working with differences, it's usually preferable that (64+192)/2 gives 128, not 119. ;)
I am not saying (64+192)/2 ever gives 119, but that we assume the value 192 represents a pixel that is visually 3 times brighter than the value 64. Well more like 30000 versus 10000, I hope you get the idea ....

In gamma=2.2, 8 bit space, 192 represents 87.7% brightness, 128 represents 73.0%, 119 represents 70.6% and 64 represents 53.2%

[IanB]

CVS Maintenance

I had a little spare time today so I started folding the "avisynth_2_6" branch back into the the main branch. The docs are all done, as is most of the main code (a few core elements are still pending). The 3 plugins are still to be done.

[kemuri-_9]

what's the status on how avisynth_c.h is going to be handled for 2.6?

Asking because this is going to be necessary for x264's purposes in the relatively near future.

for the time being I've edited the current avisynth_c.h to recognize the new colorspaces with new inline functions which is the bare minimum that i require atm.
but this is the exact opposite of what happened to avisynth.h, where the code behind that wandered off to interface.cpp (since there's been a move to prevent baking code in)

I'm guessing the end result of the moved interface code is to
A) export the classes/functions via __declspec and require an import lib for plugin writers
or
B) add new exported functions(s) to the avisynth.dll that will return a struct or something along these lines that will have the functions contained within.

and the C interface would likely be handled similarly whatever the case ends up being...
*ramble* *ramble*

[IanB]

@kemuri-_9,

If one bakes 2.6 code into an external module, then it's one's problem when we change the API and users fall out of the sky.

All the baked things declared "AVSC_INLINE" become proper "AVSC_API" with matching new C entry point for the real code. Some duplicates go away or get a legacy #define.

Choice of using avisynth.lib for static linkage like now or new "AVSC_NO_DECLSPEC" for dynamic linkage. That name may change.

The ""AVSC_INLINE AVS_Library * avs_load_library" and "AVSC_INLINE void avs_free_library(AVS_Library *library)" need some more thought so that every module that #include <avisynth_c.h> does not get a duplicate copy of that code. I just parked the code as contributed so it would not be forgotten.

Also I want to try to support both __cdecl and __stdcall calling conventions, i.e. export 2 sets of entry points, __stdcall keeps the existing names, __cdecl gets some prefix and/or suffix.

[kemuri-_9]

@kemuri-_9,

If one bakes 2.6 code into an external module, then it's one's problem when we change the API and users fall out of the sky.


Yes, this is correct so i could technically continue with my new baked API (that i stole/adapted from interface.cpp) but I'd rather not do that when there's something else in the works that's going to be the correct/supported way.
though i will need the baked API in a way so we maintain avs 2.5 support in x264. (but that's a different situation that I'll pursue at the necessary time)


All the baked things declared "AVSC_INLINE" become proper "AVSC_API" with matching new C entry point for the real code. Some duplicates go away or get a legacy #define.


which baked functions from avisynth_c.h are going to be made into API?

IMO all the "avs_is_yv12, avs_is_yuy2", and etc are fluff as all of these are just convenience methods that are already achievable via avs_is_colorspace.
Though avs_is_colorspace depends on the enums for each of the colorspaces being properly defined and unlikely to change...
But with how the csp enums are setup now with the current scheme of things, it doesn't look like they'll need to be changed...


Choice of using avisynth.lib for static linkage like now or new "AVSC_NO_DECLSPEC" for dynamic linkage. That name may change.

The ""AVSC_INLINE AVS_Library * avs_load_library" and "AVSC_INLINE void avs_free_library(AVS_Library *library)" need some more thought so that every module that #include <avisynth_c.h> does not get a duplicate copy of that code. I just parked the code as contributed so it would not be forgotten.


Yes, I had noticed you committed this eventually after my original request for the feature....
what were your ideas on changing it to?


Also I want to try to support both __cdecl and __stdcall calling conventions, i.e. export 2 sets of entry points, __stdcall keeps the existing names, __cdecl gets some prefix and/or suffix

the only point i see for __cdecl is for explicit declaration for functions using varargs (since they are __cdecl already).

generally the stdcall form is more preferred on windows due to it cleaning the stack by the callee rather than by the caller.
so what would be the exact reason to have __cdecl varieties of the __stdcall methods?

[Wilbert]

@IanB,

Apparently there is a bug in the rgb resizers (2.58/2.6): http://forum.doom9.org/showthread.php?p=1392361#post1392361 (thanks to JoshyD)

[IanB]

@Wilbert,

Yes I saw that. I just checked in a fix and a tune. SF is back online at last.

[Frank K Abbott]

How does this function with MT and setmtmode whose dll is only out for 2.5.8 so far?

[Gavino]

For some time, I have been puzzled (and mildly annoyed!) that using a run-time function like AverageLuma outside of a run-time filter (ScriptClip, etc) produces the error "Invalid arguments to function ...", especially when the source code contains logic to produce the more helpful "This filter can only be used within ConditionalFilter". So I decided to investigate properly.

The reason the more helpful (and presumably intended) message is not produced is that the code (in AveragePlane::AvgPlane and elsewhere) looks like this:
AVSValue cn = env->GetVar("current_frame");
if (!cn.IsInt())
env->ThrowError("Average Plane: This filter can only be used within ConditionalFilter");
However, if current_frame does not exist (the usual case outside the run-time environment), GetVar will throw a NotFound exception and the error-checking code will never be reached. The exception is propagated back to the parser, which is evaluating the original call to AverageLuma (etc), where it sees this as an inability to call and reports it as "Invalid arguments".

The solution is to use the exception-protected GetVar from conditional_reader.h instead of env->GetVar to read current_frame (in 4 places in conditional_functions.c). At the same time, the error message could be changed to refer to "run-time filters" instead of specifically to ConditionalFilter (which I suspect was the only one that existed when this code was written).

[Terranigma]

There's a new version of soundtouch [1.5.0]. You think you guys could incorporate the change in the next release?

Also, could you bring back the previous behavior of conditionalreader for boolean types where you could specify true or false without adding a space after a value?

e.g. previous behavior:
1080t = works

e.g. new version:
1080t = doesn't do anything
1080 t = works

:thanks:

[Frank K Abbott]

I'm getting a no function named spline64resize() error and I'm a bit confused as to where to get the MT and modded avisynth dll for 2.6

[IanB]

@Frank K Abbott,

MT and setmtmode are not currently supported.

Spline64Resize works fine for me. Whose version of 2.6 are you using?


@Terranigma,

I seem to remember commenting on this before, but I can't find my previous post. There have been no changes that effect Avisynth's usage of of SoundTouch. All of the changes are in the free standing application and source code tweaks to pacify the latest recalcitrant compilers. I will be picking up the current version when I do the change to the next compiler at 2.6.1.5.1. SoundTouch library Change History

1.5.0:

* Added normalization to correlation calculation and improvement automatic seek/sequence parameter calculation to improve sound quality
* Bugfixes:
o Fixed negative array indexing in quick seek algorithm
o FIR autoalias filter running too far in processing buffer
o Check against zero sample count in rate transposing
o Fix for x86-64 support: Removed pop/push instructions from the cpu detection algorithm.
o Check against empty buffers in FIFOSampleBuffer
o Other minor fixes & code cleanup
* Fixes in compilation scripts for non-Intel platforms
* Added Dynamic-Link-Library (DLL) version of SoundTouch library build, provided with Delphi/Pascal wrapper for calling the dll routines
* Added #define PREVENT_CLICK_AT_RATE_CROSSOVER that prevents a click artifact when crossing the nominal pitch from either positive to negative side or vice versa


And "1080t" should be throwing a syntax exception. I'll look into it.

[Frank K Abbott]

Yea the main prob was that I switched out replaced the avisynth.dll in system32 with the 2.8.5 version that was modded by Jeremy with 2.6 installed so that's why spline64resize wasn't working. When is MT support expected in AviSynth 2.6?

[MfA]

Likewise while in deep thought mode, what about 32bit pixels. Are they float, int32 or uint32. Is black 0.0 or 16.0 or another value. Is white 1.0, 235.0 or another value.
Floating point, standard conversions should use 0.0 for 0 and 1.0 for 255. Pixel shaders are the most familiar floating point image filters and that's how they do it ... I see no good reason to deviate.
Also in 16 and 32 bit pixel formats do we undo gamma and make the values linear.
Good for default behaviour, but conversions should let the user disable it or set their own lift/gamma/gain values.

[IanB]

@MfA,

It's good that others are thinking about this.

Of course if the API luminance distribution is truly linear, then there should be an expectation that coming from and going to the existing 8 bit spaces be user configurable for gamma, range and bias. i.e. O=(((I-k1)*k2)**k3)*k4+k5

For k3==2 there are some obvious very fast implementations with pmullw xmm0, xmm0 and a fairly quick implementation with sqrtps xmm1, xmm2 for k3==1/2. So there is a practical case for the API to say the 16bit and 32bit formats are fixed wrt Gamma=2.0 versus the 8bit spaces and the user only gets to pick from a limited selection of k1, k2, k4 & k5.

There are also some quickish implementations for O=logN(I) and O=k**I using exponent bit stuffing with IEEE floats which might mitigate the above assertion.

For the 16bit space note that 255**2=65025 (fits) and 255**2.2=196964.7 (doesn't fit)

[MfA]

k2 is redundant and k5 doesn't really belong in a gamma curve IMO.

Any way ... reading a bit, Rec 709 is the standard for cameras, and it can't even be described by this formula and neither can sRGB. So you need flags for Rec 709 and sRGB as well as the general gamma curve with parameters (oh and wikipedia says EBU uses a different gamma value for Rec 709 as well, wonderful).

You'll need a little more than just bit stuffing, Jim Blinn's tricks aren't very precise ... at least not with single precision.

I don't see the need for 16 bit, but if it has to be done why not just do the conversions in floating point and then go back to 16 bit to save some headaches?

[IanB]

@MfA,

Think a little harder about the algebra involved, yes a real implementation probably would fold k2 into k4 as k2**k3 to avoid a redundant pmul*, but I hoped the general expression would be clearer for documentation purposes. i.e. YV12 to a 'YV48' k1=16, k2=1/235, k3=2.2, k4=32767, k5=0 and the inverse k1=0, k2=1/32767, k3=1/2.2, k4=235, k5=16.

As for k1 and k5 they will usually be 0, 16 or the translation of 16.

For explicit complex conversions for Rec709, sRGB, etc you are probably looking at a plugin.

What I am brainstorming for here is a proposed relationship between existing 8bit spaces and possible 16bit and 32bit spaces. The way I am reading your responses is as inverse arguments that point back to a fixed Gamma=2.0 rule.

Yes Jim Blinn's 'tricks' are a little brutish, but for a 235 state translation they can be made to do a satisfactory job.

And for well implemented filters 16bit could be twice as fast as 32bit (memory bus limited, as in BitBlt).

[MfA]

Inverse gamma correction in YUV doesn't make a whole lotta sense, if you want to work in a linear colour space the linearisation has to happen in RGB. Which is why I don't see the need for level adjustments ... those will be taken care of in YUV<->RGB. After linearisation you can go back to YUV if you want.

I disagree about the Rec.709 transfer function, it deserves to be in core for (inverse) gamma correction as much as it deserves to be in there (with Rec.601) for YUV<->RGB. Skipping sRGB okay, but the industry standard?

[tritical]

Seems there is a bug in the cache filter's handling of setcachehints(). Specifically, if CACHE_NOTHING is sent, it doesn't check to see if setcachehints() was previously called with CACHE_RANGE or CACHE_ALL... it simply sets h_policy = CACHE_NOTHING. IMO it should always go with the largest request. Avisynth 2.6 and 2.5.8 seem to work this way.

Also, since it isn't mandatory for filters to call setcachehints() - which would be a really good idea IMO, the cache filter needs some other way to know if it is being hit by multiple filters and override a CACHE_NOTHING hint. Otherwise, it's never safe to use CACHE_NOTHING because while your filter may not require caching, you never know if a second or third or fourth, etc... filter is hitting the same cache but doesn't call setcachehints(). Even if all of those filters are non-temporal (don't require caching if used alone) and hint CACHE_NOTHING, a cache would be useful when they are all branching from the same point.

[Gavino]

Seems there is a bug in the cache filter's handling of setcachehints(). Specifically, if CACHE_NOTHING is sent, it doesn't check to see if setcachehints() was previously called with CACHE_RANGE or CACHE_ALL... it simply sets h_policy = CACHE_NOTHING. IMO it should always go with the largest request. Avisynth 2.6 and 2.5.8 seem to work this way.
I wasn't sure what you meant at first, since as far as I know SetCacheHints has always been like this, and it's not something specific to 2.6.0 Alpha 2.

But I think you are actually saying that this a design fault in SetCacheHints, period. Your suggested change seems reasonable, but would prevent a single filter from setting the hints to CACHE_NOTHING after it had previously set them to something higher (in practice however, not a very likely requirement).

[kemuri-_9]

i have a question about the following in interface.cpp:

bool VideoInfo::IsYV12() const { return (pixel_type & CS_PLANAR_MASK) == (CS_YV12 & CS_PLANAR_FILTER); }

this IsYV12() is different from the 2.5.x series in the fact that this 2.6.x version does not detect and flag CS_I420 as also being YV12 like it did for 2.5.x.
was it intended for the transparency of I420 being recognized as YV12 to vanish with 2.6.x or is this a bug?

[IanB]

@Tritical, Gavino,

Yes, the way Cache hints are handled sucks and always has. The decision for doing a CACHE_NOTHING is a bit barse ackwards, really the child should be the one saying I am a zero (or very low cost) filter, I do not need to be cached. And for the CACHE_ALL case, it seeds a number that really doesn't tune anything very much. And for the CACHE_RANGE case their has been universal confusion about what the argument value actually means.

You may have noticed that I have cribbed with the ABI a little and now have SetCacheHints returning an int (was void). virtual int __stdcall SetCacheHints(int cachehints, int frame_range) = 0 ; // We do not pass cache requests upwards, only to the next filter.The idea being to have filters optionally implement this method so the parent cache instance can query the child about it's performance criteria, i.e. Things like :- Zero cost? MT challenged? Is sequential cheap? Is random expensive?, ...

I'll probably reassign the actual enum values for these keys and treat the old values as legacy and do something safe for calls from legacy 2.5 filters.



@kemuri-_9,...
CS_PLANAR_FILTER = ~( CS_VPlaneFirst | CS_UPlaneFirst ),
...
CS_YV12 = CS_PLANAR | CS_YUV | CS_Sample_Bits_8 | CS_VPlaneFirst | CS_Sub_Height_2 | CS_Sub_Width_2, // y-v-u, 4:2:0 planar
CS_I420 = CS_PLANAR | CS_YUV | CS_Sample_Bits_8 | CS_UPlaneFirst | CS_Sub_Height_2 | CS_Sub_Width_2, // y-u-v, 4:2:0 planar
...

[kemuri-_9]

@kemuri-_9, CS_PLANAR_FILTER = ~( CS_VPlaneFirst | CS_UPlaneFirst ),

Ah, I seemed to have overlooked how this was defined...
it's a bit obscure that the & CS_PLANAR_FILTER covers both YV12 and I420 in the condition, but i guess it works... though a note indicating this would be useful.

[IanB]

YV12 and I420 are the same primitive colour space to Avisynth. As of 2.6 the CS_VPlaneFirst and CS_UPlaneFirst bits are only used in env->NewVideoFrame() to set the initial order of the chroma planes in memory. Once on the fly the plane order should be irrelevant. In fact the SwapUV() filter just flips the pointers in the PVideoFrame, likewise the UtoY8 and VtoY8 just snatch the appropriate pointer and size numbers, making all 3 zero cost filters.

[kemuri-_9]

right, it's just seems like I420 is a special case though that's because it is the only colorspace that is CS_VPlaneFirst.

on the point of the colorspaces, is YUV9 going to be supported by 2.6? it's not commented out in avisynth.h though it is everywhere else.
if it is going to be supported then YVU9 should also be supported, this would give another use case to CS_VPlaneFirst being utilized making I420 seem less special-cased.

it would also be interesting to see NV12 eventually get supported by avisynth.
But as it doesn't seem to fit into the colorspace definition scheme as it is a peculiar format that has Y as planar and UV as interleaved, this doesn't look currently feasible.

[tritical]

Going back to the cache. My suggestion for going with the max request was due to scripts such as:

some_source()
a = last.spatial_filter1()
b = last.temporal_filter()
c = last.spatial_filter2()
another_filter(a,b,c)

Now you've got multiple filters hitting the same cache (this scenario is where the cache helps significantly). Let's say both spatial_filter's send CACHE_NOTHING, the first temporal filter sends CACHE_RANGE, the final filter doesn't call setcachehints() at all. The cache gets disabled causing a big slow down depending on the speed of some_source(). If the cache goes with the max request it wont get disabled. Of course, this doesn't fix the problem if temporal_filter doesn't call setcachehints(). It also doesn't fix the problem if all the filters are spatial and send CACHE_NOTHING, which would be fine if each was the only filter requesting from that point, but if two or more are requesting then a cache is useful.This is why I said the cache really needs a way to know how many filters are requesting from it, and that with how it currently works, sending CACHE_NOTHING is never really a good idea. Of course, there are a few external plugins around that can be used to fix this situation if you are aware of it.

Another situation is that cache instances are not added after aligned/unaligned splice, which makes sense, but the splice filter doesn't pass setcachehints() on. So if you do something like:

a = source1()
b = source2()
a+b
somefilter()

somefilter calling setcachehints does absolutely nothing. I would expect the setcachehints call from somefilter to be passed through splice to the cache's after source1() and source2().

[Wilbert]

I was looking at Mask() and i might have found something. The code "starts" with

cyb = int(0.114*32768+0.5);
cyg = int(0.587*32768+0.5);
cyr = int(0.299*32768+0.5);

__declspec(align(8)) static const __int64 rgb2lum = ((__int64)cyr << 32) | (cyg << 16) | cyb;
__declspec(align(8)) static const __int64 alpha_mask = 0x00ffffff00ffffff;
__declspec(align(8)) static const __int64 color_mask = 0xff000000ff000000;
/*
for (int y=0; y<vi.height; ++y)
{
for (int x=0; x<vi.width; ++x)
src1p[x*4+3] = (cyb*src2p[x*src2_pixels] + cyg*src2p[x*src2_pixels+1] +
cyr*src2p[x*src2_pixels+2] + 0x8000) >> 16;

src1p += src1_pitch;
src2p += src2_pitch;
}
*/
__asm {
...
}

I can't judge whether the mmx code is the same as the commented c code. If it is supposed to be the same then i think the coefficients should be

cyb = int(0.114*65536+0.5);
cyg = int(0.587*65536+0.5);
cyr = int(0.299*65536+0.5);

Apologies if the mmx-code is correct.

[IanB]

@Wilbert,

Yes, the following script show a 1 bit discrepancy:-ColorBars()
Subtract(Mask(BlankClip(Last), Last).ShowAlpha(), GreyScale())The C code comment is pretty boiler plate but does not quite match the MMX code. In MMX you are stuck with 16bit signed multiplies, so the scale factor can only be 32768. Likewise the rounder should be half this, i.e. 16384 (0x4000).

So I have adjusted the comments and added the rounding into the main code, I'll check this into CVS next commit.

[kemuri-_9]

An issue has been brought to my attention involving x264 with the underlying cause being avisynth:

scenario:
an autoloaded .avsi script has a syntax error

result:
x264 crashes.

cause:
the Avisynth C API avs_create_script_environment has no try/catch wrapping around the use of CreateScriptEnvironment() which throws exceptions, like in the case of of an autoimported script having parser exceptions.
this causes the C application to crash from unhandled C++ exceptions.

as such there are two options to handling the situation...

option A:
if there's an exception, simply return a NULL/0 value

extern "C"
AVS_ScriptEnvironment * AVSC_CC avs_create_script_environment(int version)
{
AVS_ScriptEnvironment * e = 0;
try
{
e = new AVS_ScriptEnvironment;
e->env = CreateScriptEnvironment(version);
}
catch (std::bad_alloc) {}
catch (AvisynthError) {
delete e;
e = 0;
}
return e;
}

option B:
Utilize the already existing error field of AVS_ScriptEnvironment and expose this with a new API function (as it is not currently exposed for some reason I am not aware of)

// add this method to avisynth_c.h and avisynth.def as well
extern "C"
const char * AVSC_CC avs_get_error(AVS_ScriptEnvironment * p) // return 0 if no error
{
return p->error;
}

extern "C"
AVS_ScriptEnvironment * AVSC_CC avs_create_script_environment(int version)
{
AVS_ScriptEnvironment * e = 0;
try
{
e = new AVS_ScriptEnvironment;
e->env = CreateScriptEnvironment(version);
}
catch (std::bad_alloc) {}
catch (AvisynthError err) {
e->error = err.msg;
}
return e;
}

[IanB]

@kemuri-_9,

Yes all stub functions should try/catch Avisynth errors.

On a quick scan I can see at least avs_function_exists(), avs_new_video_frame_a(), avs_make_writable(), avs_create_script_environment() and avs_delete_script_environment() having unprotected IScriptEnvironment calls.

Yes, AVS_ScriptEnvironment is opaque, so how have people been getting access to AVS_ScriptEnvironment::error, seems logical that there be avs_get_error(AVS_ScriptEnvironment * p).

AVS_Clip also has an error member and it has avs_clip_get_error(AVS_Clip * p).

Any other missing bits and pieces you are aware of?

The current runtime environment does not know about std::bad_alloc, the expected behaviour is malloc returning 0 on failure. What are you suggesting here?

And unfortunately what you need cannot be done transparently. So you will need AVISYNTH_INTERFACE_VERSION > 3 to get support for these fixes. :(

[kemuri-_9]

@kemuri-_9,

Yes all stub functions should try/catch Avisynth errors.

On a quick scan I can see at least avs_function_exists(), avs_new_video_frame_a(), avs_make_writable(), avs_create_script_environment() and avs_delete_script_environment() having unprotected IScriptEnvironment calls.

Yes, AVS_ScriptEnvironment is opaque, so how have people been getting access to AVS_ScriptEnvironment::error, seems logical that there be avs_get_error(AVS_ScriptEnvironment * p).

indeed AVS_ScriptEnvironment is an opaque struct so up until now there has been no way of accessing the error field of it unless the calling application goes into the avisynth codebase and gets the definition for it.
which is an extremely risky/bad practice to do.


AVS_Clip also has an error member and it has avs_clip_get_error(AVS_Clip * p).

Any other missing bits and pieces you are aware of?

yes, avs_clip_get_error has been in use since i switched x264 from using VFW API to the C API.

I am not aware of any other missing functionality at this time.


The current runtime environment does not know about std::bad_alloc, the expected behaviour is malloc returning 0 on failure. What are you suggesting here?

the std::bad_alloc was primarily to catch the potential exception thrown by the new on AVS_ScriptEnvironment
(a habit from x264 since it checks all memory allocations, even the really small ones).
truthfully the new/delete on AVS_ScriptEnvironment seems a bit overkill (I'm not particularly fond of new/delete on structs).
the new/delete could be replaced by use of calloc/free, which would also allow the constructor in AVS_ScriptEnvironment to be removed.


And unfortunately what you need cannot be done transparently. So you will need AVISYNTH_INTERFACE_VERSION > 3 to get support for these fixes. :(

Yes, this does change the C API to expose a new function...
I never particularly understood why the C API has its own version though...
this doesn't make much since to me as the version checks are technically against the C++ API version (which is currently at 5 in 2.6)
so if the user has avs 2.6, the 4 value you're bumping the C API version to will still pass initialization checks even though it could not have the new API function.
if you want this version check to work as intended for the C interface, it needs to be overhauled in some fashion.

[IanB]

Yes the avs_create_script_environment(int version) code is confused. It should be checking against it own API version not the C++ API version.

The API version should refer to how much of the set of entry points are available. And we have been quite slack in updating this value as new entry points get added across the Avisynth versions.

The C API has an easier time here, either the DLL won't load if statically linked and need entry points are missing or the GetProcAddress calls fail with dynamic linking (and hopefully get handled).

With the C++ API if the IScriptEnvironment's vtable is different/shorter than expected you get to run some random address, then crash and burn.

[DVDBob]

Are you working still on a new build because the latest official build is from 2009 September 27 ???

[royia]

Are you working still on a new build because the latest official build is from 2009 September 27 ???
I hope someone does.
This is an amazing project, I hope someone it taking care of it.

I would really like to see a portable version (Only DLL library for other applications, if it possible) and 64 bit support.

[dansrfe]

I hope MT and SetMTmode support comes out fast for this...

[LaTo]

I have a feature request: Can you add in the SDK a way to overlay text on a PVideoFrame?

It would be great, coding font only for a few debug info is a headache. Thanks!

[Gavino]

I have a feature request: Can you add in the SDK a way to overlay text on a PVideoFrame?
I requested this a while ago - see this thread.

[LaTo]

I requested this a while ago - see this thread.

Thanks Gavino, I missed this topic.

I hope this is still on the IanB's todolist because it would be really useful :D

[Wilbert]

Thanks Gavino, I missed this topic.

I hope this is still on the IanB's todolist because it would be really useful
That's already done months ago. Checkout the latest csv version.

[LaTo]

That's already done months ago. Checkout the latest csv version.

Great! I'll have a look this weekend.

[StainlessS]

Moved here from another thread:

Do you have an example where this is broken?

colorbars.Trim(0,100).ConvertToYV12() # 640x480@29.97
#ConvertToYUY2() # UnComment in v2.6 for error @ ytouv()
u=utoy()
v=vtoy()
ytouv(u,v) # When crash, In VdubMod "File Information" shows 640x960 YUY2, then crash

[IanB]

Oops, some code is missing. Also screwed for non VY12 planar. :o

I'll check the fixes in next round of CVS updates.

[StainlessS]

@IanB

This snippet was posted in another thread, as you have not responded,
I thought I should re-post here:

NEW Info.h, as it stands, when signed char is used EXT ASCII
characters 128 & above [eg (c)opyright, chr$(137), I think]
will not print (never did under old Info.h) and if unsigned
then characters 224 and above will reach out of font with
rubbish results and potential access violation.

DDigit has always had a fix for this and is quite efficiently implemented.
See here for futher info and the post following for a demo of DDigitTest
which shows full character sets when signed char, unsigned char and
with the fix applied, for the new Info.h.

http://forum.doom9.org/showthread.php?p=1462089#post1462089

[jmac698]

I thought of a feature that would be useful, I'd like a new type info with just per video info, I could use this as a template on new videos. Example, I usually copy whole videos just to get a template of a video I want to create,
black=blackness
white=black.tweak(bright=255)
Where I could use:
color_black=$000000
color_white=$ffffff
info template=blackness
black=blankclip(template,color_black)
white=blankclip(template,color_white)
smalltemplate=template.crop(0,0,-(width-4),-(height-4)#4x4 square - or use ConvertTo(4,4)
whitesquare=blankclip(smalltemplate,color_white)

There's other examples where I'm passing a template around just to copy the info. Imagine someway to automatically adjust color formats and sample rates and even resolution. Using converto(clip video, info template). So I could load my video and just info DVDCompliant=(720,480,"YV12",48000,16) / mpg2source()... / ConvertTo(DVDCompliant).

Another thing I'd really like that's nearly impossible now, a way for a plugin to extend video properties especially per frame. I'd like to expose last.frametype (i.e. I, P, B) for example for a filter I want to write. (I found a way to merge two encodings of the same digital TV capture for improved SNR).
Anyhow, there's a standard hack for per frame, something about the lower bits of the first 64 pixels in a video has something in it? Debug hints from dgdecode and another plugin that can use it. There's also the motion vectors from mvtools.
Imagine every frame having an IsCombed property.. would be wonderful! And you could choose which plugin you want to give you that property. You could change plugins for difficult to detect sections, yet still have a general ScriptClip to deinterlace them.

[Gavino]

I thought of a feature that would be useful, I'd like a new type info with just per video info, I could use this as a template on new videos. Example, I usually copy whole videos just to get a template of a video I want to create
No need for a new type - a clip essentially is just a template until you start requesting frames from it. When you provide a 'template' clip to BlankClip/Blackness, all you are doing is copying its properties, not its contents.
Imagine someway to automatically adjust color formats and sample rates and even resolution. Using converto(clip video, info template). So I could load my video and just info DVDCompliant=(720,480,"YV12",48000,16) / mpg2source()... / ConvertTo(DVDCompliant).
You can always write your own ConvertTo function using the script language. But conversion of dimensions also involves a choice of resizer to use, aspect ratio considerations, etc.

[Wilbert]

I'm updating the documentation again :) Regarding SkewRows. I noticed that for RGB it skews from the bottom and for YUY2/Y8 from the top. It's perhaps nice to add this as an option where it starts to skew.

Also, when do you know when to use "Add "Global OPT_AVIPadScanlines=True" option for DWORD aligned planar padding."? Is it sometimes set to false by some input filters?

[Gavino]

Happy New Year, Wilbert (and anyone else reading this).

Regarding SkewRows. I noticed that for RGB it skews from the bottom and for YUY2/Y8 from the top.
My first thought was that this was a design fault - the visual result should not depend on internal representation. But I imagine the purpose of this filter is not to make pretty pictures, but to correct faults in source files and filters. In that case it makes sense for the skew always to start from where the data begins.

Another point - the doc says that skew is optional (default 0) - in fact it is mandatory.

[Wilbert]

Happy New Year, Wilbert (and anyone else reading this).
Likewise!

Another point - the doc says that skew is optional (default 0) - in fact it is mandatory.
Oops :) Corrected, thanks!

My first thought was that this was a design fault - the visual result should not depend on internal representation. But I imagine the purpose of this filter is not to make pretty pictures, but to correct faults in source files and filters. In that case it makes sense for the skew always to start from where the data begins.
Makes sense. Perhaps it's to fix the chroma shift here: http://forum.doom9.org/showthread.php?p=1425106#post1425106 I'm not sure however.

[IanB]

A Happy New Year, to all our Avisynth friends and family.

I'm updating the documentation again :) Regarding SkewRows. I noticed that for RGB it skews from the bottom and for YUY2/Y8 from the top. It's perhaps nice to add this as an option where it starts to skew.
Yes as noted above the skewing is memory layout based, so RGB images are skew from the bottom up, YUV images are skew from the top down. I threw it together to read those skewed error messages that some media player users were submitting a short while ago, so no great amount of thought went into the design.

The effect of the algorithm is to paste all of the input rows together as one single very long row, then slice them up based on the new width (= input width + skew). Skew can also be negative in which case the last skew pixels of each line are added to the beginning of the next line and you get some extra lines at the end. The last line is padded with grey pixels when required.

The geometry of the output is calculated thus :-
. OutWidth = InWidth + Skew // signed skew values acceptable
. OutHeight = (InHeight*InWidth + OutWidth-1) / OutWidth // Ceiling

Also, when do you know when to use "Add "Global OPT_AVIPadScanlines=True" option for DWORD aligned planar padding."? Is it sometimes set to false by some input filters?
OPT_AVIPadScanlines controls the memory alignment used in the AVIFile output emulation, class CAVIFileSynth::, Avisynth input filters should have nothing to do with this output option. Programs that use direct Avisynth API input, e.g x264, will be unaffected by this option, but may choose to support it if appropriate.

Microsoft specify 4 byte, DWORD, alignment for the simple DIB compatible formats, RGB24, RGB32, YUY2 and Y8. They make no specification for other formats, i.e. it is format specific.

Avery Lee in VirtualDub assumes all planar YUV formats are packed, i.e. pitch = rowsize, and all DIB compatible formats are DWORD aligned, i.e. pitch = (rowsize+3)/4 * 4.

By default Avisynth conforms to VirtualDub's alignment and packing expectations. For other software using AVIFile input that may assume DWORD alignment of a planar format the user can set OPT_AVIPadScanlines=True. With VirtualDub's direct stream copy mode the Avisynth AVIFile emulation packing is copied through, so DWORD aligned planar AVI files can be created by this method.

Both DirectShowSource (257) and AviSource (260b3) test for and support both packed and DWORD aligned planar memory layouts.

For image widths such that the chroma rowsize is mod4 there is never an issue, i.e YV24 is mod4, YV16 and YV12 are mod8, YV411 is mod16. But for other widths the assumptions made by the software in use becomes relevant.

If the result of processing a planar output Avisynth script, via the AVIFile interface, shows row skewing then OPT_AVIPadScanlines=True may help.

[ajp_anton]

Is there a build of this that includes SetMTmode?

[Overdrive80]

In this link, you have avaliable different versions included MT. http://avisynth.org/mediawiki/Main_Page

[Gavino]

Is there a build of this that includes SetMTmode?
See IanB's answer at post #38:
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.

[jmac698]

Does this bug exist in 2.6?

#crop bug
exposebug=false#set to true to crash
n=exposebug?241:240
colorbars
crop(0,n,0,n)
#~ File "pyavs.pyo", line 310, in _GetFrame
#~ File "avisynth.pyo", line 139, in BitBlt
#~ WindowsError: exception: access violation reading 0x02DDFFE0

[Gavino]

Yes it does.
Reason is code in transform.cpp:
} else {
// RGB is upside-down
_top = vi.height - _height - _top;
}

if (_left + _width > vi.width || _top + _height > vi.height)
env->ThrowError("Crop: you cannot use crop to enlarge or 'shift' a clip");
For RGB, if _top+_height > vi.height, _top will become negative and will not be caught by the following error check.

[jmac698]

Amazing. I did a quick search and can't find any other bugs reports. If only there were a bounty :) I tend to do advanced/weird stuff and find bugs in any program.

[IanB]

Yes, The "Crop: you cannot use crop to enlarge or 'shift' a clip" test is wrong for RGB. Fixed!


@Gavino: Snap! ;)

[jmac698]

could we update this page:
http://avisynth.org/mediawiki/Known_Issues
I don't know where else to put it.

[jmac698]

I was wondering if this behavior exists in 2.6, and if you can think of a way of reducing memory usage, and also improve the color problems to the same amount of accuracy as Layer, finally why do I get the wrong lines at the top when n>=26?:

#Overlay uses color conversions, this can be a problem if called many times
#you will see an increasing yellowish color at the top of the screen
#the script also uses a large amount of memory
#Layer has none of these issues
#Layer does have issues when n>=26, the wrong lines appear
base=blankclip.trim(0,9)
over=colorbars.trim(0,9)
showissue=true#Be careful with overlayissue, large values of n cause excessive memory use leading to a crash
showissue?overlayissue(base,over,25):layernonissue(base.resetmask,over.resetmask,26)
function overlayissue(clip base, clip over, int n) {
n<2?overlay(base,over.crop(0,n-1,0,1),y=n-1):overlay(overlayissue(base,over.crop(0,n-1,0,1),n-1),over.crop(0,n-1,0,1),y=n-1)
}
function layernonissue(clip base, clip over, int n) {
n<2?layer(base,over.crop(0,n-1,0,1),y=n-1):layer(layernonissue(base,over.crop(0,n-1,0,1),n-1),over.crop(0,n-1,0,1),y=n-1)
}

[Gavino]

why do I get the wrong lines at the top when n>=26?

function layernonissue(clip base, clip over, int n) {
n<2?layer(base,over.crop(0,n-1,0,1),y=n-1):layer(layernonissue(base,over.crop(0,n-1,0,1),n-1),over.crop(0,n-1,0,1),y=n-1)
}
Because your script is wrong - you are passing a one-line clip on the recursive call, which then gets cropped beyond its end. (This should give an error, but doesn't, which is the bug you've already reported.)
The second parameter should just be over at all recursive levels. (Would have been easier using GScript ;))

The same error exists in overlayissue, which probably explains the crashes for large n.

[jmac698]

Great, that fixed one of the problems. There is still a huge amount of memory used in overlay, hundreds of MB.

#Overlay uses color conversions, this can be a problem if called many times
#you will see an increasing yellowish color at the top of the screen
#the script also uses a large amount of memory
#Layer has none of these issues
base=blankclip.trim(0,9)
over=colorbars.trim(0,9)
showissue=true#Be careful with overlayissue, large values of n cause excessive memory use leading to a crash
showissue?overlayissue(base,over,25):layernonissue(base.resetmask,over.resetmask,400)
function overlayissue(clip base, clip over, int n) {
n<2?overlay(base,over.crop(0,n-1,0,1),y=n-1):overlay(overlayissue(base,over,n-1),over.crop(0,n-1,0,1),y=n-1)
}
function layernonissue(clip base, clip over, int n) {
n<2?layer(base,over.crop(0,n-1,0,1),y=n-1):layer(layernonissue(base,over,n-1),over.crop(0,n-1,0,1),y=n-1)
}

[GRKNGLR]

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.

When will an MT-supporting version be released? Will there be x64 support at the 2.6 release?

[kemuri-_9]

latest repository does not compile in .net 2008:


1>.\filters\levels.cpp(187) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.\filters\levels.cpp(201) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.\filters\levels.cpp(213) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.\filters\levels.cpp(224) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.\filters\levels.cpp(236) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

since the fix is trivial i'll withhold posting a patch.

[yup]

I try last official Avisynth 2.6 with simple script
ImageSource("TSW Charger V4.4.jpg", end=0)
ConvertToYUY2()
nnediresize_YUY2()
function nnediresize2x(clip c, bool pY, bool pU, bool pV)
{
v = c.nnedi3(dh=true,Y=pY,U=pU,V=pV,field=0).turnleft()
v = v.nnedi3(dh=true,Y=pY,U=pU,V=pV,field=0).turnright()
return v
}

function nnediresize_YUY2(clip c)
{
cy = c
cu = c.utoy()
cv = c.vtoy()
cy = nnediresize2x(cy,true,false,false)
cu = nnediresize2x(cu,true,false,false)
cv = nnediresize2x(cv,true,false,false)
return ytouv(cu,cv,cy)
}

function nnediresize_YV12(clip c)
{
return nnediresize2x(c,true,true,true)
}

for enlarge image, it is work with YV12 colorspace, but not work with YUY2.
Please explain.
yup.

[IanB]

Sorry the YUY2 version of the YtoUV() code is broken. See post 132 above by Stainless.

The planar version works so you could use an intermediate YV16 and then convert that to YUY2 at the end.

Also a better workflow in 2.6 would be RGB -> YV24 -> nnedi3 -> YV16 -> YUY2, which would save doubling the chroma width.
ImageSource("TSW Charger V4.4.jpg", end=0) # RGB Format

ConvertToYV24() # No chroma subsampling

nnediresize_YUY2()

function nnediresize2x(clip c, bool pY, bool pU, bool pV)
{
v = c.nnedi3(dh=true,Y=pY,U=pU,V=pV,field=0).turnleft()
v = v.nnedi3(dh=true,Y=pY,U=pU,V=pV,field=0).turnright()
return v
}

function nnediresize_YUY2(clip c)
{
cy = c.ConvertToY8().ConvertToYV12() # Fast extract Y, blank chroma
cu = c.UtoY8().ConvertToYV12() # Fast extract U to Y, blank chroma
cv = c.VtoY8().ConvertToYV12() # Fast extract V to Y, blank chroma

cy = nnediresize2x(cy,true,false,false) # Double height and double width

cu = nnedi3(dh=true,Y=True,U=False,V=False,field=0) # Double height only
cv = nnedi3(dh=true,Y=True,U=False,V=False,field=0) # Double height only

YtoUV(cu,cv,cy) # YV16 output
return ConvertToYUY2() # Lossless conversion to YUY2
}The *toY8() are all zero cost (pointer flip only) for planar. The Y8 to YV12 costs a plane blit + 2 memfills. A normal YV24 to YV12 would cost a resize of the chroma but as we don't want them here we can save a lot. As nnedi3() is a 2.5 filter it must have YV12.

[yup]

IanB :thanks:
But I get error at line
cy = c.ConvertToY8().ConvertToYV12() # Fast extract Y, blank chroma
yup.

[IanB]

@yup,

And the error message is ???? :confused:

[yup]

IanB!
Please.
Line 5 it it is line calling nnediresize_YUY2(), Line 16 it it is line cy = c.ConvertToY8().ConvertToYV12() # Fast extract Y, blank chroma
yup.

[Gavino]

Sorry the YUY2 version of the YtoUV() code is broken.
Is this fixed in CVS?
Any timescale for getting a new release out?
On 18th Jan 2011, you said:
The bugfix list has become pretty meaty, perhaps I should devote some cycles to give people a release. I'll try to put some effort into fixing the offset errors in the planar conversions and then roll out another alpha release soon.
I know there are some third party CVS builds floating about, but a new official release (even if still alpha) would be a very welcome addition.

@yup:
Wouldn't it have been more useful just to quote the error message? - images can take some time to be approved by a mod.

[IanB]

@Yup,

Looks like ConvertToYV12() is broken with Y8 input. :( You will have to go from YV24 direct to YV12 and wear the performance hit with this alpha release.

A possible faster solution might beFastishY8toYV12(Clip C) {
UV = Blankclip(C, Width=C.Width()/2, Height=C.Height()/2, Color=$808080)
Return YtoUV(UV, UV, C)
}

And Join Date: Feb 2003, Posts: 549, and you still can't report error messages as text. Hint: Press Control-C in VirtualDubs Error Messagebox, this copies the error text to the clipboard.

@Gavino,

Yes, I think most of these bugs have been addressed, and I am crawling towards doing another interim release, this time it might actually be somewhat tested.

[pbristow]

IanB,

No feature requests or bug reports from me at this time, just wanted to say thankyou for all the effort you're putting into this new V2.6. I'm looking forward to trying out the next official build. :)
:thanks:

[Wilbert]

@yup,

I moved several 'nnedi3 resize' posts to a new thread (http://forum.doom9.org/showthread.php?t=160887).

[pwnsweet]

I think I may have found a bug with Avisynth 2.5.8, MeGUI or something else, but I think it's with AviSynth. Before I can confirm it is a bug, it would be appreciated it someone can replicate my workflow to confirm that they have the same problem.

I'm using MeGUI 2008 (svn) to encode my movies. Basically I'm having a problem where the color displayed in the avs script creator window is never the same as the source, but the resultant encoded video is. I experienced this issue when indexing an .m2ts Blu-ray file (with an MPEG-2 video stream) using DGindex. When the .d2v is loaded into avs script creator, I've got the option to enable or disable color correction in the filters tab. Setting this option to on or off changes the colors slightly in the preview window (most noticeably with greens and reds) but neither setting produces the same colors as the source. Interestingly though, the colors of the actual encoded video had the same colors as the source when color correction was turned off.

Now, I'm not sure if this is a bug in AviSynth or a bug with me (ie, I'm not comparing them properly). So here's how I compare.

I open the source with Daum PotPlayer and then I open the preview window in avs script creator and compare them side by side with and without color correction. The result is neither setting produces the same colors as the source. When I'm comparing the encoded video to the source, I open the encoded mp4 in one PotPlayer window and the source in another and compare them side by side. The result is the encoded video only has the same color as the source when color correction is off. That's it.

Can someone please replicate this issue to see if they have the same problem? For reference, my source was Mission Imposssible 3 on Blu-ray. Alternatively, if there is a flaw in the way I compare, please point it out and explain why it's flawed so I can further my understanding (I'm noob). My script with color correction set to off is displayed below:

# Set DAR in encoder to 65 : 27. The following line is for automatic signalling
global MeGUI_darx = 65
global MeGUI_dary = 27
LoadPlugin("D:\stuff\megui\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Temp\MI3\00003.d2v")
#deinterlace
crop( 0, 130, 0, -132)

Spline36Resize(1504,640) # Spline36 (Neutral)
#denoise

[poisondeathray]

I think I may have found a bug with Avisynth 2.5.8. Before I can confirm it is a bug, it would be appreciated it someone can replicate my workflow to confirm that they have the same problem.

I'm using MeGUI 2008 (svn) to encode my movies. Basically I'm having a problem where the color displayed in the avs script creator window is never the same as the source, but the resultant encoded video is. I experienced this issue when indexing an .m2ts Blu-ray file (with an MPEG-2 video stream) using DGindex. When the .d2v is loaded into avs script creator, I've got the option to enable or disable color correction in the filters tab. Setting this option to on or off changes the colors slightly in the preview window (most noticeably with greens and reds) but neither setting produces the same colors as the source. Interestingly though, the colors of the actual encoded video had the same colors as the source when color correction was turned off.

Now, I'm not sure if this is a bug in AviSynth or a bug with me (ie, I'm not comparing them properly). So here's how I compare.

I open the source with Daum PotPlayer and then I open the preview window in avs script creator and compare them side by side with and without color correction. The result is neither setting produces the same colors as the source. When I'm comparing the encoded video to the source, I open the encoded mp4 in one PotPlayer window and the source in another and compare them side by side. The result is the encoded video only has the same color as the source when color correction is off. That's it.

Can someone please replicate this issue to see if they have the same problem? For reference, my source was Mission Imposssible 3 on Blu-ray. Alternatively, if there is a flaw in the way I compare, please point it out and explain why it's flawed so I can further my understanding (I'm noob). My script with color correction set to off is displayed below:

# Set DAR in encoder to 65 : 27. The following line is for automatic signalling
global MeGUI_darx = 65
global MeGUI_dary = 27
LoadPlugin("D:\stuff\megui\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Temp\MI3\00003.d2v")
#deinterlace
crop( 0, 130, 0, -132)

Spline36Resize(1504,640) # Spline36 (Neutral)
#denoise



probably a playback issue

the preview in megui uses rec601 to convert to rgb for display

your player is probably using rec709 for hd material

levels are untouched and you remain in YUV when you encode with that script using megui

ie. no additional RGB<=>YUV conversions are going on here , only when it's converted to RGB for display



To test this out, add converttorgb(matrix="rec709") to the end of your script, what does the preview look like in megui ? Comment it out (#)before you encode

[pbristow]

So, when you open both the source and the encoded video using *the same player* (PotPlayer), they have the same colours (provided you set colour correction to off). But if you open them in different players (one in PotPlayer, one in MeGui), they look different. Clearly then, the two players are disagreeing with each other about how the colours should be rendered on screen.

poisondeathray's explanation for that is probably correct... Or it could be a bug in either MeGui or PotPlayer. Nothing points to AviSynth as causing the problem.

Hope that helps. :)

[IanB]

An interim patch release.

Get AviSynth_110525.exe (4.9MiB) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/AviSynth_110525.exe/download) from SourceForge.

Note, it's now a full release with the documentation component.

[Mini-Me]

An interim patch release.

Get AviSynth_110525.exe (4.9MiB) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/AviSynth_110525.exe/download) from SourceForge.

Note, it's now a full release with the documentation component.

YAYYYY!!! It's funny, because I've been having some crashes this week with complex ScriptClip stuff, and I've been checking here for the past three days hoping for a new 2.6 release. I felt silly expecting it to be posted so imminently, but lo and behold! :)

I can't wait for the time to check it out. Thank you!

[Wilbert]

Thanks for the new release!

If I read the code correctly (and your adjusted documentation) i see that an YV12 clip (when converting to YV12 itself) is processed when ChromaInPlacement or ChromaOutPlacement is specified, right? (So this can be used to change the chroma placement in an YV12 clip.) I guess when both are specified and equal, the original clip can also be returned?


if (clip->GetVideoInfo().IsYV12()) {
if (!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5])
return clip;
}

[IanB]

If I read the code correctly (and your adjusted documentation) i see that an YV12 clip (when converting to YV12 itself) is processed when ChromaInPlacement or ChromaOutPlacement is specified, right? (So this can be used to change the chroma placement in an YV12 clip.) I guess when both are specified and equal, the original clip can also be returned?AVSValue ... ConvertToPlanarGeneric::CreateYV12(...) {
...
if (clip->GetVideoInfo().IsYV12()) {
if (!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5])
return clip;
}
...Yes it can be used to change the chroma placement in an YV12 clip.

And yes the code probably should check for ChromaInPlacement == ChromaOutPlacement, it currently relies on the resizer core to detect a null operation however the frame will still be plane split and reassembled so cost a needless set of blits.

[Mini-Me]

The new release has unfortunately not solved my crashes, so a question occurred to me: What's the best way to debug a crash in Avisynth?

I'm currently using a script that should take about 8 hours to complete. It previously crashed in places like a quarter to a third of the way through, and it just crashed at over 80% complete instead with Alpha3 (an improvement ;)). If I load the script through Virtualdub for rendering, I get "Dub/IO-Video error: (Unknown) (80004005)," and if I render the script to .avi through AvsPMod, it just suddenly skips to "Done" as if it finished (but the file isn't complete). Is there another way to run Avisynth that will give me more information about what's causing the crash?

Thanks for both your advice and your hard work! :)

[Wilbert]

And yes the code probably should check for ChromaInPlacement == ChromaOutPlacement, it currently relies on the resizer core to detect a null operation however the frame will still be plane split and reassembled so cost a needless set of blits.
Ok, i see what you mean. Second attempt:


AVSValue __cdecl ConvertToYV12::Create(AVSValue args, void*, IScriptEnvironment* env)
{
PClip clip = args[0].AsClip();
const VideoInfo& vi = clip->GetVideoInfo();

if (vi.IsYV12()) {
if (!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5])
return clip;
}

if (vi.IsYUY2() && !args[3].Defined() && !args[4].Defined() && !args[5].Defined()) // User has not requested options, do it fast!
return new ConvertToYV12(clip,args[1].AsBool(false),env);

return ConvertToPlanarGeneric::CreateYV12(args,0,env);
}



@Mini-Me,
The new release has unfortunately not solved my crashes, so a question occurred to me: What's the best way to debug a crash in Avisynth?
Could you simplify your script as much as possible (retaining the crash) and post it?

[Gavino]

Thanks for all your work on the new release, Ian.

if (vi.IsYV12()) {
if (!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5])
return clip;
}
You've got a misplaced bracket there. ;)
I think you mean
if ((!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5]))

[pbristow]

Where can I find an up-to-date list (preferably with definitions, not just the abbreviations) of the colourspaces that are support by this release? I've found various posts that talk about what colourspaces are/were intended for Avisynth 2.6 and for 3.0, but I'm getting a confused picture of what's been implemented so far.

I know 2.6 has the YV16 (Like YV12 but the chroma is only halved in one dimension) and YV24 (chroma is full resolution) variants. What else? Do we have ways of storing 12 bit or 16 bit luma yet (plus the core filters to work with it, of course)?
I've been shying away from trying the development/alpha versions, but if 2.6.0.2 has the colourspaces I want to work in then I'll take the plunge! :)

[Mini-Me]

@Mini-Me,

Could you simplify your script as much as possible (retaining the crash) and post it?

I can post it, but simplifying it while retaining the crashes would probably be quite difficult. It calls a function that uses [G]ScriptClip recursion, and along with all of its helper functions, it's over 350 lines long. (A lot of the lines are comments, but taking those out before posting would probably be unwise.) The crashes seem to have a direct relationship with the complexity and amount of work done. I could strip out some features (effectiveness ;)) and robustness and bring it down to the core algorithm, and it might still crash, but it would probably take a lot longer and require a clip the length of The Ten Commandments movie (and it already takes hours of peaceful and effective operation before it suddenly fails). Would you still be interested in seeing it as-is?

I have another script that crashes in the same way, but it's just as long and probably more complex. Some months ago, I was getting crashes with simpler and non-recursive (but more numerous) [local] [G]ScriptClip functions, but the total combined length of the functions was similar.

[Wilbert]

Where can I find an up-to-date list (preferably with definitions, not just the abbreviations) of the colourspaces that are support by this release?
See http://avisynth.org/mediawiki/ConvertToRGB or http://avisynth.org/mediawiki/Filter_SDK/Data_storage .

Do we have ways of storing 12 bit or 16 bit luma yet (plus the core filters to work with it, of course)?
Nope to both questions.

@Gavino, yes thanks. I probably looked at vba too long where you don't need all those brackets.

[Wilbert]

@Gavino,

I merged a post of you (thread consisting of one post) in this thread: http://forum.doom9.org/showthread.php?p=1394689#post1394689 . Is that issue still relevant?
For some time, I have been puzzled (and mildly annoyed!) that using a run-time function like AverageLuma outside of a run-time filter (ScriptClip, etc) produces the error "Invalid arguments to function ...", especially when the source code contains logic to produce the more helpful "This filter can only be used within ConditionalFilter". So I decided to investigate properly.

The reason the more helpful (and presumably intended) message is not produced is that the code (in AveragePlane::AvgPlane and elsewhere) looks like this:
AVSValue cn = env->GetVar("current_frame");
if (!cn.IsInt())
env->ThrowError("Average Plane: This filter can only be used within ConditionalFilter");
However, if current_frame does not exist (the usual case outside the run-time environment), GetVar will throw a NotFound exception and the error-checking code will never be reached. The exception is propagated back to the parser, which is evaluating the original call to AverageLuma (etc), where it sees this as an inability to call and reports it as "Invalid arguments".

The solution is to use the exception-protected GetVar from conditional_reader.h instead of env->GetVar to read current_frame (in 4 places in conditional_functions.c). At the same time, the error message could be changed to refer to "run-time filters" instead of specifically to ConditionalFilter (which I suspect was the only one that existed when this code was written).

[Gavino]

@Gavino,

I merged a post of you (thread consisting of one post) in this thread: http://forum.doom9.org/showthread.php?p=1394689#post1394689 . Is that issue still relevant?
It's fixed now (by IanB in revision 1.10 of conditional_functions.cpp).

[IanB]

In general the construct (args[3] == args[5]) never expresses a useful intent. In most cases you should be comparing the contents of the AVSValue, i.e. (args[3].AsInt() == args[5].AsInt()).

In the case here to get Wilberts intent and avoid the redundant blits it would be :-
... (getPlacement(Arg[3].AsString(0)) == getPlacement(Arg[5].AsString(0)))




@Mini-Me,

You need to post your script so we can get some idea what your issue might be. As this is a long standing problem that spans multiple version you probably should start a new thread to discuss this problem in detail. A first initial guess given things fall out of the sky without an Avisymth exception report of some sort is you are exhausting the process address space. Reporting an error does need some free memory. Monitor the process virtual memory size, if it is growing and over 1.5GB then that is a very strong indicator.


@pbristow,

At the script level there is currently YV24, YV16, YV12 and YV411 as YUV tri-planar formats.

The core is currently capable of handling any planar format with 1, 2, or 4 times subsampling independently in horizontal and vertical directions, you just can't script it yet.

[pbristow]

Thanks, Wilbert and Ian. In other words, "we're getting there, be patient", eh? :)

[EDIT:] Ah, hang on... To clarify, Ian, do you mean the core can now handle any planar format *in any (likely) bit depth*? Or is it restricted to 8-bit components? (Colour subsampling doesn't worry me so much, as I find YV12 adequate for almost everything on that score - Although it's good to know that other options are available when required.)

[Mini-Me]

@Mini-Me,

You need to post your script so we can get some idea what your issue might be. As this is a long standing problem that spans multiple version you probably should start a new thread to discuss this problem in detail. A first initial guess given things fall out of the sky without an Avisymth exception report of some sort is you are exhausting the process address space. Reporting an error does need some free memory. Monitor the process virtual memory size, if it is growing and over 1.5GB then that is a very strong indicator.
Thanks, Ian. I knew that crashes span multiple versions, but I wasn't sure if I was experiencing a typical issue or an unusual one. Looking at the virtual memory, I have a script less than two hours in that's currently at 950,000 KB and growing...growing...so I'm pretty sure you're right. It's just continually allocating memory and rarely releasing anything. (It ended up crashing at 1,199,420 KB.) Is continuous memory growth by design, due to a memory leak in Avisynth, or specific to certain scripts (in which case I should start another thread as you suggest)?

Before I start a new thread and thrust a gargantuan script upon people (perhaps needlessly), I should ask: How does SetMemoryMax behave with a single Avisynth instance? If I set a limit, would that just make it crash faster, or would it compel Avisynth to try recycling its own resources?

[IanB]

@pbristow,

Yes 8 bit only. I have been reserving bit positions and fleshing out constants definitions in the 2.6 API in anticipation for supporting 16 and 32 bit data elements in a future version, but there is no associated code yet and no data format definitions.


@Mini-Me,

SetMemoryMax only sets the size of the frame buffer cache. It is independent of any other memory allocation. Memory usage due to the frame cache should ramp up pretty quickly to the limited value and stay there. Setting a lower SetMemoryMax value will make more memory available for other purposes and provide less cache buffer frames. It is pointless having more buffers available than are needed by the scripts temporal requirements. If each and every frame generated at each and every stage of a script is only ever used once then the cache is entirely useless. By definition a cache is only useful if a generated element is needed a second or subsequent time.

[StainlessS]

Not sure where I should post this.
Had problem with MergeChroma(c1,c2,weight=1.0) as in 2.58 documentation.
Looked in Avisynth source, there is no "weight" arg, should be
"LumaWeight" for MergeLuma() and "ChromaWeight" for MergeChroma().
Installed the new Alpha 3 and checked docs, still the same, needs
amending for next issue.

[Wilbert]

Had problem with MergeChroma(c1,c2,weight=1.0) as in 2.58 documentation.
Looked in Avisynth source, there is no "weight" arg, should be
"LumaWeight" for MergeLuma() and "ChromaWeight" for MergeChroma().
Installed the new Alpha 3 and checked docs, still the same, needs
amending for next issue.
Thanks for your report. I will correct the documentation.

[Gavino]

Thanks for your report. I will correct the documentation.
I think it would be better (and more consistent) to change the code instead, and use 'weight' for all three Merge filters. I know it would not be backwards compatible, but in practice it's unlikely to cause great problems to anyone.

[StainlessS]

I think it would be better (and more consistent) to change the code instead, and use 'weight' for all three Merge filters. I know it would not be backwards compatible, but in practice it's unlikely to cause great problems to anyone.

Absolutely, that had occured to me but dismissed suggesting it.
No-one seems to have noticed it before, so change it to the
more sensible and less demanding and more obvious
choice

[IanB]

Yes it makes more sense to just use "Weight" everywhere, I will add some aliases to the Merge_filter AVSFunctions to match the doco and maintain legacy compatibility.

[Mounir]

Question for IAnB:
Does this alpha version convert correctly YV12 to YUY2 and perhaps RGB >YV12 aswell ?
See the related Chroma shift topic here (http://forum.doom9.org/showthread.php?t=147629&page=2)

Edit:
Oh yeah before i do something wrong, all the filters work with the v2.6 or should i keep the v2.58 in case ?

Also i have a problem with mediacoder (not your concern i know) it seems it don't support avisynth 2.6 (it can't decode a simple script) What software do you recommend (with v2.6 support) so i can encode in x264, thank you

[Chikuzen]

What software do you recommend (with v2.6 support) so i can encode in x264, thank you
x264CLI completely supports the features of avs2.6 at present.

[IanB]

Question for IanB:
Does this alpha version convert correctly YV12 to YUY2 and perhaps RGB >YV12 as well ?
See the related Chroma shift topic here (http://forum.doom9.org/showthread.php?t=147629&page=2)
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.

Edit:
Oh yeah before I do something wrong, all the filters work with the v2.6 or should i keep the v2.58 in case ?
2.6 is intended to be a pure superset of 2.58, all 2.58 scripts should work identically under 2.6 (bug fixes excepted :D ) Of course under 2.6 you can do 2.6 things, e.g YV24, YV16, etc, that are not supported under 2.58.

Also I have a problem with mediacoder (not your concern i know). It seems it doesn't support avisynth 2.6 (it can't decode a simple script) What software do you recommend (with v2.6 support) so i can encode in x264, thank you
As long as your script outputs a 2.58 colour space, i.e. RGB24, RGB32, YUY2 or YV12, then is should work. The interfaces have not changed, they have only been extended.

VirtualDub supports YV24, YV16 and Y8 formats. Older versions have the chroma plane order reversed. Global OPT_VDubPlanarHack=True can be used to work around the problem.

[StainlessS]

[I][B]
Also i have a problem with mediacoder (not your concern i know) i'ts seems it don't support avisynth 2.6 (it can't decode a simple script)

Have just installed the update to Mediacoder:-
MediaCoder2011-update-5158.exe and just did a short test
render via Avisynth 2.6 Alpha 3, with no real problem. I dont
like feeding AVS directly into Mediacoder (lately), as it seems
to always detect the AVS as Interlaced and you get a log entry
saying something like:

"x264 [Warning]: interlace + weightp is not implemented"

in the console (press F6). If the AVS does nothing other
than AVISource(), you still have an interlaced detection, but
if you feed the same clip in directly, it correctly finds it to
be progressive.

If you have recently installed an update, perhaps you did as I
did and canceled an x264 download, if so then you may find
that there is no x264.exe in your codecs directory as MC
directly overwrites the file, you would get an error 14 and
a redirect to the damn website to see what that means.

MC has had a LOT of problems of late, always a good idea to
have a known working version, all MC versions for about a
year (I think) are not considered stable. Try the Last stable
release.

[Mounir]

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.

So the convertions are internal no need of the script now if i understand you correctly we're back to regular converttoyv12() etc...Please confirm

[IanB]

@Mounir,

Why don't you test it and then let everybody know the results. As I said the intent is yes!

[Mounir]

Have just installed the update to Mediacoder:-
MediaCoder2011-update-5158.exe and just did a short test
render via Avisynth 2.6 Alpha 3, with no real problem. I dont
like feeding AVS directly into Mediacoder (lately), as it seems
to always detect the AVS as Interlaced and you get a log entry
saying something like:

"x264 [Warning]: interlace + weightp is not implemented"

in the console (press F6). If the AVS does nothing other
than AVISource(), you still have an interlaced detection, but
if you feed the same clip in directly, it correctly finds it to
be progressive.


I have no such problem i'd say it's the opposite i'm struggling to make an interlaced encode because mediacoder always want a progressive source.

Anyways, i've updated avisynth and mediacoder, it seems to be working ok for now

[upyzl]

Many thanks!!

I'm very glad to see there's update for this!!!

[leeperry]

Is there any way to get >8bit video processing in Avisynth 2.6?

Why are plugins coders forced to use kludges to get 16bit out of 2.6? :(

[Wilbert]

Is there any way to get >8bit video processing in Avisynth 2.6?

Why are plugins coders forced to use kludges to get 16bit out of 2.6?
You are acting like your nick. In case you didn't notice it there is only one main developer doing all the hard work. Limited 16 bit video processing is reserved for one of the future versions of AviSynth. If we add it now there will be never a stable 2.60 version.

[leeperry]

16 bit video processing is reserved for one of the future versions of AviSynth.
Well, it'd be like audio software working in 16int internally(instead of 32/64fp)....but ok, good to know that 16bit support is on the TODO list indeed :)

I wasn't being sarcastic, or anything like that....merely asking a simple question :o

[poisondeathray]

.tif images seem to be flipped vertical with ImageSource() or ImageReader() in 2.6 alpha 3

-Doesn't occur with 2.6 alpha 2, or 2.58, or 2.57

-occurs in avspmod preview and vdub preview (so less likely an avsp bug)

-other image formats like .jpg, .png are decoded ok , but when converted to .tif they are flipped

-doesn't matter if it's ".tiff" or ".tif" , both are flipped

-seems independent of odd/even resolution (e.g. 427px width image vs. 428px width image)


or is it just me ? I can upload some sample images, but it's pretty easy to replicate this behaviour on random images

[Wilbert]

-other image formats like .jpg, .png are decoded ok , but when converted to .tif they are flipped
..
or is it just me ?
No, i can replicate that. We changed this when adding support for DevIL 1.7.8. It seems that with the included library (devil.dll 1.6.6) it is flipped, and with the latest library (devil.dll 1.7.8) it's not flipped. That's annoying.

@IanB, the following should correct it

/* old:
if ( !lstrcmpi(ext, "jpeg") || !lstrcmpi(ext, "jpg") || !lstrcmpi(ext, "jpe") || !lstrcmpi(ext, "dds") ||
!lstrcmpi(ext, "pal") || !lstrcmpi(ext, "psd") || !lstrcmpi(ext, "pcx") || !lstrcmpi(ext, "png") ||
!lstrcmpi(ext, "pbm") || !lstrcmpi(ext, "pgm") || !lstrcmpi(ext, "ppm") || !lstrcmpi(ext, "tif") ||
!lstrcmpi(ext, "tiff") || !lstrcmpi(ext, "gif") || !lstrcmpi(ext, "exr") || !lstrcmpi(ext, "jp2") ||
!lstrcmpi(ext, "hdr") )
{
should_flip = true;
}
*/

if ( !lstrcmpi(ext, "jpeg") || !lstrcmpi(ext, "jpg") || !lstrcmpi(ext, "jpe") || !lstrcmpi(ext, "dds") ||
!lstrcmpi(ext, "pal") || !lstrcmpi(ext, "psd") || !lstrcmpi(ext, "pcx") || !lstrcmpi(ext, "png") ||
!lstrcmpi(ext, "pbm") || !lstrcmpi(ext, "pgm") || !lstrcmpi(ext, "ppm") || !lstrcmpi(ext, "gif") ||
!lstrcmpi(ext, "exr") || !lstrcmpi(ext, "jp2") || !lstrcmpi(ext, "hdr") )
{
should_flip = true;
}

if ((DevIL_Version > 166) && (!lstrcmpi(ext, "tif") || !lstrcmpi(ext, "tiff")))
{
should_flip = true;
}


When calling ImageSourceAnim there should be a version check too.

[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.