Avisynth+

[ultim]

So basically, I can't count on any of the interface improvements made in 2.6. "Great." I can always use wrappers for any kind of 3rd, 4th, 5th interface, but that would still mean keeping around old code, except maybe in its own module. Not to mention now I'd even have to make sure the "glue" logic also works. So thanks, but no. In this case I'll rather continue what I was doing sticking to 2.5-style, and devise *one* new interface for Avisynth+ in the future, when the more important stuff are out of the way, and I can make sure that it will finally be alright. I am not in the mood of maintaining 4+ (redundant!) interfaces, and I don't think I ever will be. But to avoid misunderstandings, plugins should of course still use the 2.6 header. There is currently nothing better than that, as it is most feature complete, and does not suffer from the "baked code syndrome".

... General refcounting is done by scheduler based on 2, wrapper can do additional refs in response to 2.5 frame refs, but I guess it won't be used much.
Refcounting is nice and I would want to use it myself, but I really think I can't because of 2.5 baked code. You can supply the cleanup logic in the users of the frame classes instead of in the frame class, sure, so you could think that might work as long as the core always has the last reference to any frame, instead of the filters. The problem is, how will you know when the refcount reaches zero? The baked-in code won't tell you, so you are left with the choice of either periodic scanning, or with the choice of scanning only when needed, for example on out of memory, which is what current Avisynth does.

You say that we can do refcounting our own way however we want, and provide a wrapper for 2.5 plugins. That means we still have to duplicate the extremely complex old-style Avisynth caching, except in a wrapper, but in addition we must also develop and maintain a second caching system, the primary one?! This is just not worth it, because the old cache basically works. Yes it is way too complex for what it does. Yes it eats memory. But it works and it is not a performance bottleneck. So what reason is there to develop a completely new one if we still have to continue living with all the drawbacks of the current cache, except in a wrapper?

[SEt]

2.6 interfaces are useless – they solved nothing while breaking binary compatibility, usage is very low. I'd say implement only 2.5 compatibility.
New interface obviously needs to be the only one and extensible. Btw, this implies that it must be C style and not the C++ hell like now. For exact design I'd say COM-like: great scalability and linking compatibility.

As for wrapper complexity – it greatly depends on which and how efficient you want it to support quirks of 2.5. Sure, maybe 2.5 plugin that formatted your hard drive would require total emulation to work correctly, but do we care? I suspect that quite simple wrapper + some special cases would be ok for most interesting plugins.

And FTY, caching is the main problem of Avisynth MT. Not threading hacks, not 32-bitness how quite a few people think. And it is performance bottleneck.

[ultim]

2.6 interfaces are useless – they solved nothing while breaking binary compatibility, usage is very low. I'd say implement only 2.5 compatibility.
New interface obviously needs to be the only one and extensible. Btw, this implies that it must be C style and not the C++ hell like now. For exact design I'd say COM-like: great scalability and linking compatibility.

As for wrapper complexity – it greatly depends on which and how efficient you want it to support quirks of 2.5. Sure, maybe 2.5 plugin that formatted your hard drive would require total emulation to work correctly, but do we care? I suspect that quite simple wrapper + some special cases would be ok for most interesting plugins.

And FTY, caching is the main problem of Avisynth MT. Not threading hacks, not 32-bitness how quite a few people think. And it is performance bottleneck.

Well I'm rewriting caching and memory management from scratch anyway. Coz I agree that current cache doesn't lend itselft to MT naturally. In single-threaded mode though it didn't seem like a bottleneck, as it didn't even show up in profiling results.

I also agree that new interface needs to be C-style. My plans are to make it object oriented (as far as C allows), but keep objects totally opaque. An extremely thin C++ wrapper shipped as public include files will provide C++ binding, but it will only provide syntax sugar and some help in memory management thanks to destructors.

[ryrynz]

That have been said, I'm busy with other areas atm. (And you will likely see something useful for Avisynth in several days. ;))

What is it?

[ultim]

You have probably noticed that this release of Avisynth+ is taking longer than previous ones. The good news is that not because we are stalling, but because the features we are working on are a lot larger, and also a lot more complex.

Other good news is that people have started joining in on the project. TurboPascal7 and innocenat have been working on bringing you full-fledged 64-bit functionality, qyot27 has already sent a pull request to give you a nice automated installer, and I myself am introducing multi-threaded processing.

So, look forward to the next release!

[turbojet]

Looking forward to 64 bit and multithreading. A few questions:
1. Will the installer be able to extract the dll's with 7zip?
2. Will the dll package still be available?
3. At some point in the future, would JincResize (from madvr) be considered?

[innocenat]

3. At some point in the future, would JincResize (from madvr) be considered?

I have been considering adding Jinc support (as I also want them), but I have trouble finding reference to this filter. I'd be grateful if someone could link a nice explanation of how this filter works.

[turbojet]

There was a lot of talk about it in the madvr thread last year. I believe it's based on: http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=21415 there's some code on page 2 and maybe more in later pages. This might be part of it: http://forum.doom9.org/showthread.php?p=1595043&highlight=sigmoid#post1595043

But only madshi and maybe NicolasRobidoux would really know.

[Keiyakusha]

For Jinc, you also need madshi's anti-ringing, it sux without it.
Also if someone is going to implement it, it will be cool if needed calculations can be done in GPU. Unless it'll be comparable to spline36 by speed. Cause if it'll be slow, one could just go with nnedi/eedi+subpixel shift(if desired) and get better results. And Jinc is also not something you're going to use for downscale.

It could be way simpler if madshi could just turn that part of his renderer into a plugin (even if closed-source).

[TurboPascal7]

Moving stuff to GPU and back is not worth it if resizing is the only thing you're going to do. So no, this is not going to work.
Also, fmtconv might get ported to avisynth some time in the future. We might as well wait for it before spending our time on something that might end up replaced by fmtconv.

[Keiyakusha]

There were examples of gpu resampling in avisynth and they worked quite well (old and not compatible with recent avisynth versions). I imagine today with better gpus and better drivers it'll be fine too. I guess one should try some simple resampling and see how it goes.
Edit: of course it is probabably pointless for something like bicubic, but JincAR is gonna be slowest resampling yet.

[TurboPascal7]

It's not like you can't implement a GPU resizer in avisynth, it's that performance improvement you might get out of it is not worth it in most cases unless your resizer is really complex and slow to do on CPU. I don't think it's a good idea to include slow filters like that into the core.

Things might change if avisynth suddenly becomes GPU-aware, but I'm not aware of any efforts/plans in this area.

[Keiyakusha]

The thing is, I don't care about GPU that much, but rather...
All filters can be roughly divided into 2 groups: fast, average speed - your "go to" filters and slow filters - when you don't care about speed but want to get the most out of it. If it'll turn out that Jinc+AR falls into the second group, there will be no reason to prefer it over nnedi. But at this point probably no one except madshi can estimate possible speed. Maybe even madshi doesn't know, unless he tried to implement it in CPU 1st. On the other hand, unlike nnedi, it was proven that JincAR can be done in GPU and works quite nice. This is where my "make use of GPU" idea comes from. Plus this way madshi probably will be able to give better assistance.

[ultim]

Looking forward to 64 bit and multithreading. A few questions:
1. Will the installer be able to extract the dll's with 7zip?
2. Will the dll package still be available?
3. At some point in the future, would JincResize (from madvr) be considered?

1. Not sure what you mean. Probably no, but cna you clarify?
2. Haven't decided yet. Is there any use to a zip if you can update an existing installation by just simply installing over it?
3. I won't work on it personally, if anyone is interested in porting it to Avisynth though, that'd be cool.

[ultim]

The thing is, I don't care about GPU that much, but rather...
All filters can be roughly divided into 2 groups: fast, average speed - your "go to" filters and slow filters - when you don't care about speed but want to get the most out of it. If it'll turn out that Jinc+AR falls into the second group, there will be no reason to prefer it over nnedi. But at this point probably no one except madshi can estimate possible speed. Maybe even madshi doesn't know, unless he tried to implement it in CPU 1st. On the other hand, unlike nnedi, it was proven that JincAR can be done in GPU and works quite nice. This is where my "make use of GPU" idea comes from. Plus this way madshi probably will be able to give better assistance.

Briefly flying through what's in the first post of here (http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=21415), the nice thing is it looks like you could implement the filter on the GPU without any of the CUDA or OpenCL GPGPU BS. Possibly all you need is OpenGL with GLSL and FBO extensions. As a result you could use the filter even on older HW, without any special drivers or dependencies, and even be portable to Linux. My investigations will stop here though, and Turbo is right that a GPU implementation might not pay off due to bouncing textures on and off the GPU.

[Keiyakusha]

Briefly flying through what's in the first post of here (http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=21415), the nice thing is it looks like you could implement the filter on the GPU without any of the CUDA or OpenCL GPGPU BS. Possibly all you need is OpenGL with GLSL and FBO extensions. As a result you could use the filter even on older HW, without any special drivers or dependencies, and even be portable to Linux. My investigations will stop here though, and Turbo is right that a GPU implementation might not pay off due to bouncing textures on and off the GPU.

I see. In other words, it is better just leave it alone and do something else. Because GPU implementation might not pay off due to bouncing textures, CPU implementation might not pay off due to nnedi being much better choice.
BTW that discussion you link to is TL;DR but I think it does not includes anti-ringing which is something madshi made on his own. Also I remember madshi was saying something that he tried to implement sigmoidal algorithm but didn't liked it, so his Jinc might be something a bit different.

[ryrynz]

Would it be easy to allow for filters that currently work only on YV12/NV12 to work with PO10? And if that was the case, would anyone be willing to hack ffdshow a bit to allow untouched 10bit frame serving
for the processing of that content? Perhaps even a ffdshow raw replacement for interfacing with Avisynth so that 10bit content can be enhanced without any color space conversion?

[qyot27]

Looking forward to 64 bit and multithreading. A few questions:
1. Will the installer be able to extract the dll's with 7zip?
2. Will the dll package still be available?
1. 7zip can unpack the installer, yes. It's just an update of the NSIS script that classic AviSynth uses for its installer.
2. I would wager any third-party builds would still use a non-installer-based package. So, probably?

The big caveat here is that the installer is assumed to be used by those choosing to rely only on AviSynth+, such as first-time users. It installs to %ProgramFiles%\AviSynth+ and sets the plugins and plugins+ directory targets in the registry to the ones residing in the AviSynth+ directory. This means that - unless some other solutions arise to allow classic and avsplus to coexist - you should only use the installer for either classic or avsplus, but not both. Using the avsplus installer over top of the classic one will more than likely reset the plugin directory locations in the registry and that means you'd have to move/copy the plugins over to AviSynth+'s plugins directory (and if you ever uninstalled AviSynth+, you'd have to be sure to either reinstall classic or fix the registry so it points at AviSynth 2.5\plugins again).

Currently, it cannot install both 32-bit and 64-bit versions, so separate installers for each one would be necessary unless/until a proper solution for that is found. I saw some references on StackOverflow to getting NSIS to use one installer for both, but since I don't have access to any Win64 setups I can't really do any work on that and test it (the closest is 64-bit Wine, but that still means nothing because I can't compile AviSynth+ itself as 64-bit - unless there's some CMake trick to make a Win64 target available to a 32-bit MSVC...if cross-compiling 64-bit stuff with 32-bit MSVC is even possible, that is).




One thing that I have been thinking about in regard to licensing as SEt brought up way earlier in the thread: since several parts of the AviSynth+ source code would be brand-new, I propose that anything brand-new could be put under a more permissive but still GPL-compatible license. The ISC license (http://en.wikipedia.org/wiki/ISC_license) and Expat license (http://en.wikipedia.org/wiki/MIT_License) are both popular and GPL-compatible, for instance. Arguably, the refactoring process on the old stuff might eventually render many of those parts completely rewritten and open to relicensing, but since IANAL I won't say anything definitive on that front.

The end result is that AviSynth+ (in binary form?) would still be distributed under the terms of the GPL (with the plugin linking exception intact), but at least on those brand new parts, it could encourage more source contribution from those that would otherwise not because of the GPL.

[TurboPascal7]

Would it be easy to allow for filters that currently work only on YV12/NV12 to work with PO10? And if that was the case, would anyone be willing to hack ffdshow a bit to allow untouched 10bit frame serving
for the processing of that content? Perhaps even a ffdshow raw replacement for interfacing with Avisynth so that 10bit content can be enhanced without any color space conversion?

No, it won't be easy.
No, no one will be hacking ffdshow since the project is dead. We do have a few ideas about avisynth in directshow, but that will wait.

Oh and I agree on the license part.

[qyot27]

Would it be easy to allow for filters that currently work only on YV12/NV12 to work with PO10? And if that was the case, would anyone be willing to hack ffdshow a bit to allow untouched 10bit frame serving
for the processing of that content? Perhaps even a ffdshow raw replacement for interfacing with Avisynth so that 10bit content can be enhanced without any color space conversion?
I imagine that high bit depth support in general is a long-term goal, and most likely will emerge as 16-bits first, and then fill in with the in-between pixel formats later. Trying to specifically hack 10-bit support into the current codebase is probably not feasible, and anything described as a hack is certainly not desirable.

[ultim]

The big caveat here is that the installer is assumed to be used by those choosing to rely only on AviSynth+, such as first-time users. ...

true, but when i get near a release, i will try to modify the installer to:
- prevent installation if it detects classic avisynth already installed, and give meaningful instructions to the user.
- install both 32- and 64-bit versions (on a 64-bit OS)
- install the required vc++ runtime unattended if needed

qyot's work is a very good start on an avs+ installer, and even if none of the above points get realized right now, his installer can still be used to make releases. but i will try to implement my points soon based on his work, coz i find them important for a seamless user experience.

my experience lies in Wix rather than in NSIS though, so someone more experienced with NISIS could probably do it in half the time than me. any volunteers?

[ultim]

the licensing issue might be worth its own topic. it's a complicated thing, both in practice, both legally, and both in reaching a consensus between all past contributors. i'm all for changing the license, but it only makes sense if we can do it legally properly. otherwise there is little point in having one at all.

[turbojet]

Extractable installer makes standalone dll package not very useful, at least for me. The reasoning behind it is portability or being able to use/update avisynth without admin rights.

Nnedi is limited to multiples of 2 resizing, which doesn't make it a replacement for a general resizer. While it's subjective I think Jinc performs just fine without anti-ringing, imo it's does a better job of detail retention. I can't find it now but in another thread I had asked madshi about Jinc downsizing and he said it could be effective just not implemented. I'm not sure it would be more effective than lanczos when encoding however, during playback lanczos seems to be stay closer to the source.

DGNV's gpu resizing is very fast but I believe it's baked in cuda code and limited to bilinear. It would be interesting to see if a resizing is faster with gpu pixel shaders or cpu.

[innocenat]

I agree that license is complicated thing, and while many parts of avs+ are rewritten and could be put under, say , LGPL, many part also don't. At least on core filter I have been working on, the C++ files are rewritten but header file mostly remain the same. And it's very hard to track which piece of code are written by whom.

[ultim]

I see. In other words, it is better just leave it alone and do something else. Because GPU implementation might not pay off due to bouncing textures, CPU implementation might not pay off due to nnedi being much better choice.

Well it depends on if you are willing to take the risks. Ofc a GPU implementation will be faster if the time lost by copying textures over the buses is a lot smaller than the time won by the GPU processing. If the filter it very slow, than GPU processing will probably still be a good choice. But this means whether it is worth it or not also depends on the difference in speed between your CPU and GPU. It is well posisble that someone with a slow-ish CPU but modern GPU will see a huge benefit, while another guy with a fast CPU but non-gaming (or old) GPU will be hurt by GPU processing.

I agree that license is complicated thing, and while many parts of avs+ are rewritten and could be put under, say , LGPL, many part also don't. At least on core filter I have been working on, the C++ files are rewritten but header file mostly remain the same. And it's very hard to track which piece of code are written by whom.
Exactly. Even if large parts have been rewritten, it is not practical to change the license without permission from previous authors, because without permission, we'd have to track every line which license applies for that particular line number.

On the other hand, the current "GPL+public header exception" is practically the same as the accepted interpretation of the LGPL, so we might be able to pull that change off. It will only work with LGPL though, not with other licenses like MIT. Also note that the 2.6 header is not under the exception right now.

To summarize, trying to get ALL the code under LGPL could be possible, but we'll need other opinions on the matter than just mine, coz I'm not sure if even that is okay. Any other target license surely requires getting in contact with all the previous contributors.

[TurboPascal7]

I'm perfectly fine with LGPL or any other more permissive license, if that matters.

[malmsteen81]

hi, with avisynth+ can i use the filter without setmode's istruction (for multi thread)? right?

[ryrynz]

Avisynth+ is not multithreaded yet, there are no MT modes.

[andybkma]

Greets, can Avisynth+ also be used for realtime script post processing with ffdshow raw filter? Reason being, I swapped out the dll file with the + version and now I get a conflict with mVR which didn't happen before when using the "official" 2.6.0 Alpha 5 avisynth.dll file.

The problem is that I get an error code: "madVR reports: resetting Direct3D device failed 8876017c" when coming out of mVR Fullscreen Exclusive Mode back into window mode after playing a video in FSE for more that 10minutes or thereabouts. Not sure what the cause is, all I know is that it happens when using the avisynth+ dll file and not with the official. Just thought I would let you know. Cheers

AviSynth+ 2013.10.16 + mVR Deband 14 version

[qyot27]

A couple of suggestions for the plugin writing tutorials and/or general explanation about the core: an explanation of what needs to be considered in order to support 64-bit properly, and how to deal with the topic mentioned above with moving to being high bit depth aware (also if relevant to the HBD discussion, anything about adding new pixel formats and/or colorimetries). I'm certainly interested in knowing what the nuts-and-bolts of these are, even if only for educational purposes.

[ultim]

Greets, can Avisynth+ also be used also for realtime script post processing with ffdshow raw filter? Reason being, I swapped out the dll file with the + version and now I get a conflict with mVR which didn't happen before when using the "official" 2.6.0 Alpha 5 avisynth.dll file.

The problem is that I get an error code: "madVR reports: resetting Direct3D device failed 8876017c" when coming out of mVR Fullscreen Exclusive Mode back into window mode after playing a video in FSE for more that 10minutes or thereabouts. Not sure what the cause is, all I know is that it happens when using the avisynth+ dll file and not with the official. Just thought I would let you know. Cheers

AviSynth+ 2013.10.16 + mVR Deband 14 version

Hi!
Yes, Avisynth+ should work fine for that, just like Avisynth did. In fact, I'm often using MPC-HC+ffdshow raw renderer for my own visual tests, so I know for sure you can use it that way for real-time processing. The only difference is I'm not using madVR, but I don't see yet how the changes in Avisynth+ compared to classic Avisynth could cause a Direct3D issue with the renderer.

If you are really sure it is caused by Avisynth+, I'll try to reproduce it when I finish working on threading, then I'll be able to tell more. Until then can you please enter it as a bug report on GitHub so that I won't forget it?

[Myrsloik]

I have a small avisynth.h change request. Feel free to ignore it if you're not going to break the ABI when going 64bit.

Would it be possible to extend VideoFrame:: offset, offsetU and offsetV to be a 64 bit type (such as ptrdiff_t)?

This would make wrapping to VapourSynth internals possible for the 64 bit ABI.

[ultim]

I have a small avisynth.h change request. Feel free to ignore it if you're not going to break the ABI when going 64bit.

Would it be possible to extend VideoFrame:: offset, offsetU and offsetV to be a 64 bit type (such as ptrdiff_t)?

This would make wrapping to VapourSynth internals possible for the 64 bit ABI.

Hi, I have already wanted to make such and similar changes on many occasions, but I resisted, because I really want to keep full ABI compatiblity to existing 64-bit plugins. When the interfaces get updated though, you can be sure that the new interface will use such types. But not in avisynth.h though.

[osgZach]

I have to say I commend your dedication to this effort and I wish you lots of success. I will be watching this (fork?) with interest.

[Jeroi]

So last post was not funny enough, Ultim I am referencing to your desire of modernize the Avisynth into new era so since AVI is kinda oldish video container format (who uses it anymore?) why not Ultim change your Avisynth+ name into more modern name Like Videosynth or Mediasynth or let say Mediaframer or similar more universal name for supporting more modern HD video container formats and the age we live in 2013 where no AVI's anymore?

[Guest]

So last post was not funny enough, since AVI is kinda oldish video container format (who uses it anymore?) why not Ultim change your Avisynth+ name into more modern name Like Videosynth or Mediasynth or let say Mediaframer or similar more universal name for supporting more modern HD video container formats? It's a fork of Avisynth, hence the name. And BTW Avisynth supports modern HD container formats quite fine.

[Jeroi]

It's a fork of Avisynth, hence the name. And BTW Avisynth supports modern HD container formats quite fine.

You obviously missed the point hence there where that reference call in that last post.

[ryrynz]

Could we not continue with this discussion please?

[andybkma]

If you are really sure it is caused by Avisynth+, I'll try to reproduce it when I finish working on threading, then I'll be able to tell more. Until then can you please enter it as a bug report on GitHub so that I won't forget it?

Yep, definitely sure as I just reproduced it again. Don't know what a github is though I am sure if the bug is important to you you won't forget about it ;-)

[StainlessS]

I dont know what a github is either but, see here, https://github.com/pylorak/avisynth

looks like you need to access 'issues' on Right Hand Side of page to give a bug report.

[StainlessS]

Although if you go to above link and click on "New Issue", you get a "404, This Is Not The Page You Were Looking For"
type error message, ie it dont work.

[ajp_anton]

Feature request: allow comments on split lines, like this:
filter(argument 1 #comment
\, argument 2)Another closely related request:

Example:

function1()
#\.function2()
\.function3()

allow commenting out the middle line for easy temporary removal of the middle function. /**/ commenting just isn't very practical...
The previous request would allow for a
\#.function2()
comment, but commenting out the full line including the \ would make life even better =).

[ultim]

Yep, definitely sure as I just reproduced it again. Don't know what a github is though I am sure if the bug is important to you you won't forget about it ;-)

I entered it into the bugtracker: https://github.com/pylorak/avisynth/issues/11

StainlessS: @404, That's becasue you weren't logged in?

ajp_anton: Got it, it will be handled together with your previous request.

[StainlessS]

StainlessS: @404, That's becasue you weren't logged in?


Thank you Ultim.
I actually tried it to see if you needed to be register to give bug report, the 404 made me think that it was not a registration issue.
(EDIT: With that error code, I would not have bothered to register if wanting to report an error, as it looked pointless if the site did not work)

[TurboPascal7]

I actually tried it to see if you needed to be register to give bug report, the 404 made me think that it was not a registration issue.
(EDIT: With that error code, I would not have bothered to register if wanting to report an error, as it looked pointless if the site did not work)
Good news: this is fixed now.

[zero9999]

In preparation for the upcoming release, we are in need of a few translated strings for the AviSynth+ installer. If you want to help, please check out this pad (https://pad.riseup.net/p/gfyPtMbihf6q)

Edit: an in case you want to be credited, please leave your name here, because apparently the pad doesn't save the authors names after they close the window...

[ultim]

Hooray, we've got a couple of announcements to make. All good ones ;)

A new release
Yes we have a new release and a cool one that brings full 64-bit functionality. But here's the semi-detailed changelog.
- A small number of bugs that were regressions compared to classic AviSynth have been fixed. This includes a bitblt copy error, and a script evaluation error that made it necessary to explicitly give the „last“ clip as input to some rare filters. It was discovered on animate(), but it might not have been the only one. The 64-bit version also had non working versions of Amplify(DB), Normalize, and MixAudio, which should be fixed now.
- tp7 and innocenat have finished porting all built-in filters to compiler intrinsics. This is a truly great accomplishment not only becasue it gives us a fully working 64-bit version, but the previous assembly code (which is now gone) was a large obstacle in reaching linux/osx compatibility too. We are still not cross-platform, but their work has brought us a large step closer. Not to mention it also allowed us to get rid of the SoftWire library, which brought down the binary size by 50% (though you might not see this if you compare it to UPX'd versions). I should probably also underline how much work this has been for them, they updated like 19.000 lines of code!
- As yet another consequence of tp7's and innocenat's work, the speed of many internal filters has greatly increased, in some cases 150% or more.
- There is now a shiny new installer. After qyot27's installer update for AviSynth+, line0 brought it another step further and has rewritten the old AviSynth installer from scratch. Compared to the old installer, you not only get a nicer graphical look, but also comprehensive migration options from classic AviSynth too, as well as unified x86/x64 support. Line0 is also working on high-res icons. This is still work in progress, but you can see preliminary results in the installer's icon.

Last but not least, we give special thanks to a random stranger* (see EDIT) who has pioneered in introducing Pig Latin translations to the software world. His work is unfortunately not yet included due to purely technical reasons, but I'm sure that many will appreciate his contribution when we finally do, especially native speakers of Pig Latin.

Homepage and IRC
Also kind of important news is that AviSynth+ now has a homepage, reachable under avs-plus.net (http://avs-plus.net). It is hosted by GitHub and is a bit minimalistic right now, but for sure a better landing page than GitHub's repository dump. There is also a new #avs-plus channel on Rizon for all IRC lovers, and in addition to this forum, you are welcome to influence development of AviSynth+ there too.

And the googly master plan
… is to involve even more people in AviSynth's future. The past weeks have proven to me that I'm far from alone caring for AviSynth, but there are still quite a number of items on AviSynth+'s wish-list, so there is a little thing I'd like to do: enter AviSynth+ into Google Summer of Code (http://www.google-melange.com/gsoc/homepage/google/gsoc2014) as a mentoring organization. GSoC is a wonderful opportunity, as it would not only help in code development, but would spread the word of AviSynth, and give us even more feedback thanks to the larger exposure. I also think it is a fun and rewarding task for students to work on multimedia processing, not to mention they'd even get compensated by Google this time. So we're counting on you, whether it is ideas or volunteering for being a mentor for the project (yes we're looking for mentors, all are eligible that have previously written code or plugins for AviSynth). Also let us know if you're not wishing to get directly involved, but you've got previous experience with GSoC and got a few tips and pointers for us.

Help us spread the word, and live long and prosper.

EDIT: __ar apparently wasn't involved. So we don't know who to thank.

[Jeroi]

I just can't say more than thank you guys. In one day we may have unix native avisynth.

[Guest]

In one day we may have unix native avisynth. There already is one: avxsynth.

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

[TurboPascal7]

A few notes on the porting effort, asm and future plans.

1) Myrsloik did not lie - a lot of asm in the core was quite terrible. We actually had to remove HorizontalReduceBy2 YUY2 ISSE implementation because it was slower than the C code. There were some quite good MMX routines though (SSE2 was awful everywhere but resizers). Resizers were good.

2) As mentioned in the first pull request (https://github.com/pylorak/avisynth/pull/12), the general rule was "not slower than original on Nehalem+ CPUs". We did not test on any older CPUs. Expect performance to get a bit worse on Pentiums and I'm not sure about some memory-bound filters on Core 2. Please report if you experience a noticeable performance drop in the core filters on Core 2 level CPUs. We will not be spending a lot of time optimizing for pre-Nehalem CPUs though.

3) All filters now have C versions so you can run them on super ancient CPUs. It will also help non-x86 platform support.

4) All filters now have SSE2 versions. This for example means up to two times faster TemporalSoften. Some also got SSSE3 and SSE4.1 optimizations. You can find which one in the commit messages of the pull requests.

5) There are some behavior changes: TemporalSoften mode 1 is removed, mode parameter is simply ignored. Blur MMX parameter and Tweak SSE parameter are also ignored.

6) MMX optimization routines are dropped if there is a faster ISSE version. This affects only a few filters and some extremely old CPUs.

7) Code from FTurn (http://forum.doom9.org/showthread.php?t=168315) is now integrated into the core (with some additional optimizations and new RGB32 routines), making the plugin obsolete.

8) We did not port MMX code of any audio filters. We won't do this any time soon, feel free to contribute.

9) Resizers are implemented as VerticalResizer().Transpose().VerticalResizer().Transpose() instead of two separate routines for vertical and horizontal resizing. Some rounding differences are possible, although not noticeable. This improves performance in most test cases and simplifies implementation quite a bit.
YUY2 resizer is also implemented as ConvertToYV16().Resize().ConvertToYUY2(). This does not affect performance in any way on the CPUs we were working on. Conversion is lossless and extremely fast.

Speaking of YUY2: support of this color format will be dropped in all external filters we port. We don't have unlimited time or will to work on something that no one uses. You can always process YUY2 with planar filters by converting to YV16 and back.

Now, what next's? Our part of the team will be slowly improving useful external filters to make them work with MT and other platforms in the future. Feel free if you want to help, but please write about it beforehand so we don't end up porting the same filter twice.

Also, I'd like to hear if any of the authors are willing to update their plugins themselves. This includes future MT registration, inline asm removal and later - other platforms support.

EDIT: A note for ICL users. In our tests, ICL14 tends to generate slower code for some filters, e.g. resizers. You might want to check it before publishing any dlls (which I still recommend you NOT to do). I don't know if the same applies to older versions and I don't know what's the older version you can compile avs+ with. For VS it's vc100 right now (2010).