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

Jory wrote:

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

Christian

>
>  
>




More information about the Matroska-devel mailing list