I’ve hinted that there are plenty of things left to do before. Especially in my forum posts. Repeatedly. So in this post I’ll list some tasks I think should be done. Not all of them are programming either.
- Proofread the documentation — most it was written after midnight so suggest clarifications too
- Write testcases to cover more parts of the code — testing the python bindings is important too so only some scripting knowledge needed to help out with it
- Add override file support to VIVTC (good entry level programming task)
- Convert the EEDI3 port to pure C (simple if you know the difference between C and C++)
- Port your favorite function/plugin from Avisynth — there’s something for everyone here
- Port your favorite Avisynth script
- Make a nice editor with preview — think AvsP
- Write some simple getting started examples or maybe a quick introduction for Avisynth users
- Add support for more output formats in vfw — clean up the output code too a bit
- Write a good implementation of edge detection filters — canny, sobel and friends for higher depths would be nice
- Your own ideas here
First, thanks for doing VapourSynth. It’s appreciated work, Fredrik!
Why do you want EEDI3 in C? What’s wrong with C++ approach? VS core is written in C++, no?
It would be good if you could write basic architecture and design introduction to VapourSynth, hopefully with some explanations (i.e. not only how, but also why it is done that way). It would ease a bit getting into it.
Maybe not my favourite, but quite often used in the past years was MCTemporalDenoise script, depending on many other scripts/plugins.
AvsP isn’t the greatest. If something new is going to be created, it should be well-thought-out, allowing “writing” scripts in a GUI-way. E.g. by laying out blocks representing functions, scripts, input sources and output sink or some other data and connections between them. (Does VS supports many output sinks? Maybe it’s worth considering adding such thing?) Other approach would AfterEffects-like layers with stacked effects. You’re using QtCore a bit already, so going with Qt would be quite natural (I’m not sure about QML approach), possibly >= 4.8.
The VapourSynth core is written in C++, yes, but all the standard functions are pure C and so will many written filters be too. Most video processing code doesn’t benefit from classes, it’s that simple. At most I miss default arguments and template functions in a few rare cases to make a simple generalized function to support many bitdepths at once. Also porting EEDI3 to C will make it possible for other linux projects to borrow the code without going crazy.
I guess I should write something describing the architecture in general, it’s definitely needed to explain why the threading works the way it does.
You can have an unlimited number of outputs and use them from different threads at once if you want, actually I mostly want a script editor and not a massive bound to fail NLE project. There have been enough of those for avisynth already.
I have to admit, I’d love a writeup of the architecture, and the current filter pipeline procedures.
Although all things considered, the current code quality lends itself well to easier reading than other projects, including AvxSynth.
My suggestion for “Write a good implementation of edge detection filters — canny, sobel and friends for higher depths would be nice” would be porting masktools.
Rewriting it is easier, I did look at the quality of mt_merge and even when the mask has a value of 255 the other clip can create noise in the lsb due to simply using a bad blending formula. It’ll simply take more time to extract it from Mvtools and verifying it than doing it properly from the the start.
For edge detecting (putting the other mask manipulation etc aside), I found tedgemask by Tritical the most practical tool. It is also extremely user/noob-friendly, with good default behaviour.
How about, before telling people what they can do, how about telling us where you are going? (i.e. roadmap)
I don’t have that much more in the list. The only bigger project is a script abstraction library so you don’t need to link python into a program using vs. The rest I’ve planned is mostly portportport whatever I see. Or more exactly rewrite rewrite rewrite.
I’ll start looking at gpu stuff seriously once I think things are good enough.
Without audio processing, frameserving is utterly useless for the average frameserver user. Audio is important, how come it is not on your list yet?
Pick one thing. Do it well. This way I at least have a working half instead of a big, convoluted mess. And no, audio isn’t that important in my opinion, just look at the poor treatment and how few filters were written for it in Avisynth. Besides, you can always mux it in later in the next step.
If you need audio support very soon I’m of course willing to discuss the cost of implementing it. I estimate it’s one month of full time work to design the API, implement basic filters and spend a few minutes testing it.
I wrote a replacement for AvsP back when AvsPMod didn’t exist. I “officially” abandoned it not long ago but could revive it as a VapourSynth editor. Need to just replace the backend with VapourSynth and it will already be a fairly usable editor for Windows. Would need to port it over to other platforms after that.
Is there a working api for frontends yet? I see one commit for it.
Yes and no to the api thing. You have to link against python but otherwise it’s not that bad. See the vfw model for how it does thing. It only takes like 15 lines of code if all you want is to evaluate a full script file.
import_vapoursynth() is a part of vapoursynthpp_api.h I assume? Which seems to be missing from source…
It is automatically generated when you compile the python module with cython. So yes, it’s a bit annoying right now unless you also feel like compiling the vs core just to get that file.
I will write a better abstraction library soon because this solution is bad. It’s still good enough to start poking an editor if you want a head start though.