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

Steve Lhomme steve.lhomme at free.fr
Wed Jan 28 20:55:09 CET 2004


Christian HJ Wiesner wrote:

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

Mmm, that's what we did with Matroska. And it was worth !
Now a software that won't share much of his code with other parts needs 
a different thinking. But still, good programming always start with a 
good analysis. You're not going to build a good/stable house on weak 
foundations.

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

Don't be a fool Christian. This is going to happen anyway whatever way 
we choose !

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

See above.

> So, from a political point of view, only Gstreamer or our own solution 
> are viable options. Sorry for this non-technical point of view :) ...

Well of course it makes sense. But it's still good to pick some good 
ideas here and there when we can.




More information about the Matroska-devel mailing list