[Matroska-general] Re: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool
steve.lhomme at free.fr
Wed Jan 28 11:20:39 CET 2004
Moritz Bunkus wrote:
> I agree with Chris here. This project will be big enough as it is, and I
> fear we won't get anywhere with so few people if we spend our energy now
> on something that is not the first thing to decide. Actually we can do a
> LOT of work before we even get to this stage where such an edit format
> will be required, and I hope we can concentrate on that instead.
Sure. But you will also lose a lot of precious time/energy if you start
coding and think afterwards. IMO we should have a far view of what we
want to do to keep that in mind when designing, and then coding. That
was my basic idea of throwing random thoughts in the basket.
> I like Chris' roadmap so far, especially the first four points. What I
> really want to have is to have the core and the GUI separated from each
> other. I also want to have the core being completely scriptable. Ideally
Mmm, that script your talking about for phase 1 is the same one I was
> the GUI would only translate its actions (open file, seek to time x, get
> the number of tracks etc) into such script commands. Therefore this
> script language needs some thinking. I have very little experience with
> such stuff, so others are probably more knowledgable (avisynth users?).
Maybe Cyrius has some. Because VDub is also scriptable a bit (at least
exectue batch processings).
> Then we need some kind of API for the demuxers / readers /
> whateveryouwanttocallit. This API must be powerful enough to get all the
> information out of a Matroska file. It will not be enough to have
> something like libavformat (meaning only the basics, open a file, get
> the next frame, have a rough description of the codecs etc). The same
> goes for the output layer. And we need a framer layer (functions/modules
> that split a stream of e.g. MP3 frames into the individual frames).
I suggest investigating some time to search if we will have to reinvent
the wheel or not. There are maybe GStreamer, Helix and Quicktime that
are possible to use for the main 3 desktop OSes. GStreamer being the
most open one, but the less advanced so far.
> That's only the background. We also need someone who's willing to do GUI
> programming. I'm not - I don't like it, and more importantly, I'm not
> good at it. The GUI (like the core) must be cross platform, so the
Yes, that's also my problem : the GUI. And we can't give that to a VB
coder... Maybe Jory would be interrested ?
> number of GUI toolkits to chose from is very, very small. Qt is out of
> the loop as it cannot be used royalty-free on Windows anymore
Uh ? I didn't know something has changed here !
> (especially not if we ever want to accept money for it if I understand
If we want money we need to pay a license of a few 1,000 USD (IIRC).
> it correctly). Gtk might be a solution as it does run on Windows. I'd
> prefer wxWindows as it is very comprehensive and takes care of a lot of
> xplatform issues right away.
Yes, and it looks native ! Which is the best way to have a user feel
comfortable. (and is probably the most efficient CPU wise).
> What else? Hmmm... I'd also prefer to use Subversion as the version
> control system as it has numerous advantages over plain CVS, but as this
> will be a Corecodec project I guess that is out of the question, and
> we're stuck with CVS again.
We might talk to Cyt0plas about it. But we could also use your
subversion system. And only feed CVS for the tagged versions. (extra
work for no gain...)
> You see, Steve, I definitely do not want to discredit your ideas. It's
> just that we have more than enough work ahead of us that is totally
> independant of what you want to achieve. Let's concentrate on this
> instead, please.
Well, you're not that far from my ideas :)
More information about the Matroska-general