AVSEdit Plus - official thread

[kagetoki]

AVSEdit Plus
https://sourceforge.net/projects/avseditplus/

I introduce a new AviSynth editing environment - AVSEdit Plus. The interface and the functionality is strongly inspired by the original AVSEdit. I have focused on creating a useful and efficient video preview feature that many of You may find interesting e.g. buffering frames into memory or side-by-side video preview. I encourage You to give it a try and I hope You will enjoy using AVSEdit Plus. You will find the latest build, source code and more details in the link above - at the official repository.

This is the official thread for AVSEdit Plus. Feel free to post here any suggestions, state issues and ask for improvements or bug fixes.

AVSEdit Plus is an AviSynth script editor with side by side preview and video encoding GUI for command line encoders:
- edit AviSynth scripts,
- preview script video results,
- buffer slow scripts and preview them in real time,
- enable side-by-side preview for two script video results,
- work with command line encoders using an encoding GUI,
- create an encoding queue.

Video tutorial on Vimeo (higher bitrate, recommended):
https://vimeo.com/170947672

Video tutorial on YouTube:
https://www.youtube.com/watch?v=VWxd6YBTZZU

Changelog

1.25.0.0 / stable / 2016.08.26

[Script editor]
- Find feature with optional regular expressions included
(Menu > Edit> Find).

[Other]
- Translation bugs handled: English

1.24.0.0 / stable / 2016.06.29

[Other]
- Fixed a mistake in handling "AvisynthWrapper.dll was not found"
exception.

1.23.0.0 / stable / 2016.06.28

[Other]
- Improvements made to the installer. Program used to install the
database files to the install location. The database files are
installed to the user's profile now (User/AppData/Roaming) and are not
removed when the program is being uninstalled. When UAC enabled, in
versions below 1.23 the database files might have been redirected from
the install location to (User/AppData/Local/VirtualStore). You might
want to recover your previous database by copying it to
(User/AppData/Roaming).
- The installer remembers the custom install location for future
upgrades.
- Fixed an exception thrown when the database files/directory was not
found or deleted.
- Fixed an exception thrown when AvisynthWrapper.dll was not found or
deleted.

1.22.0.0 / stable / 2016.06.18

First version of AVSEdit Plus ever released. The following is a list of
initial features:

[Script editor]
- AviSynth script editor with line numbering, tabs, undo/redo function
and block commenting capability.
- Sortable list of standard read-only AviSynth functions. Add function
to the editor with double click.
- Sortable list of editable functions. Add useful script parts or
functions with customized argument lists. Edit, rename, delete, add to
the editor with double click.

[Video preview]
- Video preview of script video result. Many preview windows at the
same time. Right click to open settings and study the list of shortcuts
to all video preview features.
- Seek bar, frame seeking with keys or mouse. Video playback at
original frame rate. Go to a specified frame, copy the selected frame
to clipboard. Remove borders in the preview.
- Frame buffering is turned on by default. No more encoding of
extremely slow scripts to see the results, just let a part of the clip
to buffer into memory and play it at original frame rate.
- Side by side preview mode (dual preview). Set second script video
result in the same video preview to watch before/after changes. Move
the splitter with mouse, change the splitter orientation.
- Zoom in/out the whole frame. Crop preview to a specified range.
- Clip properties shown, values may be copied: current frame and time,
clip frame length and time duration, zoom, video resolution, current
crop values, clip frame rate, video aspect ratio, system memory
information, buffer statistics for each clip in dual preview mode.
- Trim editor. All clip selections made in the preview are stored here
and may be copied to clipboard in AviSynth format. Paste it into your
script.

[Encoding GUI]
- GUI editor for command line encoders. Create and save your custom
commands for CLI encoders with the help of prepared forms. Choose
encoder, opened script (input), destination path (output) and add the
command to the batch queue.
- Sortable list of your encoder commands. Edit, rename, delete, add to
the command editor.
- Batch queue. Change job status with double click, edit or delete
commands with right click. Start or stop queue processing, each job
opens in a separate command line window.

[Other]
- Program global preferences. Any modifications made here become
default in the future unlike most ones made locally.
- language localization: English, Polish.


Known issues

- 2GB memory limitation per x86 .NET process. This limits a video
buffer capacity although there is still more physical memory left on
the system.
- No syntax highlighting developed yet.
- No code complete feature developed yet.
- Firing [AvisynthWrapper.dll].dimzon_avs_init while being very low on
memory may lead the application to freeze instead of throwing an
emergency shutdown of the video preview.
- Cannot drag & drop .avs files directly onto the script editor to open
them.
- Troubles with selecting text by mouse in the script editor moving to
the left edge when the line's length exceeds the visible width.
- No x64 AviSynth support yet. Using Dimzon's AvisynthWrapper which is
x86 only.

[kagetoki]

Reserved

[MysteryX]

WOW! Downloaded.

Will install tomorrow.

Edit: couldn't wait to try it.


System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\AVSEdit Plus\data\settings.xml' is denied.


You can't have your settings file under Program Files as your application can't write to that folder. You must move your settings file somewhere else.

I've done that same mistake before in some other app.

[luigizaninoni]

Looks interesting. No AVS+ 64-bit ?

[kagetoki]

There are going to be lots of bugs at first as it's the first release and I have been the only tester so far. Forgive me and be patient while I try to fix it.



You can't have your settings file under Program Files as your application can't write to that folder. You must move your settings file somewhere else.

I know :) I had been quite aware of the potential problem before the 1.22 release but I tested it on an admin account with Windows UAC enabled and it worked fine moving the database files to Virtual Store automatically. Will fix it. Until then, use the portable .zip version, please.

Looks interesting. No AVS+ 64-bit ?

Unfortunately I use dimzon's x86 AvisynthWrapper that won't cooperate wit x64 AviSynth, I guess. But I may be mistaken. Will check it if sth can be done.

[wonkey_monkey]

Best first post ever! :)

I started work on something similar years ago, but never had the time to finish it up. I planned to have the same split-bar comparison thing, though I was going to do it so that you would prepare your script with a stackhorizontal or stackvertical, and the program would let you swipe between the two halves of the output.

Something else I planned was to have control over conversion to RGB and also bobbing, external to the AviSynth script being edited. So for example, if you were working on interlaced video, you could view a bobbed preview without having to add bob() to your script (frame numbers could count as 0T, 0B, 1T, 1B etc). You could also select which colour matrix you wanted to use to convert to RGB for display. This was all going to be done using env->invoke.

The buffering for previews looks great, too. I had all kinds of ideas, such as: if someone starts seeking backwards (left arrow) don't just get the previous frame; go back a few frames more and work forward. If they keep seeking backwards, jump even further backwards. I hoped that - at least on simple formats like MPEG2 - it would allow smooth reverse seeking, which you just can't do with Virtualdub. I also thought about caching many frames as low quality JPEGs to allow fast scrubbing, or allowing the user to somehow specify a "low quality" version of their output. For example, they could set a special line of AviSynth code (lo_quality_clip_=source.bob) which would allow fast scrubbing, with the full quality frame (generated, for example, using QTGMC) only being displayed once scrubbing stopped.

Other ideas: a tooltip to give information about individual pixels, such as RGB value or YUV value, or if you zoom in far enough, to have these numbers printed on the pixels themselves.

A timeline below the video, on which you could set markers for interesting places in the video, or scene changes.

Copying and pasting:

The ability to copy a frame onto the clipboard, edit it in (for example) Photoshop, and paste it back on to the video. This would then generate a "diff" file which you could apply to your AviSynth script with a plugin.

Syncing:

Two or more instances of the program could be set to "sync" which would mean moving to another frame would also make any other "sync"ed instance move to the same frame.

I hope some of this might be useful to you.

[geometer]

Really great idea!
So far I use AviDemux (connected to frameserver) for the simpler adjustments, as it has sliders and [x] check boxes for the parameters and many filters have an instant preview. Also, it can freely skip forwards and backwards one or many frames, though not entirely stable.

Suggestion:
Parameter sliders and checkboxes with fast preview cycle.
- for this we preselect one frame or a very short sequence in the video.
- we define the parameter(s) either in a template script with the syntax: myfunction(&val1&,&val2&,&val3&) ## &def val1:integerslider; &def val2:floatslider; &def val3:checkbox
-- so the actual script will be rewritten from that template,
- or we create reserved variable names and the function uses the variables as usual, and the script mechanism sets the variables with inserted/replaced assignment statements.
-- val1 = 100 ## &integerslider # 100 is the initial value to start that experiment from
- the sliders might appear in a pop-up window with the variable names written below
- a move of a slider triggers the redisplay mechanism, this can be switched off.

[GMJCZP]

Welcome to the forum, kagetoki.
I've always used VDubMod for these tasks but keep an open mind to new ideas. Thanks.

[MysteryX]

Toolbar buttons need tooltips to say what they do. It's really obvious for most buttons anyway except the 2 '#' buttons. This change is very easy to add.

Clicking the '#' makes it easy to see what they do. Still, just out of respecting coding standards :)

[kagetoki]

AVSEdit Plus 1.23

New version has been released. See the Changelog section in the first post (http://forum.doom9.org/showthread.php?p=1771799#post1771799) for the complete list of changes.

[StainlessS]

Thank you kind sir.
Nice to see source available and also not Pascal (or Delphi maybe) as the original. [EDIT: Seems much C#]

[MysteryX]

Now when I try to run the script, it says:

File was not found:
F:\AVSMeter\TestImage\tools\AvisynthWrapper\AvisynthWrapper.dll


Ctrl+F to Find would be an important feature to add

[real.finder]

thank you for develop AVSEdit

Unfortunately I use dimzon's x86 AvisynthWrapper that won't cooperate wit x64 AviSynth, I guess. But I may be mistaken. Will check it if sth can be done.

I think if every script run in it's own process then you can even make side-by-side preview for two different AviSynth (x64 and x86) by an option to change that for every script, Regarding AvisynthWrapper, I think you can dispense it by make a tool in .exe that load AviSynth .dll directly just like avsmeter or mp_pipeline

[MysteryX]

+1 for running scripts in different processes. It would also greatly add to the stability as AVSEdit wouldn't crash if the script crashes.

[kagetoki]

AVSEdit Plus 1.24

New version has been released. See the Changelog section in the first post (http://forum.doom9.org/showthread.php?p=1771799#post1771799) for the complete list of changes.

[Groucho2004]

One little cosmetic thing I noticed:

https://s31.postimg.org/p10joetpn/Image1.png

The file type combo contains Polish text (on English Windows).

Otherwise - nice program!

[kagetoki]

Thank You all for the warm welcome of AVSEdit Plus, I appreciate Your fast feedback :)

Best first post ever! :)

Thanks. You give many great ideas which some of them I hope to use in the future. I've already been thinking about low quality JPEG buffering to extend buffered frames count.

Suggestions

Thank You for your suggestions. Instant-preview sliders may appear somewhen, that'd be some new quality.

Toolbar buttons need tooltips

I hate tooltips popping up when the button images are obvious enough especially when there are only a few custom buttons. I had disabled tooltips on purpose. Yet, I reactivated them for the custom buttons.

Now when I try to run the script, it says:

File was not found:
F:\AVSMeter\TestImage\tools\AvisynthWrapper\AvisynthWrapper.dll


Ctrl+F to Find would be an important feature to add

Thanks MysteryX for the quick response to the error. I didn't do enough testing, and made a mistake. Gonna think about Ctrl+F too.

I think if every script run in it's own process then you can even make side-by-side preview for two different AviSynth (x64 and x86) by an option to change that for every script, Regarding AvisynthWrapper, I think you can dispense it by make a tool in .exe that load AviSynth .dll directly just like avsmeter or mp_pipeline

+1 for running scripts in different processes. It would also greatly add to the stability as AVSEdit wouldn't crash if the script crashes.

I admit to have been thinking about it since the beginning, however I hadn't felt strong about multi-process coding back then. Will rethink the approach to this matter.

The file type combo contains Polish text (on English Windows).

Nice catch! Will be fixed in the next release. Why translating using resources? When I was choosing the method, I simply found it'd be faster to click through designers at first, knowing what is what.

[MysteryX]

If you could run the script in one thread and store the cache in the main thread, that would solve a lot of memory issues.

In C#, there are several ways to share data between processes and Named Pipes may do what you need. (https://msdn.microsoft.com/en-us/library/bb546085.aspx)

[Groucho2004]

If you could run the script in one thread and store the cache in the main thread, that would solve a lot of memory issues.
What cache?

[MysteryX]

Didn't he say he's buffering the video to facilitate playback and that caused memory to run out?

[Groucho2004]

Didn't he say he's buffering the video to facilitate playback and that caused memory to run out?Oh, that. I was thrown off a bit by your choice of terminology.

[MysteryX]

Oh, that. I was thrown off a bit by your choice of terminology.
Don't be thrown off so easily. No I wasn't talking about AviSynth's internal cache.

kagetoki, .NET and Software Architecture are my specialties. If you have any questions about how to structure the code, just ask.

Running the script in a different thread does have great advantages
1. Main app can cache without running out of memory
2. If AVS process crashes or freezes, it won't affect the main app and the main app can kill it
3. You can run both x64 and x86 scripts. Otherwise, a x86 app can only run x86 scripts and a x64 app can only run x64 scripts.

It really shouldn't be hard to implement at all. With C++, this would be a heck of a nightmare to setup cross-process communication. With C#, you have many options available to do it in a clean and simple way. C# also makes multi-threading and asynchronous operations very easy to code, make good use of it.

As for the database, I see you store it in a XML file. You might want to consider using SQLite instead. (https://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki) Then you can manipulate your data with LINQ and it's easy to expand your data structure as the needs evolve.

You might want to compile the application with Target Platform: Any CPU (project properties, Build). That way, it will run in x86 on x86 systems and in x64 on x64 systems. Managed code will work fine and the restriction then is that you cannot use x86-specific components. The only x86 components you should use are to run AVS and that can be in the other process. The script can run in x86, pass the computed frames through Named Pipes to the main app running in x64 that can cache those without worrying about memory.

By the way, is this an open source or closed source project?

[StainlessS]

By the way, is this an open source or closed source project?

Full C# source via Sourceforge link in 1st post, or here:- https://sourceforge.net/projects/avseditplus/files/avsEditPlus/stable/01024/src/

[real.finder]

Don't be thrown off so easily. No I wasn't talking about AviSynth's internal cache.

kagetoki, .NET and Software Architecture are my specialties. If you have any questions about how to structure the code, just ask.

Running the script in a different thread does have great advantages
1. Main app can cache without running out of memory
2. If AVS process crashes or freezes, it won't affect the main app and the main app can kill it
3. You can run both x64 and x86 scripts. Otherwise, a x86 app can only run x86 scripts and a x64 app can only run x64 scripts.

It really shouldn't be hard to implement at all. With C++, this would be a heck of a nightmare to setup cross-process communication. With C#, you have many options available to do it in a clean and simple way. C# also makes multi-threading and asynchronous operations very easy to code, make good use of it.

As for the database, I see you store it in a XML file. You might want to consider using SQLite instead. (https://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki) Then you can manipulate your data with LINQ and it's easy to expand your data structure as the needs evolve.

You might want to compile the application with Target Platform: Any CPU (project properties, Build). That way, it will run in x86 on x86 systems and in x64 on x64 systems. Managed code will work fine and the restriction then is that you cannot use x86-specific components. The only x86 components you should use are to run AVS and that can be in the other process. The script can run in x86, pass the computed frames through Named Pipes to the main app running in x64 that can cache those without worrying about memory.

By the way, is this an open source or closed source project?

yes, I was hoping avspmod did this too, I already suggest this https://github.com/AvsPmod/AvsPmod/issues/33

this will help a lot in avoid crash if a lot of script is opened, I and many people suffered from avspmod crashes because of 2 or 4 gb limit

[MysteryX]

You might also want to consider GitHub for hosting the source code. It's a bit harder to get started, but then it works very smoothly for managing source code.

Let me know if you need some help to move the AviSynth API code into a separate process.

Here's how I would go about moving the code into a different process.
1. I'd create a new EXE project
2. I'd change the project to x64, move the DLL that doesn't compile into the new project, and look at the compilation errors (references to that DLL)
3. Move all the code that isn't compiling into that separate project.
4. Write the code to launch the process and setup the communication interface
5. Decide on the best code structure for the inter-process communication and implement it. Process B generates frames via AviSynth and return the processed frames to Process A which stores it in a cache and display to the user.

This also creates a layer of abstraction between the UI and AviSynth; you could just as well run a VapourSynth script and return it through the same inter-process interface. You might not support it now but you might as well design it so you could easily do that.

[shekh]

You might also want to consider GitHub for hosting the source code.

May I ask, why GitHub is important? Can you explain its benefits?

[shekh]

A suggestion: there is no need to have another process only to have more address space. You can use pagefile backed memory mapping to store frame cache in the same process that generates them. Afaik pagefile mapped memory has overhead around 10% compared to normal memory, sending it to another process through pipes should be much slower...

[FranceBB]

@shekh... it's important because you can easily setup access to that repository, test and submit changes. For instance, since you are using C#, I assume you are using Visual Studio as well. With Visual Studio you can login to your github account, create a sharing project and work together with other people to improve your code and add new functions. Basically it will first download the whole code, then it will allow you to make some changes locally, then it will check whether someone else changed something while you were working on that code. If no one changed anything, it will let you submit your changes, otherwise, if someone did actually change the code, it will retrieve the new code, check whether there are any incompatibilities with your modifications or not and ask you again if you want to commit your changes again.

I find it very constructive and a very good way to work together with other programmers. ;)

[shekh]

@FranceBB
It looks like you are confusing git and github, all you described applies the same to all git, and sourceforge` git hosting seems ok

[Groucho2004]

A suggestion: there is no need to have another process only to have more address space. You can use pagefile backed memory mapping to store frame cache in the same process that generates them. Afaik pagefile mapped memory has overhead around 10% compared to normal memory, sending it to another process through pipes should be much slower...
Shared Memory via CreateFileMapping/MapViewOfFile is probably the easiest and fastest inter-process data transfer. Not sure if that is to what you are referring.

[shekh]

Shared Memory via CreateFileMapping/MapViewOfFile is probably the easiest and fastest inter-process data transfer. Not sure if that is to what you are referring.

It is also the easiest way to have a lot of memory in single 32bit process. This trick is hard to guess and I used it for similar purpose (frame cache inside of input driver) so decided to mention this.

[Groucho2004]

It is also the easiest way to have a lot of memory in single 32bit process.And another goodie - 64/32 bit inter-process data exchange.

[MysteryX]

Shared Memory via CreateFileMapping/MapViewOfFile is probably the easiest and fastest inter-process data transfer. Not sure if that is to what you are referring.
Shared Memory File is the C++ way of doing it. C# offers many other options. You want to avoid writing to the hard drive if it's not necessary. If you do a search on C# cross-process communication, you will never see Shared Memory File ever mentioned as an option to consider.

Many of the methods work between 32-bit and 64-bit processes. You just don't want a method that involves XML serialization; you want to pass raw data, but with some structure around it. Named Pipe and Binary Remoting are two options.

Just found a performance comparison of the various communication methods. (https://msdn.microsoft.com/en-us/library/bb310550.aspx)

You might as well go with WCF. It's a bit more complex to setup than Remoting but it's a more modern technology and the performance is good. Then with WCF, you have the choice between NetTcpBinding and NetNamedPipeBinding. Then all communications are Object-Oriented.

[MysteryX]

May I ask, why GitHub is important? Can you explain its benefits?
http://programmers.stackexchange.com/questions/164618/why-are-many-programmers-moving-their-code-to-github

[Sparktank]

As an end user, I find GitHub has less clicks to get to a download.

For some reasons, navigating SourceForge tends to be the slowest.
Even with a quad, 3.1GHz processor, 8GB ram and SSD's.
I can't see why add-ons in Firefox would hinder navigating SF, but SF has the slowest response times. After 5 folders, it becomes tedious.
If the main, big green button was the AIO download archive, I'd grab that. But in most cases, there's plenty of sub-folders that may need to be grabbed separately.

I use JDownloader to download anything as even clicking download may lead to issues (for any raw document not archived).

[MysteryX]

SourceForge is great to distribute the application as it tracks the downloads, which GitHub doesn't.

However, giving a link to a ZIP file containing the source code of the latest release doesn't support collaborative development.

With GitHub, anyone can easily navigate the source code online, view the code history, download the code, make changes and submit them to you where you can merge the changes in a single click. I would have already taken a quick look at what the AviSynth API calls look like if I could do it online, and how you structured the code and projects.

With GitHub, anyone can also see the latest developments before the next official release, which is a must for collaborative development. SourceForge also supports Git, but it's not as fast and clean as GitHub.

Also there is this to take into consideration. (https://helb.github.io/goodbye-sourceforge/) (although I see SourceForge has just been sold to a new company that promises to turn things around)

[MysteryX]

I also would advice against writing the cache to a file. If Windows needs more memory, let it manage its paging file on the hard drive. That's what it's for.

[Groucho2004]

Shared Memory File is the C++ way of doing it. C# offers many other options. You want to avoid writing to the hard drive if it's not necessary. If you do a search on C# cross-process communication, you will never see Shared Memory File ever mentioned as an option to consider.
It has nothing to do with C++. It's a functionality the Win32 API offers. Also, nobody said anything about writing to a file/hard drive.


Just found a performance comparison of the various communication methods. (https://msdn.microsoft.com/en-us/library/bb310550.aspx)

You might as well go with WCF. It's a bit more complex to setup than Remoting but it's a more modern technology and the performance is good. Then with WCF, you have the choice between NetTcpBinding and NetNamedPipeBinding. Then all communications are Object-Oriented.
All this is about network protocols. Is that how you want to transfer frame data?

Since you seem to be clueless about what's going on beneath your shiny Visual Studio IDE and chosen abstraction method for the Win32 API, I suggest you stop embarrassing yourself.

[Groucho2004]

I also would advice against writing the cache to a file. If Windows needs more memory, let it manage its paging file on the hard drive. That's what it's for.
What are you talking about?

[MysteryX]

Shared Memory via CreateFileMapping/MapViewOfFile
How can you have a "File" without writing to the hard drive? File = hard drive.

Since you seem to be clueless about what's going on beneath your shiny Visual Studio IDE and chosen abstraction method for the Win32 API, I suggest you stop embarrassing yourself.
NetNamedPipeBinding A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.
That's the way communication is being done in .NET between processes. Not through a shared file but through local network communication.

Adding this level of abstraction also would make a few interesting features possible. With this level of abstraction, code-wise, you're accessing a class as if it was local and the framework handles the communication and binary transfers of data. On top of the big advantages already mentioned, it would also make those possible:
- Since the worker process handles the requests from the main thread in whichever way it wants (x64 or x86), it can process VapourSynth scripts just as easily
- Since WCF really doesn't care whether it's inter-process or inter-machines communication (just change configuration), it would even make it possible to run the script on a remove server that would return the processed frames. It could even be a server with GPU support. Maybe you wouldn't want to pay $30 or $60 a month to maintain such a server, but THAT feature would be WAY COOL!

[Groucho2004]

Shared Memory via CreateFileMapping/MapViewOfFile
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 (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it).

How can you have a "File" without writing to the hard drive? File = hard drive.
You're absolutely correct (https://msdn.microsoft.com/en-us/library/dd997372(v=vs.110).aspx).

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]

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.

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]

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.