AviSynth 2.6.0 Alpha3 [May 25th, 2011]

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