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

Jory jcsston at wiesneronline.net
Wed Jan 28 19:01:23 CET 2004

----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>; "General talk about Matroska and other
products" <matroska-general at lists.matroska.org>
Sent: Wednesday, January 28, 2004 4:20 AM
Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate,
plugin based video editing tool

> 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 agree here too.
When I first started VFRE (VFR Encoder), I coded like crazy for two days on
the internal framework (in/out streams/pin, format types, etc.) and now I
don't have a clue of how it works because I never had done any planning for
it. (It doesn't work BTW ;)

> > 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.

I think GStreamer would be our best target.
Helix is nice and very DShow/COM like, but it has no docs whatsoever, and it
is not GPL/LGPL friendly.
I don't know anything about Quicktime, but if IIRC the support under Linux
is not that great. (I may be wrong here)

> > 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 ?

I would be interested in helping with the GUI, but I wouldn't want to do it
all myself. ;)

Also the plugins would need a good options interface/GUI. Prehaps we could
do something like I prototyped in LemAPI.
 // Here you supply your supported options, names, types (Integer, String,
Boolean), and supply a short description about the option
<Option name="Copy Info Frames" desc="If set to True Info Frames will be
copied" type="Boolean">True</Option>
<Option name="Read LAME Info Frame" desc="If set to True Info Frames will be
copied" type="Boolean">False</Option>
<Option name="Frame Size" desc="This is a dummy to show Integer"
type="Integer" range="0-10">10</Option>
then for each plugin we could generate a small options dialog with the XML
options fragment.
|                              MPA Input Options                          |
|      Plugin by Steve Lhomme <steve.lhomme at free.fr>    |
|                            X Copy Info Frames                          |
|                            O Read LAME Info Frame                |
|                           Frame Size : 10 (a spinbox control)     |
|                             OK           Cancel

The checkbox would have the desc fields as tooltips. With that type of data
it should also be easy to create .htm/.txt docs for those who want to script
from scratch.

> > 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).
I wouldn't use anything but wxWindows. :)
GTK, along with it not looking native, requires a ton of version dependant
.dll's. Which under Windows is just asking for trouble. GIMP doesn't work
here because of that, some rogue png.dll is the wrong version and crashes


More information about the Matroska-devel mailing list