Project announcement + invitation to participate : new, opensource video editor TCME

[ChristianHJW]

Hi there,

i have a short announcement to make, followed by an invitation to other developers to participate in the project, or at least to comment on it :

The matroska and Corecodec teams have decided to unify the efforts made in various projects around the matroska container, and to create a new, opensource and x-platform video muxing/editing/encoding tool together. It will be called

'TCME - The Core Media Editor'

and it will be released under a ( EDIT : decision pending ) license.

This new tool, once ready and working, will gradually replace the following matroska editing/creation tools :

- mkvmerge
- VirtualdubMod
- mkvextract
- mkvinfo
- MPEG2-to-MKV
- matroska stream editor

Main developers will be Cyrius and Mosu, assisted by robux4, jcsston, spyder 482 and maybe S_O . Hopefully more contributors will follow sooner or later, everybody who knows some C and/or C++ and has some basic video coding knowledge is invited to join the team.

Here a possible roadmap for the development :

1. Define basic structure, including the internal editing scripting
2. Define API for input/output modules
3. Allow muxing of MKV files, using different source formats
4. Implement simple cutting/editing based on frame number / timestamp
----- note : at this step mkvmerge becomes redundant
5. Add Preview for the most used and free formats ( via libavcodec ? licensing problems ? )
6. Implement enhanced one step editing, similar to Virtualdub ( mark areas to be deleted / copied )
7. Define a codec plugin API
8. Realize re-encoding of audio and video streams, using de/encoder plugins
----- note : at this step vdubmod becomes redundant
9. Adding NLE, with fades etc.

As the editor will allow output plugins also, the editor can well be extended to create/edit/output

- MP4 files
- RMVB files ( depending on RealNetworks licenses of course )
- MPEG files

so it will not be a sole matroska tool ( maybe MKV will be used as interims editing container for some steps, we'll see ), but could become a general, VFR capable replacement for Virtualdub. The GUI and the core application will be strictly separated, so the GUI ( written in wxwindows ) will only create scripts telling the app what to do with the file. This will make it very easy for the tool to be used from 3rd party apps ( like GKnot, DVX, DVD-to-MKV, etc. ).

Our to-do list now comprises :

1. Agree on a platform for this, i.e.
a. using Gstreamer, including a port of it to win32
b. using Helix ( license problems ? )
c. make a new platform, including media-api to allow format and codec plugins

2. Create a scripting language ( similar to avisynth, but more powerful in terms of editing ), as it will be the basis of the interfacing from GUI to app.

3. Convert existing code from mkvmerge into working input plugins, based on the API as decided under 1.

The main purpose of this announcement is to motivate developers to join the discussion about the basic structure on the matroska mailing lists. http://lists.matroska.org or http://news.gmane.org , gmane.comp.multimedia.matroska.devel

Thanks for your interest .....

[Wilbert]

This sounds really nice!


2. Create a scripting language ( similar to avisynth, but more powerful in terms of editing ), as it will be the basis of the interfacing from GUI to app.
More powerful, as in porting to other platforms? Or do you mean a whole new scripting language? Does that imply that AviSynth in its current form won't be supported?

[ChristianHJW]

Input plugins could certainly include an avisynth plugin ... no problems to be expected here ....

[alexnoe]

Will it read AVIs containing AAC and SSA? :rolleyes: :D

[ChristianHJW]

Originally posted by alexnoe
Will it read AVIs containing AAC and SSA? :rolleyes: :D ... thats very much depending on you Alex, as you will have to care about at least the AVI output plugin personally, if not the input plugin also :P ....

[mf]

If you read my suggestion for VFR in AVISynth (http://forum.doom9.org/showthread.php?s=&threadid=69132) I think there's no problem in extending it to do what you want it to do. AVISynth has always needed a "direct stream copy" operating mode, especially for audio but preferably for any kind of stream (including unsupported ones, like subtitles), and a tool like this would be the perfect excuse to implement it. I've actually always wanted VirtualDubMod to be able to "host" AVISynth in the same way ffdshow does (instead of external avs->vdubmod, vdubmod->avs->vdubmod), but people seemed to prefer external scripts and I must say it's only an ideal wish instead of a practical need. What you guys are on to could be the ideal solution for combining DirectShow, VfW, AVISynth and independant tools (like mkvmerge). It would be nice if you could look outside the scope of the YACAPs.

[ChristianHJW]

Originally posted by mf If you read my suggestion for VFR in AVISynth (http://forum.doom9.org/showthread.php?s=&threadid=69132) I think there's no problem in extending it to do what you want it to do.

mf, you should know us guys good enough meanwhile, should you :D ?

Avisynth, however powerful it may be or possible become, is based on AVI/VfW, and especially the latter is a bad, old legacy we are trying hard to replace. So, for that reason and others, we certainly wont build this new tool around avisynth, especially also because this means porting it to other platforms, which is a complete no-go IMO, similar to porting Virtualdub.

Rest assured we will look at the avisynth scripting language and try to get a lot of inspiration from it, and of course knowledgeable avisynth script users are always invited to give input to what we are trying to do now ;) ....

[RadicalEd]

I think it sounds like a brilliant idea. There are no full-featured open NLEs for Windows. I'd gladly join if I knew an ounce of C (useful, I know :D ), still, I'll see what I can pool from the AMV community.
:up:

[mf]

Originally posted by ChristianHJW
mf, you should know us guys good enough meanwhile, should you :D ?

Avisynth, however powerful it may be or possible become, is based on AVI/VfW, and especially the latter is a bad, old legacy we are trying hard to replace. So, for that reason and others, we certainly wont build this new tool around avisynth, especially also because this means porting it to other platforms, which is a complete no-go IMO, similar to porting Virtualdub.
It is not a matter of knowing, but it's a matter of some (false) hope I still have left. I'm disappointed in you. You guys must really love doing duplicate work. Just look at all the bugs that have been in AVISynth 2.5.x which were fixed in 2.5.3, and look at the bugs left. Coding a wannabe AVISynth from scratch is NOT fun. Expect a million bugreports, limited features, and a lot of missing compatibility. Even if you would create something that loads AVISynth plugins, you're just as well off basing your work on it. But I guess a million headbumps aren't enough for you. Remember -gemma?

[Wilbert]

A thread about AviSynth and porting it to linux

http://forum.doom9.org/showthread.php?s=&threadid=61415

Dunno whether it is of any use, since I'm not a programmer.

[Siku]

Originally posted by mf
Just look at all the bugs that have been in AVISynth 2.5.x which were fixed in 2.5.3, and look at the bugs left. Coding a wannabe AVISynth from scratch is NOT fun. Expect a million bugreports, limited features, and a lot of missing compatibility. Even if you would create something that loads AVISynth plugins, you're just as well off basing your work on it.

Yeah. Replacing AviSynth sounds like a insane idea. Is there any chance to incorporate AviSynth in this 'TCME - The Core Media Editor'? But if you really somehow manage to create something similar to AviSynth, it would be great. Good luck with your project!

Regards,
Siku

[stax76]

I wish you guys all the best, I reads like a huge challenge. What I don't understand is how will a scripting language like AviSynth be marriaged with a editing tool like VirtualDub. I asume it must be based on the same multimedia framework so GStreamer must be ported as well, is it technically possible to have binary compatible GStreamer plugins on different plattforms?

[ChristianHJW]

Originally posted by Siku Yeah. Replacing AviSynth sounds like a insane idea. Is there any chance to incorporate AviSynth in this 'TCME - The Core Media Editor'? But if you really somehow manage to create something similar to AviSynth, it would be great. Good luck with your project!Regards, Siku ... :sigh: .... please read above what was said. Yes, there could be an avisynth input plugin be done for the editor. Basically, if a program can open AVI, it also can open AVS scripts, as avisynth is doing nothing else but simulating an AVI to the program thats opening it.

Dont ask me if we include an avisynth script editor though, because for sure we will have completely different goals for the first year of the development of the editor.

Originally posted by mf It is not a matter of knowing, but it's a matter of some (false) hope I still have left. I'm disappointed in you. You guys must really love doing duplicate work. Just look at all the bugs that have been in AVISynth 2.5.x which were fixed in 2.5.3, and look at the bugs left. Coding a wannabe AVISynth from scratch is NOT fun. Expect a million bugreports, limited features, and a lot of missing compatibility. Even if you would create something that loads AVISynth plugins, you're just as well off basing your work on it. But I guess a million headbumps aren't enough for you. Remember -gemma?

mf, calm down and get your head right. Avisynth is a scripting language for advanced filtering and frame processing. We need a scripting language to define various input and output files containing a high number of different video/audio/subtitles streams, select single streams from that, process them independantly, mux them into new files, etc. pp. To be able to use avisynth for that we had to
- make it portable ( not so easy )
- extend it to allow REAL VFR capability ( timestamp, not simply variabke framerate based )
- extend it to allow handling of many different input formats and plugins, and again x-platform !!

I agree avisynth could be used as a basis for many things, but wouldnt we risk to get stuck in the middle of what we are actually trying to do, and without being able to foresee this when we are starting ?
You may think its 'reinventing the wheel' when we think about a new scripting language specifically for our purposes, but coders/developers will maybe agree that its sometimes easier to start from scratch, on a white piece of paper, then trying to 'pump up' an existing solution that was never designed for what you are trying to achieve.

Also, there may be no need to do this work ourselves. Both Gstreamer and Helix are very interesting alternatives for what we are trying to do, and we are currently looking very closely into the possibility to port Gstreamer to win32 ....

[mf]

REAL vfr. You're just making it sound fancy. Using timecodes is just as valid/real VFR as defining framerate ranges. In fact, afaik mkvmerge USES framerate ranges for making into timecodes. Framerate ranges are much easier to work with than timecodes when editing (when trimming and splicing you need to subtract/add timecodes and eventually you'll run into a hundred bugs and problems doing that alone), but suit yourself. Go reinvent the wheel.

[bilu]

@ChrisHJW

I knew you guys would have the guts to start such a project :D
Wish you the best luck from the start.

There are several reasons to do an Avisynth replacer. Have a look at the link that Wilbert posted and this one:

http://forum.doom9.org/showthread.php?s=&threadid=64115

And you already have the will to do it, and that's good :)

But I honestly think you don't need to reinvent the wheel entirely.
Why not use GStreamer as the basis for all your work?

There's a lot of work to be done to put GStreamer in Windows but I think it's worth it. And the GStreamer team would be glad too IMHO :)


Bilu

[ChristianHJW]

Originally posted by bilu But I honestly think you don't need to reinvent the wheel entirely. Why not use GStreamer as the basis for all your work?
There's a lot of work to be done to put GStreamer in Windows but I think it's worth it. And the GStreamer team would be glad too IMHO :). Bilu

Using Gstreamer would in fact have another advantage : we could merge efforts with two french computerscience students from France, who are actually starting to make a video editor based on Gstreamer as there diploma thesis ;) .... but they wont help us with porting, as they are focussed on making it work on Linux ....

[bilu]

@mf

Have a look at Bidoche's post here:
http://forum.doom9.org/showthread.php?s=&postid=387136#post387136

@ChrisHJW

Well, porting would be your job, greatly rewarded by code already done.
You would also reward them with the GStreamer port :)
And we'd have a cross-platform API for audio/video filters!!! :D :D :D

Please please please? ;)

http://www.gstreamer.net/status/?category=7

"Windows Platform: Not tested, probably needs some porting effort and platform plugins made.Testers needed. Maintainer unclaimed." :rolleyes:

Bilu

[bilu]

It would be great to share the Windows video experience and coding with the skills from Unix and Mac coders :)

Bilu

[mf]

Originally posted by bilu
Have a look at Bidoche's post here:
http://forum.doom9.org/showthread.php?s=&postid=387136#post387136
Bidoche didn't consider per-frame framerate flags, did he :D. It's a simple extension similar to Decomb hinting, that will always guarantee 100% backwards compatibility, and it's easy to implement. VFR problem solved.

[bilu]

I'd like his opinion about that :rolleyes:

[mf]

Originally posted by bilu
I'd like his opinion about that :rolleyes:
Feel free to tell him about it. I wrote it in the MkvSource thread, dunno if he read that.

[Human_USB]

I would love to help but my programming skills are lacking. I'm just now learning C++ .NET in college.

-Jason

[MfA]

A small word of warning to contributors, if you plan to put a lot of time into it be sure you are marked as one of the initial developers according to the QPL ... and not just a contributor.

The QPL gives exclusive commercial&closed-source distribution rights for the complete project to the initial developers. Contributors retain copyrights for their own code to do with as they wish of course, but they have to grant the initial developers a license to do pretty much anything with it ... and that does not go the other way, it is not a reciprocal license (which can be a fair deal if the initial developers will always be the main developers, but is not really a viable model for community based open source projects for obvious reasons).

[Bidoche]

Originally posted by mf
Bidoche didn't consider per-frame framerate flags, did he.I thought I just did that.
Not as part of core, but an extension that filters can choose to take into account.

[spyder]

Hmm, why is this supposed to be QPL...

[Human_USB]

So they can make money if they wish to sell the software. Am I right?

[bilu]

Where did the QPL licensing came from? :confused:

Not from GStreamer:
http://www.gstreamer.net/docs/cvs/faq/html/chapter-general.html#general-licensing

Bilu

[MfA]

Well maybe Christian thought there was still a free Qt edition for windows under the QPL? There used to be, but they stopped updating it AFAICS ...

[bilu]

Why work on Qt when you can work on WxWindows ?

Real cross platform, better licensing.

http://www.wxwindows.org/newlicen.htm

Bilu

[spyder]

Qt was never mentioned by ChrisHJW ;)

I myself am unclear as to why the QPL license is stated. That obviously conflicts with gstreamer... We do plan to use wxWindows as it's the toolkit we have the most collective experience in. Calm down. The licensing thing is maybe a mistake ;)

Spyder

[spyder]

OK, after reading the QPL and discussing with some of the team we concluded that QPL will be used for a few reasons. First, we would like to keep the project from forking into numerous mods...even one is bad, just look at how much time Cyrius and Belgabor spend merging VDub into VDubMod. This way we keep the whole project under one tree and everyone benefits. Second, only the editor core and main application will be licensed this way. This doesn't restrict plugin developers to this license and therefore does not force them to give up rights to their own code. Obviously, the QPL does give rights to the main developers for any modifications made to the application. This is scary for some as MfA pointed out. The group of initial developers is still swelling so our whole team shouldn't disappear anytime soon unless some freak accident happens that kills all of us in our different countries. Most of the app will be extendable through plugins which should protect the rights of most contributors. Again, we think of the community when deciding this.

Spyder

[MfA]

This isnt about being scared of the development group falling apart ... this is about money.

This is about informing anyone who wants to contribute to core that the initial developers can (and probably will if the oppurtunity ever presents itself, lets be honest) profit from their contributions in a closed source project. As a plugin writer little changes, you are still adding commercial value to the core (unless you want to put a click through license on your plugin to prohibit using it with closed source versions).

QPL is a nice license when the initial developers will always own 99% of the code, but still want to allow some access to the source for patches and user input. Anyone planning to contribute big time should ask themselves if he likes the initial developers enough to make them money without getting a cut.

Oh BTW, on vdubmod ... so you would rather it didnt exist at all? (It probably would not if Virtualdub had been QPL.)

PS. the control issues over licensing is way to big a part of the QPL to make a justification that you are just using it to prevent branching ... if that truely is your only aim you could amend the license, if you dont do that then to assume that it isnt being used for the obvious reason (money) would require me to believe you guys were stupid (about licensing anyway, at the moment it would just be naive ;).

If that is really the only reason change clause 4b to stipulate the software can only be released under the QPL or the GPL. I include the GPL so you could in the future still cut the project free if you decided to ditch the QPL.

[bilu]

@spyder

Forks aren't necessarily bad. Matroska is a fork from MCF, right?

:devil:

I don't like licenses less free than GPL. My favorite is BSD.
GPL would be enough to force every fork to release it's code, many new ideas could inspire different forks. Look at Divx/XVID as a good example.

Forks won't have significance until the project gets to an usable status. And everyone will work on that first :)


Bilu

[mf]

This QPL thing reminds me of the OpenDivX license. The developers said there was nothing to be afraid of, yet they closed the source and even removed some important code from CVS. Really nice.


Originally posted by Bidoche
I thought I just did that.
Not as part of core, but an extension that filters can choose to take into account.
Did I read wrong then? VFR will be in AVISynth then?

[dragongodz]

would that be the QPL as found listed here ?

http://www.gnu.org/licenses/license-list.html

[mf]

Originally posted by dragongodz
would that be the QPL as found listed here ?

http://www.gnu.org/licenses/license-list.html
Certainly looks like it.

[bilu]

IMHO QPL should be avoided like the plague.
OpenDivx is a nice example on how these things would end up.

Bilu

[MfA]

They couldnt really close to the source, closest they could do is put the existing source in a library (to be released under the QPL) and build proprietary software on top of that.

[ChristianHJW]

Guys, i dont understand whats going on here. I appreciate that you discuss the choice of our license here, thats perfectly allright and of course we owe you an explanation here, why we wont make it GPL.

But do we really deserve all the prejudices listed here ? I understand that MfA, who never saw the sense behind making matroska BTW, is trying to tell people we choose this license form to be able to make money from it. It seems he has a certain interest to shade a bad light on our project, for whatever reason, but so be it.
But you other people, do you really believe that also ? Have we ever give you the faintest impression we did matroska to earn money with it ? Is it the professionalism and passion we are putting into this project that makes you believe that ?

To clarify why TCME will under no circumstances be released under the GPL :

There is only one major driving force behind this project, and we are not ashamed to say this, and this is to push the use of our container format. At the end of last year i wrote an email to the team, thanking them for all the effort they did and the fun we had doing this. But, i also tried to give a look into the near future, and i predicted a clear migration of users towards MP4. There can be no doubt that MP4 ( which is MOV basically ) is a very powerful container format, and it has the status of an industry standard. There are more and more apps suporting it, and they allow more and more features, and some of them are even more powerful than what we can do with matroska currently.

Still, MP4 doesnt qualify for what matroska is aiming to become, a real successor of the AVI format. MP4 is only a subset of MOV and thus limited to a number of video and audio codecs, and as such it will certainly replace the old MPEG standard for content transmission where stadarisation is a big point, like from satellites, to cellphones, picture telephones etc. pp.

Matroska, on the other hand, is about freedom of using whatever compression format fits the users needs best, and for his present situation. It is aiming to become a very good container for video and audio editing, and Cyrius has proved this already with the wonderful MKV support in VirtualdubMod, just like AVI being the first choice for video editing still.

Having said that, please understand that using the GPL license for the editor would mean to put a big risk behind the whole matroska project, because basically the following things could happen :

- an opensource friendly company trying to push MP4, like 3ivX, Cisco or IBM, could literally fork the project, REMOVE ALL MATROSKA RELATED CODE FROM IT ( for them, they might find it annoying ) and relase the editor as a MP4 version, under the GPL, and distribute it with the huge marketing power they have. Bearing in mind that currently all MP4 is missing to become widely adopted is a nice and free video editor ( like Virtualdub ), its clear we would hurt our own project if we allowed that to happen. Then, it wouldnt help us at all that the GPL would allow us to copy their MP4 module and add it to our project.

- using GPL license, we would risk that TCME would become a part of mplayer / mencoder. As these guys hate us and flame us whenever they can, we have to choose a license that clearly forbids that, and they are GPL :p .. ( j/k ) ...

Now, allow me to add a couple of important aspects :

1. Chances are good that we finally decide to use gstreamer as the underlying platform for TCME. robux4 has made excellent progress in trying to compile it for win32 lately, so we see light at the end of the tunnel. Again, this doesnt mean its ported already, but we're making progress.
As gstreamer is released under the L-GPL license, it is compatible with QPL, so we could use it from TCME under this license. But, needless to say, all necessary container/codec plugins that needed to be done to read/mux/parse/decode/encode into all the different formats supported by matroska, would also be relased under the L-GPL license by the matroska team, ONLY the TCME core would be QPL !!!

2. libmatroska/libebml are relased under a GPL/QPL dual license, so we could use it fine for TCME without having to change the license type now. Of course, this is only a minor point because all the developers of it are still team members, so we could easily relicense the libs to whatever we need.

3. We are still happy about input from the community what other OSS license type might be suitable to help us with the issues explained above. We are certainly not dogmatic here, if we find another license deos the same, but doesnt have this 'can be used for commercial stuff' smell, we are happy to change that.

Does this make things clearer now for you ? Guys, trust us ! We never had commercial interests when making matroska, and we dont have any intentions to change this. We are just taking appropriate measures to ensure our hard work doesnt turn back against our beloved project ;) .....

[bilu]

Money was not what I was talking about.

I didn't read the whole license, but got the idea it would stop forks.
Given that Matroska itself is innovation born from a fork, I think forks may become great products :)

I wouldn't want to stop new VDMods or Matroskas from being born. :)

Bilu

[MfA]

Actually I have always seen the need for Matroska, I just never liked the design.

The QPL has issues, and no amount of words will make those go away. Intentions change, the license stands.

[ChristianHJW]

Originally posted by bilu Money was not what I was talking about. .. good :)
I didn't read the whole license, but got the idea it would stop forks. .. thats not fully correct. forks are still possible with QPL, but under pretty bad circumstances. And you cant hide the fact very easily that you made a fork ;) ...
Given that Matroska itself is innovation born from a fork, I think forks may become great products :) .... i know i was using the word 'fork' myself when speaking about MCF and matroska, but basically this is not fully correct. libmatroska contained some very small amount of code taken from libmcf, and these lines have been replaced since some time now. So, matroska is not a fork in the real sense of the word, because it was never really using MCF code.
I wouldn't want to stop new VDMods or Matroskas from being born. :) Bilu ... no, for sure, you as the user wouldnt. But how do you think will Avery and Tronic ( if we assume for a moment we really had forked, taking his code for our stuff ) think about that ?

[Koepi]

:goodpost: MfA :)

The reasons given for the choice of QPL worry me even more. Is that a pure superiority complex? Or paranoia?
Be honest: Noone took vdubmod, took every avi stuff out and made it matroska only.
Or mp4 only.
Why would something with matroska in it's name would get such treatment? Do you think IBM has such bad engineers that they can't come up with own, nice code? (And they code a lot themselfes without any need of external supporters / "hijacked" sources.)

Sorry, but marketing blahblah doesn't change my oppinion in that.

Regards
Koepi

[ChristianHJW]

Originally posted by MfA Actually I have always seen the need for Matroska, I just never liked the design. ACK. Thats something i can live with, so i apologize for what i said above.
The QPL has issues, and no amount of words will make those go away. Intentions change, the license stands. .... any recommendations about what other license we could use then ? How about making it closed source and sell a version with MP4 support for 20,- US$, very similar to what TMPEGencoder, BSplayer, Zoomplayer, and many other well accepted video appliations are doing right now, and without being bothered from anybody about their license type ?

[Wilbert]

I wouldn't want to stop new VDMods or Matroskas from being born. :) Bilu


... no, for sure, you as the user wouldnt. But how do you think will Avery and Tronic ( if we assume for a moment we really had forked, taking his code for our stuff ) think about that ??

I take it that you know how Avery thinks about VDMod. Maybe you can share it with the rest of us?

[ChristianHJW]

Originally posted by Wilbert I take it that you know how Avery thinks about VDMod. Maybe you can share it with the rest of us? .. sorry, i should have been more precise. Avery never ever said something negative about VdubMod, not at all. He was also never interested to adapt parts of its code to extend Virtualdub to read or write other containers than AVI, although i asked him about that more than once. He is of the opinion that VfW/AVI are pretty powerful, and there is no real need for a replacement of it. For the MPEG2 parser from fcchandler, he doesnt add it for legal reasons, of course. Given the number of copies Virtualdub is distributed with each release, and him living in the US, this might be a wise decision after all.

However, i dare saying this positive view about VdubMod would probably change once VdubMod would be the favourite tool for the users, and get more downloads then the original ? I dont know, maybe i am wrong, and he lives the GPL idea however it may turn out for him.

But, lets suggest for a moment that the above described scenario would happen, and a company like Cisco made an MP4 editor based on Virtualdub ( technically not really possible, but lets assume for a moment it was ), forking from Virtualdub under the GPL, removing the AVI output module and releasing the program using their sheer marketing power. Avery wouldnt be pleased, i bet ....

[Suiryc]

Originally posted by Koepi
:goodpost: MfA :)

The reasons given for the choice of QPL worry me even more. Is that a pure superiority complex? Or paranoia?
Be honest: Noone took vdubmod, took every avi stuff out and made it matroska only.
Or mp4 only.
Why would something with matroska in it's name would get such treatment? Do you think IBM has such bad engineers that they can't come up with own, nice code? (And they code a lot themselfes without any need of external supporters / "hijacked" sources.)

Sorry, but marketing blahblah doesn't change my oppinion in that.

Regards
Koepi
I was also surprised to see today that 'we' concluded that QPL would be used ;)

Now I would like to clarify a few things that seemed unclear when I read Chris posts.
Nb: The following is only my point of view, maybe other people see it differently.

In no way I would like this editor to be somehow codec / container / platform-dependant.
As you could read in the description given, we would like this editor to work using plugins for input/output etc. This way if someone wants to add support for a specific container it would be possible by building a plugin :)
Chris' plan is to 'strongly' integrate Matroska support (e.g. by statically linking the Matroska plugin) right from the beginning. This would then help spreading this nice format :p

Now what ChristianHJW wanted to prevent with the QPL license is from 'bad' people to somehow 'corrupt' the initial aim of the editor and make an editor only supporting their favorite container. In other words prevent people from 'forking' the project, remove the Matroska code (that is the plugin source code) and only support their container as output.

As far as I am concerned, I hope there are no such kind of people in this community (maybe I am naive).
Also I believe that the QPL won't prevent such determined people to do so. It will only add some constraints on the way they would do it.
And actually I don't think this would be a good solution because this would give reasons for people to do so, while those very same people could also help us improving the program in other circunstamces.


Right now I am still discussing about the licensing ...

[bilu]

Looks like the BSD versus GPL discussions.

GPL prevents code from being closed into proprietary projects. It shows afraid of being locked out of your own project because a proprietary modification got more success than yours and you're not even acknowledged the merit.

BSD lets the code become part of more restrictive licenses, either closed source or open source (BSD code can become GPL, but not the other way around). It aims to see good code getting everywhere, not worried if someone makes profit from an improved version of your product or not. You just KNOW you won't be locked out: you can allways create the same features that the closed source company added.

Ironically GPL coders do this all the time: add features that exist on closed source only. So why are they afraid of getting locked out?

Same question applies to the Matroska team of course ;)


Bilu

[mf]

What a lame reason for such a license. You might not have taken much MCF code, but afaik the menuing is still exactly the same, as are other parts of the specification, if not only slightly changed to allow for EBML. Specification was also licensed, remember? And that's exactly what you did. Fork the spec, and create your own format, which, due to lack of manpower on our(MCF) side, became more successful. Now really, I'm not very pleased. But would I have known this would happen, have pushed for a QPL spec license, or anything similar? No. You Matroska guys are showing your ugly side again. The "we want to become the nr. 1 container format side and aren't afraid to do dirty things for it" side. Disgusting, really, seeing all your other stuff is (L)GPL.

[Latexxx]

Oh crap!
The guys are giving you free software (at least like "free beer") and you are complaining about their license! They could have made it proprietary.