AviSynth 2.6.0 Alpha3 [May 25th, 2011]

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