berrinam
11th July 2006, 12:46
Here's an idea I've been mulling over for a while. I would appreciate it if you take the time to comment on it.
Goal
Create a cross-platform, extensible, lightweight encoding back-end which co-ordinates plugins, video/audio encoding, muxing, pre-/post-processing, and profiles.
Why
It would save development time, allowing more people to focus on extending the power of encoding co-ordinaters without having to choose one particular frontend.
It would mean that GUIs themselves would be less effort to create, since the gruntwork would be done by this co-ordinating back-end.
Separating the GUI from the co-ordinater makes platform independence much easier, thereby allowing those Linux and Mac users to more easily enjoy the beneifts of the tools created on this forum.
Having a text-based interface as opposed to a GUI would also be much more flexible. Just look at Avisynth!
Inspiration from Avisynth
Obviously, Avisynth is a great example for this outcome. Avisynth achieves the same goal that I discuss here, but just for processing as opposed to the entire chain. There are a few things that make Avisynth so ubiquitous:
Extensible infrastructure allowing third party plugins
Nice language for both human and computer editing.
Many already-included filters, meaning it works from the start
Strong abstraction, meaning easy integration into other appsAll the points except for the last are relevant and possible for a encoding co-ordinater, and I would recommend trying to achieve all of them.
The language it is written in is also a somewhat important consideration: I think it needs to be cross-platform, extensible, and lightweight (meaning no huge frameworks are required to use it, *ahem* Java, C#). To be extensible, it needs to support some form of library, just like Avisynth does with *.dll filter files. So this would mean a systems language like C or C++ are a good idea. It could also be an interesting idea to try D (http://www.digitalmars.com/d/), because it allows this low-level (and fast) coding, while keeping most of the safety of Java/C#. An interpreted language like Ruby/Perl/Python is also a possibility, but I've had no experience in that area, so I can't judge.
This task would be a big project, but MeGUI and StaxRip could be used as a guide a lot of the way, because I think they are the most feature-complete tools here. The rest of the details will hopefully become clearer if the project gets started, so does anyone have any comments on the idea, and is anyone interested in participating in development?
Goal
Create a cross-platform, extensible, lightweight encoding back-end which co-ordinates plugins, video/audio encoding, muxing, pre-/post-processing, and profiles.
Why
It would save development time, allowing more people to focus on extending the power of encoding co-ordinaters without having to choose one particular frontend.
It would mean that GUIs themselves would be less effort to create, since the gruntwork would be done by this co-ordinating back-end.
Separating the GUI from the co-ordinater makes platform independence much easier, thereby allowing those Linux and Mac users to more easily enjoy the beneifts of the tools created on this forum.
Having a text-based interface as opposed to a GUI would also be much more flexible. Just look at Avisynth!
Inspiration from Avisynth
Obviously, Avisynth is a great example for this outcome. Avisynth achieves the same goal that I discuss here, but just for processing as opposed to the entire chain. There are a few things that make Avisynth so ubiquitous:
Extensible infrastructure allowing third party plugins
Nice language for both human and computer editing.
Many already-included filters, meaning it works from the start
Strong abstraction, meaning easy integration into other appsAll the points except for the last are relevant and possible for a encoding co-ordinater, and I would recommend trying to achieve all of them.
The language it is written in is also a somewhat important consideration: I think it needs to be cross-platform, extensible, and lightweight (meaning no huge frameworks are required to use it, *ahem* Java, C#). To be extensible, it needs to support some form of library, just like Avisynth does with *.dll filter files. So this would mean a systems language like C or C++ are a good idea. It could also be an interesting idea to try D (http://www.digitalmars.com/d/), because it allows this low-level (and fast) coding, while keeping most of the safety of Java/C#. An interpreted language like Ruby/Perl/Python is also a possibility, but I've had no experience in that area, so I can't judge.
This task would be a big project, but MeGUI and StaxRip could be used as a guide a lot of the way, because I think they are the most feature-complete tools here. The rest of the details will hopefully become clearer if the project gets started, so does anyone have any comments on the idea, and is anyone interested in participating in development?