AVSEdit Plus - official thread

[Groucho2004]

Originally Posted by Groucho2004

Shared Memory via CreateFileMapping/MapViewOfFile

Originally Posted by MysteryX

How can you have a "File" without writing to the hard drive? File = hard drive.

I understand how this can be confusing for somebody who never read the Win32 API documentation. I give you a clue: Your focus should be on "Mapping", not "File".

[TurboPascal7]

but THAT feature would be WAY COOL

Right.

How can you have a "File" without writing to the hard drive? File = hard drive.

You're absolutely correct.

Imo the only reasonable thing the OP could do is to stop listening to people suggesting him how to code stuff here. Just do your own thing the way you want to do it.

[MysteryX]

It is often easier to structure things in a way that allow for more features as it forces to structure in a more flexible way, which then leads to better maintainability of the code in the long run. That doesn't require any more time or code; just a bit more thinking in the beginning. Compared to using a raw shared memory file (where you have to hack around a create some kind of limited communication protocol for various commands), the structure I proposed would require much less code and be much cleaner. Easier to program, more stable and easier to debug and maintain, and the user probably wouldn't see any performance difference.

Ok, Memory-Mapped Files use Virtual Memory. Still, there are various commands that must be sent back and forth, such as getting information about the script and error reporting. Doing that the C way with a raw file as if we were in the 1990's would be pointless, especially when using C#.

At the end of the day, unless kagetoki needs help programming it, he's the one who's going to decide how he's going to do it -- or even do it at all.

[TurboPascal7]

If you want nice abstraction, trivial implementation and flexibility - use bloody http. The overhead of http will be much lower than that of avisynth anyway and http is infinitely easier to implement and use than any other IPC method in existence. And for all you know, the remote machine might be running vapoursynth on linux, controller by python! Now that would a killer feature a lot of people would use.

[Groucho2004]

Originally Posted by MysteryX

Doing that the C way with a raw file as if we were in the 1990's would be pointless, especially when using C#.

You're right. While we're at it, all plugin developers should remove their ASM optimizations and re-write them with C#. ASM and C is so 90's.

Originally Posted by MysteryX

At the end of the day, unless kagetoki needs help programming it, he's the one who's going to decide how he's going to do it -- or even do it at all.

Indeed.

[MysteryX]

What are heck are you guys talking about.

HTTP or XML is not ideal for large binary data.

The client doesn't care what the server is as long as it exposes the interface.

You can't write assembly in C#; assembly is considered "unmanaged" code. This gives C++ an edge for critical-performance calculations.

Now please stop talking non-sense

[Groucho2004]

@TP7
Your sarcasm seems to be lost on some people.

[MysteryX]

Now here's something that "could" actually be useful, especially to the several who mentioned they were running their scripts on a server.

Having a server-side component they can install on their own server. They could plug their server into AVSEdit. Running the script remotely and returning the result would only be useful for previews, and for that, yeah HTTP would be fine. Then with one click the server can perform the full processing and send back the encoded video when it's done. It would then be better to do the entire processing remotely otherwise the job would be lost if the internet connection cuts.

That's a low-priority feature but would be interesting for the future, especially if AviSynth+ ever supports Linux.

Separating the processes with WCF would make this easy to implement.

Thinking of it, binary downloads are also done over HTTP so that's not an issue at all. Forget what I said about HTTP not being suitable for binary data.

[geometer]

what's the problem?
different people have learnt in depth different very powerful paradigms and programming worlds, so there should be a lot of synergy!

[MysteryX]

Originally Posted by geometer

what's the problem?
different people have learnt in depth different very powerful paradigms and programming worlds, so there should be a lot of synergy!

It's interesting when "worlds collide"

As for running scripts in their own processes, let's view it this way.

It can be done the C++ way with a direct file mapping; but that would be considerably complicated and I'm not sure the author wants to go through that trouble right now.

That being said, I believe this is a very important feature. If he doesn't want to implement it, I'll do it myself the C# way. Give me about 3 hours to get it up and running; plus perhaps another hour for testing and debugging. It won't require much code at all.

[stax76]

AVSEdit btw. was originally written by me about 10 yours ago as StaxRip's script editor and was later removed and extracted as standalone tool.

[feisty2]

I was gonna say c# code is not portable and cpp is but...
avisynth itself is kind of not portable already, and cpp code dealing with APIs from some specific OS is not portable either...

[MysteryX]

C# code is cross-platform compatible with Mono and/or .NET Core (at least most of it; WPF user interface library isn't cross-platform)

http://www.theregister.co.uk/2016/06...t_linux_event/

My own websites are ASP.NET hosted on a Linux VPN with Mono

[geometer]

BTW AvsProxy works with port# 9999 - on a note on interprocess communication..

[MysteryX]

By the way, I wrote a sample of inter-process communication using WCF with AviSynth.

With AvsFilterNet, you'll also be able to integrate C# directly within the AviSynth scripts; if that can prove useful. One thing that can be done, for example, is to add a C# filter at the end that gives you control of the script from within and that returns the frames to your editor via WCF. Then there wouldn't be any issues about a x86 interface that isn't compatible with x64. Not that this example is a good idea, but it just gives an idea of possibilities.

[kagetoki]

AVSEdit Plus 1.25

New version has been released. See the Changelog section in the first post for the complete list of changes.

[jriker1]

Is there a way to use this without installing? On my video editing system I do not install anything unless I absolutely have to. OK if I have to install it in a virtual machine or something and then just copy one folder somewhere but don't install much that drops things all over on my system or can't tell where it's installing things.

Thanks.

JR

[Groucho2004]

Originally Posted by jriker1

Is there a way to use this without installing?

How about using the portable version from here?

[jriker1]

Nice.

I'm having a problem per this thread:

http://forum.doom9.org/showthread.ph...54#post1780154

Hoping pre the recommendation another tool will not exhibit this problem.

Thanks.

JR

[Groucho2004]

Originally Posted by jriker1

Nice.

I'm having a problem per this thread:

http://forum.doom9.org/showthread.ph...54#post1780154

Hoping pre the recommendation another tool will not exhibit this problem.

Thanks.

JR

I'm a little confused. How does this relate to the portable version of AVS Edit Plus?