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.

[MfA]

They were asking for other developers to help, which given the rather extreme control and more importantly exclusive non reciprocal rights the QPL gives to a very small subset of those developers warranted a small warning.

A license is a contract, and it deserved a little more carefull consideration on which to choose ... this thread while turning a bit too hostile did help in that regard.

[jkwarras]

AS far as I'm concerned, as an independent filmmaker, I can only see good things about an open-source NLE system. I'm sick of all the bad things that commercial products brings to users:

1) Bad support: Users are never see as a user, but as an annoying person that always ask new things ans complaints (anyone ever tried the Adobe Premiere Forums? or adobe premiere support?). Usually thepeople that are there to help you don't know much more than you do about their products.

2) Limitations: MOst know NLE products have non supported features just for commercial reasons. For ex. one of the most discussed questions right know in the digital NLE world is the firewire port. Theoretically this can be used to transfer even HDCAM to a PC. There's no need to buy an expensive NLE video card (as Avid), etc.. Ok, you need much more and the best and quickest HD to handle that, but you still save a lot of money. Right now it's not possible but in the future this will be, for sure. One of the main advances right now is that DVCPRO50 (a DV evolution from Panasonic) which brings 50Mbps at a 3.3:1 ratio (very similar to a Digital Betacam) is already possible to be transfered via firewire to a Mac using a converter and directly supported by Final Cut Pro. One year before this will just have been denied by every commercial NLE platform. Why? Because it has many commercial issues: if you don't need an expensive editing card, products like Adobe Premiere will lose money from their "partners" agreements (they have agrements with a lot of third-party editing cards). A lot of users are asking Premiere to support DVCPRO50 throught firewire, to enter it into the PC world, but do theybother to listen to this? No.

The same applies to a lot of other things. I'm talking about tpremiere because is one of the most well-known. In the latest professional version (a copy of Final Cut Pro), they removed the EDL support and replaced by another "similar" thing, that just a few post-production firms support. I don't see the user benefit from that. Add this feature if you want, but don't remove the older one.

And so on, and so on.. There's too much profit involved (which I respect, they're firms and that's normal to make money from their work) but users are just sufferinf from that behaviour.

As a potential user I can only see this project as heaven on hearth :) I mean, I don't really know if the NLE part of the project is to really create a complex system or just to allow some basic stuff (fadings, croos-disolves, etc...), but whatever it is going to be, i see it as an excellent thing. Good luck!

[ChristianHJW]

Short announcement :

After some internal discussion, we more or less decided that the QPL license is actually no good option for us, for various reasons. Sorry about the confusion, we maybe didnt check that well enough before making the announcement.

Please allow me to express a bing thanks to MfA, followed by my sincere apologies for my harsh reaction on his criticism. He was pointing us to the fact that the QPL license basically doesnt really prevent us from forks, but on the other hand will make us look like we plan to sell the software, because originally the trolltech intentions behind making this license were to be able to commercialize any changes that were applied to QT by 3rd party developers.

We herewith repeat, however, that we have no intentions to sell this software, or make any other commercial use from it. Therefore, and as the QPL license wont really help us a lot against 3rd parties forking from the project, we currently consider the follwing options :

- Make the project closed source, but release binaries as freeware
- Release the sourcecode without any license form, so that it is protected by the general copyright
- Create our own 'Corecodec Public License'
- Use the GPL, and trust in the support of the community if my paranoid worst case scenario would happen

Other than that, we'd be happy about some constructive input from the community on this matter, other than all the stupid flaming from the usual matroska haters/flamers ....

[bilu]

Originally posted by ChristianHJW
- Use the GPL, and trust in the support of the community if my paranoid worst case scenario would happen I agree with this license for the reasons I said above.
GPL forces everyone to release the source of every modification you make if your modified software ever goes public, commercially or not.

It's enough to avoid getting locked out, although the BSD licensing has proven that a community would rather improve the open-source software than to abandon it and use commercial software based on the same BSD code. Otherwise BSDs would be dead a long ago. :rolleyes:

My vote goes for GPL :)

Bilu

[mf]

Originally posted by ChristianHJW
[b]Other than that, we'd be happy about some constructive input from the community on this matter, other than all the stupid flaming from the usual matroska haters/flamers ....
Why would you think that even came to be?

[alexnoe]

Hit dogs will bark? :sly:

[Koepi]

Originally posted by mf
Why would you think that even came to be?

Well, this is just perfect advertisment (hm. someone into marketing here?) as usual to get "talked about" again. But this doesn't matter anymore, right? The license will be as it always was (something around GPL, maybe LGPL - i'm positive this was intended right from the start), but you can make a little FUD to get the name branded into people's minds.

Koepi

[mf]

The funny thing is that Chris says it like "anyone would want the same", while I have seen zero opinions that reflect his on this matter.

[bilu]

@Koepi

I agree with you. To quote a ChrisHJW post on this same thread:

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

So I need to ask to the Matroska team:

Have this community ever give the faintest impression of abandoning open-source projects for closed ones? :sly:

When I'm referring to this community I'm thinking in a larger one. We all know how much representative it is. And as I said before, even companies like Real or On2 realize that. So you have nothing to be afraid of, the rest of the world would probably react the same way :)

EDIT: When a project can't trust it's audience, it can't expect to be trusted either.


Bilu

[ChristianHJW]

Originally posted by bilu So I need to ask to the Matroska team: Have this community ever give the faintest impression of abandoning open-source projects for closed ones? :sly:
EDIT: When a project can't trust it's audience, it can't expect to be trusted either. Bilu .. huh ? my worst case scenario, to repeat this again, is that any large entity outside of this community would fork the project and remove all MKV related code, as they might see a disturbing factor in it. Sounds pretty paranoid, i know. But somehow, dont know why, i still have a bad feeling about using the GPL for this project. All rational arguments tell me GPL is the best, but this feeling doesnt go away, for whatever reason.

When i say we trust on the community, its about how you all would back up the project in case my worst case scenario would become true, thats about it.

Lets stop this better now, as the discussion is being looked at as blatant advertising again, and of course from the same people. The invitation to participate is out, we wont repeat it anymore. Next time you hear from us we will tell you what license we finally choose, how the scripting will look, and maybe we will have some working code already. So, lets say in about 4 - 9 months from now ;) ....

[bilu]

@ChrisHJW

One last remark: if you could choose a closed source product with less features than a free and open-source alternative, would you do it? ;)

Less features = Less audience

That's what would happen if a project removed MKV without adding some other REALLY GOOD features that would make you even think of it :)

And even that REALLY GOOD features can be implemented in open-souce, right? ;)

Look at the Samba project for example. Stop being paranoid :D


Bilu

[mf]

If someone added MP4 code and removed MKV code, it'd have to be licensed under GPL anyway, so you can merge the MP4 code back into the original codebase. You then have a product that does both MP4 and MKV, so more people will use it than the MP4-only thing :D. Oh wait, you guys are afraid of the MPEG-LA, so you don't want to merge back... :rolleyes:

[bond]

i think we all should be very thankfull that avery lee released his tool (one of the greatest open source tools every made maybe) under the GPL and realise what this meant to the community!!!

without this cyrius would have maybe never started in adding ogm and matroska support to it (and not to forget release a new tool, which noone accused of "evil forking the source") and the success story of these two containers would have maybe never happened the way as it was

of course all the work was done mainly by individuals but never forget the very important role of the GPL!

and of course noone can be forced to release his code under GPL but if someone does it, it should be respected even more!


btw about the fear someone could delete all matroska code...
why should someone do this? the result would be only that someone comes with a backup made before the "evil hacking" (thats even not much work if cvs is used)
-> result: the tool would be the same as before and the evil guy could be kicked from accessing the cvs

i doubt that anyone seriously would do something like that!

[bond]

hell, chris i think i told you already a thousand times that :D

mp4 is not limited to a specific range of codecs!
->
the mpeg-4 standard explicitely specifies how to put every codec you want into the mp4 container:
that way its already possible to put vorbis and vobsub into mp4!
thats not a hack!!!

also mp4 is not a subset of mov!
->
a small part of mp4 is based on the technology apple developed for mov (mainly the moov atom, which is one of "hundreds") but extended and changed it very much
mp4 offers much more possibilities than mov: for example show me how you can put things in mov like i did with creating a dvd menu in mp4...

if mp4 is 2 meters tall, mov is about 10 centimeters :D
hm thats enough "mine is bigger than yours" for now ;)

[avih]

@chris,
the GPL would be a good choice imho.

avih

[Neo Neko]

GPL would be nice. But any license that keeps the source open to the public at large but restricts big business use of it would be fine. Actually the GPL or l-GPL sould be more tha fine. If Gstreamer is going to be used it should be used at least in part for both the input and output framework. In this way any format that Gstreamer could support and might support this editor would support. Including *kof*MP4*kof*. So no worries about it getting forked.

It should probably be laid out something like this.

1. Gstreamer for basic IO and compression.
2. A scripting language "Gsynth" that could be used much as AVIsynth.
3. The editor or NLE script which could be a superset of "Gsynth".
4. The GUI.

This would keep the program as flexible as possible and would benefit the community in a large way. Not to mention the developers of the editor. It would aleviate the worries of forking and in a round about way alleviate the worries about integrating formats heavily laded with IP and copyright. MP4 input pligins might be as Xvid binaries now are. Not fully legal. But not hard to find.

[bilu]

Originally posted by Neo Neko
MP4 input pligins might be as Xvid binaries now are. Not fully legal. But not hard to find. http://forum.doom9.org/showthread.php?s=&postid=425298#post425298

:D


Bilu

[Wilbert]

Any updates? Did you guys actually start with this editor?

[Sirber]

Could be cool to keep mkvtoolnix, since RealAnime uses it for mkv management.

[multicone]

From #matroska, irc.corecodec.com :

<ChrisHJW> the whole world waiting for TCME
<ChrisHJW> if they unban me, i will reply :D

[spyder]

There is currently no work on this project. There was a small amount of stuff done initially but it died out due to a lack of hands. I'm currently coding a personal project which could be reused in such an app someday. As far as I know there is not much planned for TCME at the current moment.

[Shinigami-Sama]

aw thats suck... I was looking forwards to this. To bad I don't know any c/++ or asm, else I;d help