[Matroska-general] Re: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool

[Steve Lhomme]

Moritz Bunkus wrote:

> Heya,
> 
> 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 
talking about...

> 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 :)