AvsFilterNet - writing avisynth filter in .NET

[SAPikachu]

I recently wrote a wrapper for avisynth in .NET so that you can write avisynth filter in any .NET language. Hope someone will find it useful.

You can download binaries and source code here (http://www.codeplex.com/AvsFilterNet). Any suggestion is appreciated.

[tin3tin]

This looks very interesting. Would it be possible for you to write a quick "Getting-started writing avisynth plugins in .net" tutorial, for people(like me) who never worked in .net before ?

And maybe with an example of a .net/avisynth plugin script?

Anyway thank you for your work. :)

[SAPikachu]

You can see the SimpleSampleNet project included in the package. It is ported from the sample in avisynth filter SDK. There are many comments in the code, so you can use it as a starting point to create your own plugin.

[Fizick]

Thanks, added to the Wiki:
http://avisynth.org/mediawiki/Filter_SDK/SDK_necessaries#Other_compilers

[SAPikachu]

Thanks!

[rvs75]

AvsFilterNet is compatible with Avisynth 2.6 ?

[SAPikachu]

AvsFilterNet is compatible with Avisynth 2.6 ?

Not currently, it needs to be recompiled with new headers to support avisynth 2.6.

[MysteryX]

This looks very interesting.

But if it doesn't support AviSynth 2.6, what does it support? I'm looking at maybe writing something for AviSynth 2.6 MT.

OK, it doesn't load in AviSynth 2.6. It doesn't load in 2.5 either.

I was thinking it might be easy to port the SuperRes, written in .NET, to AviSynth if it could also be written in .NET.
https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Shiandow.SuperRes.cs

But since AvsFilterNet was obviously not designed for AviSynth 2.6, will there be more to do than replacing header files to get it working? Would I be seeing all kinds of incompatibility issues and bugs?

[MysteryX]

I went ahead and adapted the code for AviSynth 2.6, AviSynth+ (x86/x64) and Visual Studio 2015. I don't think any plugins were even written with this and looking at the code, AvsFilterNet was never finished. A few things were missing or done wrong; with comments in Chinese.

You can get the full source code here
https://github.com/mysteryx93/AvsFilterNet

C# can remove a lot of the complexity of plugin development. Here is the simplest LoadImage plugin on Earth (https://github.com/mysteryx93/AvsFilterNet/blob/master/SimpleSampleNet/LoadImageNet.cs): 45 lines of code.

Here are some benefits of C# plugin development.
- Simplicity of code. All the implementation complexity is handled automatically.
- The plugin creation and registration is handled automatically.
- The plugin's source code is self-contained within a single code file.
- Debugging works much better.
- C# code works for both x86 and x64 platforms.
- C# is natively cross-platform compatible and will work in Linux or MacOS if AviSynth ever support those.
- C# can benefit from CPU-specific advanced instruction sets as it compiles on-demand
- No random memory access violation issues. C# won't allow you to work with memory data outside the managed scope.
- No threading "undefined" behaviors. C# has much more thread-awareness, many objects will notify you if you violate their thread affinity and managing threads is a whole lot easier.
- No worries about releasing objects. C# uses the Gargage Collector to release memory. Microsoft determined that this resulted in about 3% performance cost and decided to migrate their whole products into using this.
- Everything regarding multi-threading and multi-processes become much simpler
- Complex tasks become a whole lot easier

Drawbacks of C#:
- To use assembly code, you must link to a C++ library containing that code.
- Raw pointer access and data manipulation remains easier with C++'s direct pointer access.

Performance-wise, this is a wrapper around the C++ functions. Besides the lack of assembly code, I think the performance cost will be minimal. As for working with data within a Stream vs using C++ pointers, the performance would have to be tested.

In terms of memory, because C# uses the Garbage Collector, the memory usage may "appear" considerably higher because it won't release the memory until it considers it needs it. Some people try to override the GC's logic but as a rule of thumb, don't try to re-invent the wheel and let the GC do its job. Just know the memory usage you see may be inaccurate.

It is built with the headers of AviSynth+ r2022 which are incompatible with previous builds of AviSynth+. There are currently some issues in MT mode and I will wait for Ultim to come out with an updated version of AviSynth+. It is working perfectly fine in single-threaded mode. In MT, the calls might not come from the thread you are expecting.

[amayra]

indeed this have issues MT mod

[MysteryX]

The MT issues I saw may simply be because I was using a class with thread affinity that cared from which thread it was being called. Without using such a class, then it might work just the same as with C++. Have to test more.

In terms of performance, often low performance doesn't come from lack of assembly code and raw execution speed, but rather from poor code structure due to a huge amount of unreadable code that piled up over time. On this point, C# wins major points. It allows for much better and simpler code structure that can be maintained a lot more easily.

I've done a lot of database applications, and the best practice for such application is to split the solution in 3 layers: UI, Business Logic and Data Access. In the same way, it would make sense to completely separate the plugin logic from the raw frame data operations. The plugin logic can be maintained and simplified in a C# project, while the raw calculations are being done in a separate layer. Such functions generally need a code splitter and several implementations: CPU, SSE2, AVX.

Separating the plugin logic from the raw operations also might be the easiest way to port the plugins to other platforms in the future. The plugin logic is cross-platform compatible, and all that needs to be rewritten is the assembly in the raw operations layer. Porting then becomes very easy. The only downside: it requires 2 DLLs instead of 1; plus AviFilterNet.dll.

That being said, the first person to develop a plugin with this may need to still fix a few bugs and/or implement a few missing features while using AvsFilterNet.

[FranceBB]

Avisynth and C#, I knew this day would have come! :')

[MysteryX]

I was worried about MT and error handling, and after testing, both are working fine. There are however a few issues left.

Version 1.0.1 is ready. (https://github.com/mysteryx93/AviSynthShader)
- Tested multi-threading and error handling. Both are working fine.
- Renamed the new Finalize function to ExecuteAfter.
- Added ExecuteBefore function with CancelLoad parameter.
- If CancelLoad is specified during ExecuteBefore, the filter will be discarded and other filters can be executed instead.
- env.Invoke can now take null as arguments parameters.
- Added generation of intellisense documentation.
- Fixed env2.GetProperty by adding managed enumeration.
- Added InterProcessNet sample which performs a frame operation in a different process.

Known issues:
- ExecuteBefore result will be ignored; calling SetChild with its result causes an infinite loop with SetCacheHints
- LoadPluginNet must point to a path known to the assembly (same folder) or it may not recognize the DLL
- If ExecuteAfter returns another filter, the filter will execute with the MT mode of that last filter (known issue within AviSynth+). Best solution is to make your filter MT_NICE_FILTER. Otherwise you can return a dummy filter having the desired MT mode. Or wait for Ultim to release a fix.


v1.0
- Transfered the code to GitHub
- Ported old code to Visual Studio 2015
- Replaced AviSynth.h headers with the one from AviSynth+
- Adapted the code for the new headers
- Env was being stored by the filter class (bad), removed that
- Removed GenericVideoFilter base class of AvisynthFilter and made sure it doesn't crash when first parameter isn't a clip
- Removed SAPStudio namespace
- Cleaned up formatting and removed a lot of commented code
- Added support for AviSynth+'s env2
- Added auto-registration of MT mode via the class attibute
- Added LoadImageNet sample
- Removed the constructor parameters and added them to Initialize
- Added functions to allow executing other filters before and after
- Added env.bitblt overloads to support C# byte[]

[MysteryX]

The bug with ExecuteBefore is now fixed in the code repository.

Also... why is it necessary to Dispose the VideoFrame after use? That normally shouldn't be necessary, but it crashes when closing the script if you don't.
https://github.com/mysteryx93/AvsFilterNet/blob/master/SimpleSampleNet/InterProcessNet.cs#L50

Overall, it's working. Areas for improvement: parameters could be better validated to avoid erratic behaviors, and occasionally errors aren't being handled in a nice way.

Edit: For VideoFrame.Dispose, considering it's working fine during execution and only fails during the destructor, perhaps if we let the Garbage Collector release it, it doesn't care whether the Clip or VideoFrame is released first, and if it releases the Clip first, then obviously the VideoFrame is screwed up. In that case, explicitely calling VideoFrame.Dispose may be a good idea as I don't see any other way of controlling the order.

[MysteryX]

There is one issue with VideoFrame releasing that I'm having a hard time with. It would be appreciated is some C++ expert could take a look at this one.

A lot of what I said about the Garbage Collector doesn't directly apply in this case because we're still dealing with unmanaged resources that must still be freed manually; and it must play nicely with the Garbage Collector.

Putting this code in GetFrame (C#), it will crash on exit if we don't call Src.Dispose. If we throw an exception, then we must call Dst.Dispose as well. Otherwise we get an ugly memory corruption error.

This code works but it's not addressing the core of the problem.


VideoFrame Src = Child.GetFrame(n, env);
VideoFrame Dst = NewVideoFrame(env);
try {
throw new Exception("BOOM!");
} catch (Exception ex) {
Dst.Dispose();
throw ex;
} finally {
Src.Dispose();
}
return Dst;


See the InterProcessSample. (https://github.com/mysteryx93/AvsFilterNet/blob/master/SimpleSampleNet/InterProcessNet.cs)

[MysteryX]

Version 1.0.2 is ready (https://github.com/mysteryx93/AvsFilterNet/releases/tag/v1.0.2), fixing the rough edges.

What's new:
- Fixed ExecuteBefore
- Fixed VideoFrame not being properly released

These are all the known bugs.

There is still a limitation that LoadFilterNet must point to a known folder, such as in the same folder as AvsFilterNet.dll

[amayra]

thanks AFN 1.0.2 work like a charm i have no issues until now :thanks:

[amayra]

MysteryX Just out of curiosity, why were you started(forked) this project ?

[MysteryX]

In case someone needs it. Having it before would have made it a lot easier to get started with plugin development, yet after digging through the code, there's no way I would have got it to a functional state without first learning to develop filters in C++. Now that I have the knowledge, it wasn't too hard to fix something that those who'd most need it don't have.

[MysteryX]

There are also a couple more reasons; one of which is that I'm a C# programmer in my blood.

The idea came when discussing MP_Pipeline and some of its current limitations. This sort of plugin dealing with multiple processes would be a whole lot easier to code and maintain in C#, and the other processes could then get an input instead of having to load the source within those processes. It also could be written with probably 5x less code.

The other reason is that C++ and C# have very different strengths. C++ is good for low-level work on data by using raw pointers and assembly optimization. C# is excellent for... pretty much everything else. Especially multi-threading and multi-processing. Any utility functions such as WriteToAvi or MP_Pipeline would be much easier to write that way.

Another reason is that C++ and C# programmers generally think differently. This may allow for different types of development outside of the box of what is currently being done. One thing I'm thinking is that if one would want to use some sort of advanced neural network algorithm, or some sort of AI, for highly advanced processing, these sorts of processing could be more easily done in a higher-level language like C# and linking to a library to do the neural processing (or whatever that would be). (That example is hypothetical)

Then it can lower the learning curve for .NET programmers (like me) who want to get started with plugin development.

So whatever the reasons, now it's here. I don't need it myself right now but I may use it if I need to develop something else in the future.

[feisty2]

One thing I'm thinking is that if one would want to use some sort of advanced neural network algorithm, or some sort of AI, for highly advanced processing, these sorts of processing could be more easily done in a higher-level language like C# and linking to a library to do the neural processing (or whatever that would be). (That example is hypothetical)
???? no one does algorithm related stuff in complicated languages like c#, and of course not something like c++ either
Algorithms are developed in very high level scripting dynamic languages like Matlab and Python, and then ported to c/c++ for performance reasons

[MysteryX]

???? no one does algorithm related stuff in complicated languages like c#, and of course not something like c++ either
Algorithms are developed in very high level scripting dynamic languages like Matlab and Python, and then ported to c/c++ for performance reasons
I didn't know Python had a strength for mathematical algorithms.

There is no such thing as "nobody". If I was to design a complicated algorithm, I would first do it in a high-level language like... pen and paper. Then transcribe it into C# or C++ depending on the needs.

[MysteryX]

A quick search in Google showed the pros/cons of Python over C#. Nowhere it mentions it being a better language for mathematical algorithms; it's just a simpler language, kind of like Visual Basic used to be. That simplicity also comes at a small performance cost compared to C#. It's often more compared to JavaScript.

The learning curve for C# is quite steep but once you know it it's a simple language to use.


Python is winner in: ease of learning, cross platform development, availability of open source libraries
C# is winner in: standard library, language features, development process and tools, performance, language evolution speed
Roughly even: syntax (Python is better in readability, C# has more consistent syntax), adoption.

I'd be curious to know how much optimizations .NET can do for algorithms running on raw memory streams. It can make use of all the CPU-specific commands because it does the final compilation on-the-fly, but how well does it do it? How would it compare to C++, or to SSE2 assembly? This would be an advanced question for another forum. (http://stackoverflow.com/questions/38548086/c-sharp-math-performance-on-raw-memory-stream)

To be clear: this thread is not about which language is better than any other, but about how to make the best use of C#. As to which language is best, my answer is simple: the one you're familiar with.

[MysteryX]

It's really not as bad as I thought regarding C# for raw math processing.

First, C# does support raw pointers when compiling with /unsafe. (https://msdn.microsoft.com/en-us/library/t2yzs44b.aspx)

Second, SIMD-optimized vector types have been added in .NET 4.6 (https://msdn.microsoft.com/en-us/library/dn879696(v=vs.110).aspx#Anchor_4)

Someone may have to take some time to develop a SIMD-optimized sample using raw pointers and comparing the performance with C++.

[feisty2]

I didn't know Python had a strength for mathematical algorithms.

https://en.wikipedia.org/wiki/SciPy
https://en.wikipedia.org/wiki/NumPy
https://github.com/gwpy/gwpy

[feisty2]

To be clear: this thread is not about which language is better than any other, but about how to make the best use of C#. As to which language is best, my answer is simple: the one you're familiar with.

not saying py is a better language than c#, simply pointing out c# is not widely used for scientific purposes (including algorithm designing) and py is

[MysteryX]

The scientific community is a whole other community than the programming community, so it's possible that they favor Python; but I'm not part of the scientific community.

SciPy and NumPy have however been ported to .NET and are options to be explored. Does this have SIMD optimization? How does this compare to SIMD-optimized .NET types?
https://www.infoq.com/news/2011/07/NumPy-NET
http://pytools.codeplex.com/wikipage?title=NumPy%20and%20SciPy%20for%20.Net

[feisty2]

then you're trolling, first you mentioned about "advanced neural network algorithm, or some sort of AI, for highly advanced processing", which are obviously scientific (algorithm developing) topics, then you said "You're not part of the scientific community" so you don't really give a, so what's the point?
people write prototype of the algorithm in scripting languages, and then port the prototype to a lower level language (c or c++ or stuff like that) and get a performance boost, they simply don't merge the "developing" stage and "porting" stage as one cuz that's gonna be a mess

[MysteryX]

It's not more difficult to program it in C# than in Python if you're using the same core processing library.

The difference is that Python is easier to get started with. Thus, for people whose primary job is not programming, it is easier to use. For someone who already knows C#, then there's no point in first doing it in Python.

C# is a lot simpler and clearer than C++.

Also, if C# can provide good SIMD performance using either Python Tools or SIMD data types, then it would make it a whole lot easier to optimize code properly. C++ intrinsics have a few downside:
- Complicated to use and require deep knowledge of assembly
- The same code must be written several times: CPU, SSE2, AVX, etc.
- Very difficult to maintain and/or debug
- If AVX SIMD is used, the DLL must be compiled for AVX and will fail on other CPUs; thus several DLL versions have to be produced. Very unpractical for deployment.
- Most importantly, I can't write it myself

If one of the C# options can provide performance that isn't too far, but with a *much* simpler syntax, it would allow for SIMD optimization in many places where it wouldn't be done otherwise.

[MysteryX]

Nowhere can I read that SciPy and NumPy have SIMD optimization, so SIMD-enabled vector types (https://msdn.microsoft.com/en-us/library/dn879696(v=vs.110).aspx#Anchor_4) are the way to go.

[MysteryX]

Here's something else interesting I found. It is possible to embed a C++ DLL within a C# DLL. This would allow the simplicity of C# while also being able to use C++ assembly without requiring a separate DLL. The best of both worlds!

http://stackoverflow.com/questions/666799/embedding-unmanaged-dll-into-a-managed-c-sharp-dll
https://github.com/Fody/Costura

So in practice, one can do it in C#, and if later he wants to add assembly optimization, it can also be done.

[junh1024]

Here's something else interesting I found. It is possible to embed a C++ DLL within a C# DLL. This would allow the simplicity of C# while also being able to use C++ assembly without requiring a separate DLL. The best of both worlds!

http://stackoverflow.com/questions/666799/embedding-unmanaged-dll-into-a-managed-c-sharp-dll
https://github.com/Fody/Costura

So in practice, one can do it in C#, and if later he wants to add assembly optimization, it can also be done.

It's not really 'write in C# then optimize it later' like cython or w/e, it's

CLR needs to extract the embedded native DLL somewhere (Windows needs to have a file for the DLL to load it - it cannot load an image from raw memory)

(via http://stackoverflow.com/questions/666799/embedding-unmanaged-dll-into-a-managed-c-sharp-dll )

So even if you want to do DLLception and save 1 DLL, you'll need to extract the C++ part when you use it, leaving you with 2 DLLs, which is no saving at all.

[TheRyuu]

- Very difficult to maintain and/or debug

If it's well written I don't think it should be any more difficult to maintain or debug provided equal knowledge in the languages used.

- If AVX SIMD is used, the DLL must be compiled for AVX and will fail on other CPUs; thus several DLL versions have to be produced. Very unpractical for deployment.

If you're writing custom assembly/intrinsics you have the ability to do dispatching or use function pointers. It's not difficult to do runtime CPU detection.

[MysteryX]

It's not really 'write in C# then optimize it later' like cython or w/e, it's

CLR needs to extract the embedded native DLL somewhere (Windows needs to have a file for the DLL to load it - it cannot load an image from raw memory)

(via http://stackoverflow.com/questions/666799/embedding-unmanaged-dll-into-a-managed-c-sharp-dll )

So even if you want to do DLLception and save 1 DLL, you'll need to extract the C++ part when you use it, leaving you with 2 DLLs, which is no saving at all.

The 2nd link I gave automates that process so it's done in the background. It needs to be configured right once, and then can be copy/pasted for any other project.
https://github.com/Fody/Costura

If you're writing custom assembly/intrinsics you have the ability to do dispatching or use function pointers. It's not difficult to do runtime CPU detection.
Chikuzen did that for some of my code. CPU detection for SSE2, and for AVX, it still required a separate DLL compilation.

[Chikuzen]

Chikuzen did that for some of my code. CPU detection for SSE2, and for AVX, it still required a separate DLL compilation.

I noticed the way to avoid that in the evening, yesterday.
I'll send a patch in weekend.

[MysteryX]

I noticed the way to avoid that in the evening, yesterday.
I'll send a patch in weekend.
Can you elaborate?

[Chikuzen]

Can you elaborate?

it's possible if you can read Japanese.

[TheRyuu]

Chikuzen did that for some of my code. CPU detection for SSE2, and for AVX, it still required a separate DLL compilation.

You can separate out the AVX functions into a separate file. You can then use file specific compilation flags which will only enable AVX for that file.

[MysteryX]

http://stackoverflow.com/questions/29185986/why-net-will-does-not-support-sse-in-32bit-while-ryujit-64bit-can-while-mono

SIMD support is from RyuJIT which currently only works for x64. For Avisynth we clearly need code that works on both x86 and x64.

Utility functions are very easy to write with C#, but for functions doing CPU-intensive operations on the frames, C++ is still best; unless C# allows easy SIMD integration.


RyuJIT is based off of the same codebase as the x86 JIT. While it’s only for x64 right now, it’s a modern compiler that will be the basis of all our JIT compilers in the future: x86, ARM, MDIL and whatever else comes along. Having a single codebase means that .NET programs are more consistent between architectures—put another way, you generally get bug-for-bug compatibility. But having a single codebase also means we can innovate faster and bring you more code generation features more quickly.

This quote suggests that RyuJIT will eventually be used for all platforms once it is stable enough.

Until then, the best option is C++ or C# with an embedded C++ library to do the raw frame processing operations.

[amayra]

thanks AFN 1.0.2 work like a charm i have no issues until now :thanks:

well i was wrong as usual :confused:
can you give examples for any filter please :script:

[MysteryX]

The GitHub project contains 3 sample filters
https://github.com/mysteryx93/AvsFilterNet/blob/master/SimpleSampleNet/LoadImageNet.cs
https://github.com/mysteryx93/AvsFilterNet/blob/master/SimpleSampleNet/SimpleSampleNet.cs
https://github.com/mysteryx93/AvsFilterNet/blob/master/SimpleSampleNet/InterProcessNet.cs

[MysteryX]

I just saw this: MONO supports SIMD instructions on both x86 and x64.
http://www.mono-project.com/news/2016/12/20/system-numeric-vectors/

but then it adds the MONO dependency. Not ideal, but it's an option.

[FranceBB]

Mono? What for? Let's start from the very begging, 'cause maybe I didn't get this right. (I mean, maybe I didn't understand what you are trying to do/achieve). If you write and compile filters using C and C++ you have access to SIMD, but the problem is that you need to know at compile time which instructions are available on your target machine. You need to be certain that the instructions in your binary are available on the target processor, but this is where a managed language’s JIT compiler is well placed. C# (thanks to the .NET Framework) code is compiled to an intermediate language called "Common Intermediate Language" (CIL, aka Microsoft Intermediate Language, MSIL), which is deployed to the target machine. When a program written in C# is loaded, the local .NET JIT compiler compiles the CIL to native code. The advantage is that the JIT compiler knows exactly what type of CPU the target machine has and so it can make full use of all instruction sets available to it. Besides, the application’s performance will improve in the future without ever being rebuilt and re-deployed. When future processors with larger SIMD registers become available JIT will be able to make full use them. The simplest and recommended way to use SIMD is via the classes and static methods in the System.Numerics namespace and you need at least version 4.1.0.0 of the System.Numerics and System.Numerics.Vectors assemblies. Anyway, let's stop talking about programs now. In this topic we are talking about avisynth filters that are going to run via a sort of "compatibility layer" which will make C# codes available in C++, like a "wrapper" - as you said before - which is the AVS filternet, so performance-wise it will be slower than native C++ filters, no matter what. So, the question is: what are you trying to do/achieve with SIMD? (I mean, this is not a critic at all, I'm just trying to understand, 'cause I love C#).

[feisty2]

No, you don't need to know which instruction sets are available at compile time with C/C++, basically you compile everything (even tho some might not be supported on your target machine) you have and use the cpuid instruction and detect the available best instruction set on the target machine at runtime and call the version of functions that were implemented with the detected best available instruction set dynamically.

[MysteryX]

I'm still exploring what can be done with C#, because I'm a C# programmer and have no interest in learning assembly.

For a utility filter like MP_Pipeline, C# could do an excellent job -- and pass the video clips as input and output instead of ignoring the input.

If SIMD instructions become available, then it would also become possible to do video processing filters. It may still be a bit slower than C++, but on the plus side, the development time would be much shorter, and the maintenance would be much easier. We have a whole bunch of C++ plugins that are old and have never been maintained/updated, although many of the most useful ones are being upgraded for Avisynth+ x64.

This is not about whether C# or C++ is best. This discussion is simply about what can be done with C# and Avisynth.


The .NET Framework now has SIMD support, but only for x64. Avisynth filters need to work both with x86 and x64. MONO apparently does that, but I wouldn't want to create that dependency for users.

[feisty2]

I'm still exploring what can be done with C#, because I'm a C# programmer and have no interest in learning assembly.

no assembly required, include this header file (https://github.com/IFeelBloated/Fix-Telecined-Fades/blob/master/cpufeatures.hpp)in your project and it does all the dirty work for you automatically, also extremely easy to use


//C++ 14
auto CPU = CPUFeatures{};
//yep, like the "var" feature in C#, you don't need to manually specify the variable types anymore in modern C++
//it's actually ok to just program in modern C++ like how you program in Python
//you don't have to care about types (auto and decltype), manual garbage collection (replaced by smart pointers) and tons of ugly shit inherited from C
if (CPU.sse2)
blah
else if (CPU.avx)
blah
else if (CPU.blah)
blah
else
blah



This is not about whether C# or C++ is best. This discussion is simply about what can be done with C# and Avisynth.
I'm not saying things like if one is better than another
simply pointing out that some people have been misunderstanding C++ like how they assumed runtime hardware detection would be a problem in C++
C++17 is coming soon and they still have C++98 or even C in their mind and that's why they still have so much "fear" over C++

[real.finder]

I think c# better for gui things, not for complex tasks like mp_pipeline

MysteryX, you say you will make AVSEdit work in x64 before, I think this better than mess with mpp in c#

[MysteryX]

no assembly required, include this header file (https://github.com/IFeelBloated/Fix-Telecined-Fades/blob/master/cpufeatures.hpp)in your project and it does all the dirty work for you automatically, also extremely easy to use
I never said (nor assumed) detecting the CPU type would be an issue.

But that still doesn't write any assembly. Even if dealing with that challenge I hadn't seen, one must still learn to write assembly and write assembly code for the various CPU infrastructures.

[Are_]

But that still doesn't write any assembly. Even if dealing with that challenge I hadn't seen, one must still learn to write assembly and write assembly code for the various CPU infrastructures.

No, http://www.agner.org/optimize/#vectorclass.

[FranceBB]

I never said (nor assumed) detecting the CPU type would be an issue.

I did say it, but only because I was saying that in C# you don't need to recompile a program every time, while in C++ you have to. Anyway, Feisty2 proved me that I was wrong, 'cause you can now specify which assembly optimisations use depending on CPU capabilities in C++, which is absolutely great. :)


I think c# better for gui things


As a matter of fact, Blender and Visual Studio help a lot in making UI, especially for shared projects (projects that share codes between mobile and desktop).

Anyway, we are talking about avisynth filters here; that's a whole different scenario.