I would like to talk about moving this project in a slightly new direction. I don't know whether that means a fork, although I hope not. I thnk we need to discuss this because I think avisynth is a fantastic and original bit of code, and it needs to mature beyond the obscurity of DVD rippers and Anime traders.
My main focus is, and has been, on video. But not because I like to watch TV ('tho I do) but because I like to create. I've been an engineer since I was a kid, but I also like to create with the other side of my head. And that's why I became so enamored with AviSynth. It was like love at first sight. Much of the "features" Apple is selling now about FCP are simply inherent to the functionality of AVISynth. Talk about innovation!
But the fact is AVISynth was (and for the most part is), simply, a rippers tool. And while that might be a handy use, it is selling Avery and Ben's initial effort far short of the ideal.
I want to be freed from a dependance upon Microsoft for my TV set. I want to be able to use Linux for all my stuff, but I can't. I can't because most of the software that does video for Linux is geeky crap. The one project that showed real promise, an NLE package, has been abandoned. So much for video editing in Linux. Yes, I know I can use Linux as a TV set, but it should be clear that my "TV" does a lot more than that - and I can't use avisynth or veedub in Linux, either.
I would like to not to have to worry about OS at all. If I want to add another Linux desktop I would like to have that freedom. And if I want to get a Macintosh to play with, I'll go there as well. To be able to employ all these in creative and original purpose would be my own "killer app." I think it would be to a lot of people. A lot of people who make and spend a lot of money doing this stuff. And if you're the one who helped build the damn tool they're using, that means greater marketability of skills. It doesn't mean job security, but it sure does bolster your appeal to employers.
AVISynth, at its most basic, is a language interpreter and a video processing library. Much of it is already "portable." What is missing are the hooks in and out of the system, and the development support in other platforms. Here is how I think it could be evolved to leave the box into, at least so much as the various proprietary and competing media formats will allow, true platform agnosticism.
TCP hooks
- If TCP were just another frame server and just another input device, interoperability of this widget would instantly advance by leaps. Consider:
- TCP commuications would allow multiple boxes to share the work on one project. If you have three video sources and each requires its own set of filters, they can each run on a separate box. No need to chop the tasks up arbritrarily, you can combine them as you need.
- TCP input would allow interprocess communications with other apps programmatically. Want a cool new NLE front end? Now you can export data from AVISynth into Python - or even the jscript engine built into windows. You can build a complete NLE suite in jscript and DHTML if you want to be so platform centric - or you can use python to create one NLE suite that will run on any platform, anywhere. If you have a really fast connection you don't even need to be in the same building.
Now, beyond TCP hooks, it would be useful to be able to add asynchronous behavior. That means, instead of just using python or jscript to see the output of your script, you can use the same filters programmatically. That means the ability to have a fully functionally preview window in your GUI. Tweak the knob, the picture changes - instantly. When you're ready to render the job the GUI spits out a script and off we go. So the next step would be:
Interface the library to Python
- After doing some research over the last several days, I have found discussions of such a library go back years, but no one ever actually did anything about this. The object types don't even exist yet. We already have the object type - videoinfo (vi) - and it works. And we already have the transport of it accomplished - we did that back in step one. So now "vi" becomes a standard Python object type. It can be extended to greater bits depths, palettes etc as needed without having to go back and rewrite all that c code.
Once these two steps are done, we have a full featured NLE suite that can be extended by anyone. We also have access to a HUGE library of Python tools already made, including hooks directly into the OpenGL?, Mac OS X, and Win32 API. If you want to use the tool as you always have, you can - but that is no longer the only way. And I can finally have my editing suite the way I want it - not the way Adobe wants it. And if I decide to get a Macintosh, or move to Linux, my entire suite moves right along with me. Most of the tools can even exist on the internet somewhere.
Did I hear you say .NET? Java?
Nah... let me hear you say "Python."
Back to ForkingAround
