[Matroska-devel] Re: Variable Framerate, plugin based video editing tool
Christian HJ Wiesner
chris at matroska.org
Wed Jan 28 19:48:51 CET 2004
Lets focus on matroska-devel from now on, ok guys ?
>>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 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 ;)
Good point Jory. But Mosu never said we shouldnt do any planning on the
scripting language, we are basically discussing now what the initial
scope of the planning should be like. It seems Mosu and me prefer to
keep it simple to start with, and extend it later. robux4 on the other
hand wants to invest more time to be spent at the beginning, to save us
from bad surprises afterwards.
Maybe Cyrius has the scripting language already in his head and will
lauch about us now, as we invest so much time into discussing whats
better, instead of simply doing it ;) ....
>>>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)
I also believe either Gstreamer, or a self made platform are the
solutions to go for ? Why ? Well, as you all know i am thinking
political. MOV is the standard container for Quicktime, RM the same for
Helix. As we plan to make the editor opensource and plugin based, the
following will happen if we base it on either of them :
Somebody will make an output plugin for the standard container of the
platform we were using, say thank you, and people wont use matroska
because the other container will be better supported. So, instead of
helping matroska to become better accepted, we will damage the project
with the editor.
I know you guys dont like this kind of thinking, as you believe that
users will go for the technically best solution, and freedom is
everything. But please, lets be realistic about that :
MOV is a pretty powerful container, and the advantages of matroska
compared to it, the better ( or at least easier ) extendability, will
maybe show in 5 years the earliest, if new, powerful compression formats
will come to market, requesting special support from the container.
Everything thats available right now can be stored in MOV just fine, and
normal users will see more widely supported 'standard' in it than
matroska currently is.
My point here is, if we were using QT as basis for what we are trying to
do, we had to make a lot of codec plugins based on the QT API, for many
different formats like SSA, USF, AAC, whatever. Doing that, we'd dig
matroska's grave, as this would enable Quicktime to support all the same
content than whats possible in matroska. Same, maybe a bit different, is
valid for using Helix.
So, from a political point of view, only Gstreamer or our own solution
are viable options. Sorry for this non-technical point of view :) ...
>>>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. ;)
Thanks Jory, this is highly appreciated :)
More information about the Matroska-devel