From moritz at bunkus.org  Thu Jan  1 15:06:01 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 1 Jan 2004 15:06:01 +0100
Subject: [Matroska-general] mkvtoolnix 0.8.0 released
Message-ID: <20040101140601.GK21226@bunkus.org>

Heya guys & maintainers,

I've released a new version of mkvtoolnix: 0.8.0. It is mainly a bug fix
release containing a number of small bug fixes (there was really no show
stopper this time ;)) but also support for the new and simpler tagging
system (still no tag editor, but it'll come soon).

As a side note to those interested: This release does already contain
code to create native MPEG4 files with proper B frame support and stuff,
but due to various reasons this code is not activated by default. It'll
come later. When I've got this working more or less then I'll probably
start workingon reading video from MP4 files.

The URLs:
http://www.bunkus.org/videotools/mkvtoolnix/
Sources:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-0.8.0.tar.bz2
Windows binaries:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.8.0.rar

Happy new year.

Here's the ChangeLog since 0.7.9:
---------------------------------
2004-01-01  Moritz Bunkus  <moritz at bunkus.org>

	* Released v0.8.0.

2003-12-29  Moritz Bunkus  <moritz at bunkus.org>

	* mmg: bug fix: Fixed the "write chapters to Matroska file"
	feature.

	* mmg: bug fix: Made mmg not abort but only display an error
	message when malformed XML chapter files should be loaded.

2003-12-28  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: The timescodes for Vorbis were calculated one
	packet too early (meaning that the first packet did not start at
	0).

	* mmg: Made "don't link" ON by default because some players might
	have problems with the second and all following files if they
	don't expect them not to start at 0.

	* mkvmerge, mkvextract, mkvinfo: Added support for the new tagging
	system.

	* mmg: bug fix: The default values for the chapter language and
	chapter country are now applied when loading simple (OGM) style
	chapter files as well.

	* mkvmerge: bug fix: The VobSub packetizer will assume MPEG2 if no
	MPEG version identifier was found ("Unsupported MPEG version:
	0x00...").

2003-12-23  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: There are MP4 files that actually contain HE-AAC but
	don't have the 5 byte identifier. mkvmerge will also assume SBR if
	there's only the 2 byte identifier with a sampling frequency <
	44100Hz.

2003-12-22  Moritz Bunkus  <moritz at bunkus.org>

	* mkvextract: bug fix: Wrong display output and illegal memory
	access when extracting FLAC files.

2003-12-17  Moritz Bunkus  <moritz at bunkus.org>

	* mmg: bug fix: If one added a Matroska file and the track name or
	language of a track consisted of only blanks then mmg would
	segfault. 

2003-12-15  Moritz Bunkus  <moritz at bunkus.org>

	* mmg: The input box will automatically select the first track
	when a file is selected. Upon track selection the input focus is
	set to the track name input box.

	* mmg: The chapter editor automatically focuses the chapter name
	input box whenever a chapter entry is selected.

	* mmg: bug fix: The chapter editor did not properly escape the
	chapter names resulting in invalid XML files if the special
	characters &, < or > were used.

2003-12-12  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: If splitting was active then a wrong CodecID
	was written to the second and all following files for MP2 tracks.
--------------------------

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From Liisachan at faireal.net  Sat Jan  3 07:03:23 2004
From: Liisachan at faireal.net (Liisachan)
Date: Sat, 03 Jan 2004 15:03:23 +0900
Subject: [Matroska-general] Re: VobSub SSA subtitles in matroska
In-Reply-To: <bsmabu$lab$1@sea.gmane.org>
References: <bsgoq8$eiv$1@sea.gmane.org> <bsmabu$lab$1@sea.gmane.org>
Message-ID: <3FF65B2B.8020406@faireal.net>

Yusaku wrote:

>http://www.anime.cz/s2v
>
>Version 1.0 released
>
>Yusaku
>
>
>
>_______________________________________________
>Matroska-general mailing list
>Matroska-general at lists.matroska.org
>http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-general
>
>
>  
>
Tested, and the result is fine,
as you said, just slightly worse than SSA.
I'm going to use your tool for a "real" purpose too: I'm multi-subbing now.
and i think this tool is perfect to make Tatar subs (Tatar is a language 
that is not easy to
handle on Windoes)...so I'll include 2 tracks for tatar, ssa and idx/sub

actually I had already made a short tutorial soon after you released it
http://www.faireal.net/articles/8/25/#d31229 with this sample
http://space34.at.infoseek.co.jp/ssa2vobsub.zip

I think the reason why this tool is great is properly understood here in 
Japan too.
On the other hand, I got more than one feedbacks about font embedding.
Font embedding should be better for some purposes.......

Well, I'd say your tool is highly maniac :D
General ppl are too lazy to make SSA while SSA is the starting point for 
your tool
I like it anyway :)

Liisachan

* <http://127.0.0.1/articles/8/25/#d31229>*


From Liisachan at faireal.net  Sat Jan  3 07:03:33 2004
From: Liisachan at faireal.net (Liisachan)
Date: Sat, 03 Jan 2004 15:03:33 +0900
Subject: [Matroska-general] Re: Guide change for matroska going 1.0 ?
In-Reply-To: <3FF205B4.3060509@matroska.org>
References: <3FF205B4.3060509@matroska.org>
Message-ID: <3FF65B35.5080903@faireal.net>

Christian HJ Wiesner wrote:

>
> Hi Liisachan,
>
> you know i am a big fan of your work. However, reading the matroska 
> Guides on http://ld-anime.faireal.net/guide/matroska-en , it still says :
>
>
>         Matroska is still in beta-testing.
>
> Despite all the promising features, Matroska is still not a practical 
> format to use at the moment. As of 7 June 2003, Matroska is still in 
> the beta stage (version 0.4.x.) Since Matroska has not stablized yet, 
> OGM is still the practical and realistic format to use.
>
>
> Please understand that we are now in the process of freezing the 
> container for a 1.0 release, and are leaving beta stage soon. Could 
> you then maybe change the Guides accordingly ?
>
> Thanks and all the best for 2004
>
> Christian

Well, I might edit that page and add newer info at a proper time.
You are right, needless to say we couldnt say "OGM is beter" anymore and
 I'm not going to recommend OGM because of that reason anymore
as it hasn't changed much while Matroska has been surprisingly improved.

That page says "As of 7 June 2003" very explicitly, with links to newer 
infos,
so technically it's not that wrong, but yes, I think I have to report 
about the new features now usable.

on the other hand, atm I think Matroska and things around it are still 
beta or beta-ish too

for one thing---IMHO, you 'll need a handy, safe, well-tested, 
minimalist installer for DirectShow filters just really needed,
in order to say that Matroska is now ready to use for everyone including 
newbies.

Matroska Pack 1.0.x comes with many files by default, like mmswitch and 
matrix mixer and even alpha-ish CoreFLAC:
This pack is causing quite a few problems, I know someone who had to 
restore his OS because of this,
I myself had to re-install OS because of CoreFLAC trouble.
Personally I'm OK with that as beta is like that by nature. I even like 
to try newest unstable versions

However, it would be great if Minimalist Install Pack would be available 
_for ordinary ppl_
which would install only STABLE versions of MatroskaSplitter, 
CoreVorbis, VSFilter--only these 3.
Generally, bloated codec packs like nimo are hated and labeled as dangerous,
( the true reason should be that DirectShow system is too delicate and 
not very reliable,
what is bad is not codec packs but OS.)
Ordinary ppl wouldn't do custom-install: they don't know what to do when 
filters are messed up either (Graphedit / Chage merit etc)

My page is not dev's but independent users'--practical memos for users 
by users--not for devs nor by devs--
so I might say "Test this carefully. The official page says its stable 
now but it's still beta-ish"
I'd say feely something like "Matroska is great: it can do this and this 
this and even this now!
But its not omnipotent: it has this problem and you ll have to be 
careful about it"
I assume that such info from the 3rd party will be useful.

After all, our pages exist not to evangelize with Matroska,
but just  to explain how to watch our fansubs ^^; (Or to explain why we 
should use this new format)
For instance, according to our tests, Matroska Pack 0.5 is safer than 
1.0.0-- i know this result is not what you want,
but users have different views

Christian, I'll update my site when I have time, but I hope you'll 
understand the nature of our pages.

Liisachan


From chris at matroska.org  Sat Jan  3 16:13:22 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 03 Jan 2004 16:13:22 +0100
Subject: [Matroska-general] Re: Guide change for matroska going 1.0 ?
In-Reply-To: <3FF65B35.5080903@faireal.net>
References: <3FF205B4.3060509@matroska.org> <3FF65B35.5080903@faireal.net>
Message-ID: <3FF6DC12.1040604@matroska.org>

Liisachan wrote:

> Well, I might edit that page and add newer info at a proper time.
> You are right, needless to say we couldnt say "OGM is beter" anymore and
> I'm not going to recommend OGM because of that reason anymore
> as it hasn't changed much while Matroska has been surprisingly improved.
> That page says "As of 7 June 2003" very explicitly, with links to 
> newer infos,
> so technically it's not that wrong, but yes, I think I have to report 
> about the new features now usable.

Thanks. It might interest you that we are now capable of finding 
reffered links in every hit we get on matroska.org. And ld-anime ranks 
2nd after google,with about 150 hits /  day to the matroska homepage :-) 
( google : about 500 ) !! Needless to say, we are very extremely happy 
and thankful about your Guides :-) ....

> on the other hand, atm I think Matroska and things around it are still 
> beta or beta-ish too

Any changes we make to the container specs themselves were always done 
with backwards compatibility in mind. We know there are a lot of 
matroska files out there already, and we will make sure these will 
always be spec compliant. But of course, i fully agree with respect to 
the tools for matroska creation/editing/playback .

> for one thing---IMHO, you 'll need a handy, safe, well-tested, 
> minimalist installer for DirectShow filters just really needed,
> in order to say that Matroska is now ready to use for everyone 
> including newbies.
> Matroska Pack 1.0.x comes with many files by default, like mmswitch 
> and matrix mixer and even alpha-ish CoreFLAC:
> This pack is causing quite a few problems, I know someone who had to 
> restore his OS because of this,
> I myself had to re-install OS because of CoreFLAC trouble.
> Personally I'm OK with that as beta is like that by nature. I even 
> like to try newest unstable versions

Of course, you could untick all these extra options and install only the 
basic stuff, but i am well aware nobody does that. Your idea is great, i 
will talk to Nibor about this as soon as possible.

> However, it would be great if Minimalist Install Pack would be 
> available _for ordinary ppl_
> which would install only STABLE versions of MatroskaSplitter, 
> CoreVorbis, VSFilter--only these 3.
> Generally, bloated codec packs like nimo are hated and labeled as 
> dangerous,
> ( the true reason should be that DirectShow system is too delicate and 
> not very reliable,
> what is bad is not codec packs but OS.)
> Ordinary ppl wouldn't do custom-install: they don't know what to do 
> when filters are messed up either (Graphedit / Chage merit etc)

Yes, consider it done ;-) ....

> My page is not dev's but independent users'--practical memos for users 
> by users--not for devs nor by devs--
> so I might say "Test this carefully. The official page says its stable 
> now but it's still beta-ish"
> I'd say feely something like "Matroska is great: it can do this and 
> this this and even this now!
> But its not omnipotent: it has this problem and you ll have to be 
> careful about it"
> I assume that such info from the 3rd party will be useful. 

As mentioned above, your independant reports are extremely helpful for 
us. Please continue reporting about our project, and if you feel 
matroska has problems about this or another feature, we wont mind you 
telling your readers.

> After all, our pages exist not to evangelize with Matroska,

:O ....... i would never expect this from you .....

> but just  to explain how to watch our fansubs ^^; (Or to explain why 
> we should use this new format)
> For instance, according to our tests, Matroska Pack 0.5 is safer than 
> 1.0.0-- i know this result is not what you want,
> but users have different views

Hmmm ..... you are aware you cant use the new mkvmerge then, as the 
filter in the old pack wont support the new lacing sheme .. but i guess 
you know how to deactivate the new lacing in mkvmerge.

> Christian, I'll update my site when I have time, but I hope you'll 
> understand the nature of our pages.
> Liisachan 

Thanks again Liisachan :-) !!

Christian



From steve.lhomme at free.fr  Sun Jan  4 11:12:36 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 04 Jan 2004 11:12:36 +0100
Subject: [Matroska-general] MKV search
Message-ID: <3FF7E714.1070001@free.fr>

I was just wondering how easy it would be for a user to know what do 
with an MKV file downloaded from eMule and has no clue of what it is. So 
I searched for MKV on Google and here is what I found :

http://www.google.com/search?q=MKV&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8

No mention of Matroska on the first page. So I guess we need to make a 
webpage that mention this extension a few times to be upper in the 
Google engine.

Also on the eMule side, I unfortunately don't have enough time, but I 
wanted to add "Matroska support" to the client. Ie have all the same 
features than for AVI an even more (a more intelligent preview 
possibility for example, read tags, codec informations, maybe a link to 
get the Matroska pack, etc). Would anyone volunteer to do that ? It 
should not be very complicated. But it depends wether they accept C++ 
code and how messy their code is...




From steve.lhomme at free.fr  Sun Jan  4 11:14:26 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 04 Jan 2004 11:14:26 +0100
Subject: [Matroska-general] New VLC 0.7.0
Message-ID: <3FF7E782.8020504@free.fr>

Apparently it can read subs in Matroska and HE-AAC (from Matroska too 
?). That's a good news IMO. I wonder if they updated their Matroska/EBML 
libraries for the new builds. Anyone have info on this ?



From steve.lhomme at free.fr  Sun Jan  4 11:16:40 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 04 Jan 2004 11:16:40 +0100
Subject: [Matroska-general] New VLC 0.7.0
In-Reply-To: <3FF7E782.8020504@free.fr>
References: <3FF7E782.8020504@free.fr>
Message-ID: <3FF7E808.5060009@free.fr>

Steve Lhomme wrote:

> Apparently it can read subs in Matroska and HE-AAC (from Matroska too 
> ?). That's a good news IMO. I wonder if they updated their Matroska/EBML 
> libraries for the new builds. Anyone have info on this ?

http://www.videolan.org/vlc/download-sources.html

# libebml-20030811.tar.bz2 (A form of binary XML)
# libmatroska-20030811.tar.bz2 (A open source container format)

I *highly* suggest that we contact them and change that ASAP ! They 
can't even read "new" files with the latest lacing code IIRC. And there 
are probably some "medium" bugs unsolved in these versions.



From chris at matroska.org  Sun Jan  4 12:23:15 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 04 Jan 2004 12:23:15 +0100
Subject: [Matroska-general] New VLC 0.7.0
In-Reply-To: <3FF7E808.5060009@free.fr>
References: <3FF7E782.8020504@free.fr> <3FF7E808.5060009@free.fr>
Message-ID: <3FF7F7A3.2070302@matroska.org>

Steve,

I did this already, i visit the #videolan channel from time to time and 
talk to the guys, but apparently they lost interest in supporting 
matroska's last features for the time being, maybe we implemented new 
features faster than they could support them ;-) ( they cant support RV9 
in MKV, same goes for SSA, and this makes many files incompatible ). 
Maybe this lack of interest would change also if we go 1.0, so this is 
actually putting water on Pamel's mills. Still, i want
- control tracks
- MPEG1/2 video
- menues
before we finally go 1.0  :P ... even if this means waiting 2 - 3 more 
months.

Christian

Steve Lhomme wrote:

> Steve Lhomme wrote:
>
>> Apparently it can read subs in Matroska and HE-AAC (from Matroska too 
>> ?). That's a good news IMO. I wonder if they updated their 
>> Matroska/EBML libraries for the new builds. Anyone have info on this ?
>
>
> http://www.videolan.org/vlc/download-sources.html
>
> # libebml-20030811.tar.bz2 (A form of binary XML)
> # libmatroska-20030811.tar.bz2 (A open source container format)
>
> I *highly* suggest that we contact them and change that ASAP ! They 
> can't even read "new" files with the latest lacing code IIRC. And 
> there are probably some "medium" bugs unsolved in these versions.
>
> _______________________________________________
> Matroska-general mailing list
> Matroska-general at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-general
>




From chris at matroska.org  Sun Jan  4 12:26:13 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 04 Jan 2004 12:26:13 +0100
Subject: [Matroska-general] MKV search
In-Reply-To: <3FF7E714.1070001@free.fr>
References: <3FF7E714.1070001@free.fr>
Message-ID: <3FF7F855.2020605@matroska.org>

Steve Lhomme wrote:

> I was just wondering how easy it would be for a user to know what do 
> with an MKV file downloaded from eMule and has no clue of what it is. 
> So I searched for MKV on Google and here is what I found :
> http://www.google.com/search?q=MKV&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8 
>
> No mention of Matroska on the first page. So I guess we need to make a 
> webpage that mention this extension a few times to be upper in the 
> Google engine.
> Also on the eMule side, I unfortunately don't have enough time, but I 
> wanted to add "Matroska support" to the client. Ie have all the same 
> features than for AVI an even more (a more intelligent preview 
> possibility for example, read tags, codec informations, maybe a link 
> to get the Matroska pack, etc). Would anyone volunteer to do that ? It 
> should not be very complicated. But it depends wether they accept C++ 
> code and how messy their code is...


Cyt0plas can certainly help here !!!  .mkv is well defined in all the 
well know FileExtension libraries now, and i found that many of the 
referred links that are reported by cyt0plas's new hit counter are 
coming from this link :

http://filext.com/detaillist.php?extdetail=mkv

All we need to do now is to find a way to push this link into the search 
engines ....

Christian



From steve.lhomme at free.fr  Sun Jan  4 12:36:33 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 04 Jan 2004 12:36:33 +0100
Subject: [Matroska-general] New VLC 0.7.0
In-Reply-To: <3FF7F7A3.2070302@matroska.org>
References: <3FF7E782.8020504@free.fr> <3FF7E808.5060009@free.fr>
	<3FF7F7A3.2070302@matroska.org>
Message-ID: <3FF7FAC1.6080504@free.fr>

Christian HJ Wiesner wrote:

> Steve,
> 
> I did this already, i visit the #videolan channel from time to time and 
> talk to the guys, but apparently they lost interest in supporting 
> matroska's last features for the time being, maybe we implemented new 
> features faster than they could support them ;-) ( they cant support RV9 
> in MKV, same goes for SSA, and this makes many files incompatible ). 

It sucks, they just need to put the new libs on their site, take Mosu's 
patch, and they're done (for the next release). It takes about 1h max to 
do that.


> Maybe this lack of interest would change also if we go 1.0, so this is 
> actually putting water on Pamel's mills. Still, i want
> - control tracks
> - MPEG1/2 video
> - menues
> before we finally go 1.0  :P ... even if this means waiting 2 - 3 more 
> months.

Control Track don't need extra support in the format/lib. It's just a 
codec... Maybe there could be a list of possible interactions with the 
player needed by the track. That way a player/system will know if it can 
or cannot support this track.

For the MPEG I wish spyder would stop trying useless solutions and have 
something working. It doesn't matter if it's clean.

I'm working on the menu. I hope to have the format of the data almost 
done in a few days. Then I'll see with Mosu on how to mux a basic file 
in a movie. And then I can see with the Matroska Splitter (and Gabest 
and Toff) how to interpret it in MPC and TCMP. (as the Control Track 
codec needs to talk to the player)



From paul at msn.com  Sun Jan  4 16:31:46 2004
From: paul at msn.com (Paul Bryson)
Date: Sun, 4 Jan 2004 09:31:46 -0600
Subject: [Matroska-general] Re: New VLC 0.7.0
References: <3FF7E782.8020504@free.fr> <3FF7E808.5060009@free.fr>
	<3FF7F7A3.2070302@matroska.org>
Message-ID: <bt9bkc$92h$1@sea.gmane.org>

"Christian HJ Wiesner" wrote...
> Maybe this lack of interest would change also if we go 1.0, so this is
> actually putting water on Pamel's mills. Still, i want
> - control tracks
> - MPEG1/2 video
> - menues
> before we finally go 1.0  :P ... even if this means waiting 2 - 3 more
> months.

It won't be 2-3 months.  It will be at least 6 months to get a good
implementation of the menus, and that is being generous as it would probably
take much longer.  Writing specs is one thing, getting the menus to exist and to
play back in something is completely different.  There isn't much in the way of
programs that will play back normal DVD menus, and loads of people have been
working on that for years.


Pamel





From steve.lhomme at free.fr  Sun Jan  4 16:37:42 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 04 Jan 2004 16:37:42 +0100
Subject: [Matroska-general] Re: New VLC 0.7.0
In-Reply-To: <bt9bkc$92h$1@sea.gmane.org>
References: <3FF7E782.8020504@free.fr>
	<3FF7E808.5060009@free.fr>	<3FF7F7A3.2070302@matroska.org>
	<bt9bkc$92h$1@sea.gmane.org>
Message-ID: <3FF83346.6000200@free.fr>

Paul Bryson wrote:

> It won't be 2-3 months.  It will be at least 6 months to get a good
> implementation of the menus, and that is being generous as it would probably
> take much longer.  Writing specs is one thing, getting the menus to exist and to
> play back in something is completely different.  There isn't much in the way of
> programs that will play back normal DVD menus, and loads of people have been
> working on that for years.

It's good to see how you trust our working force ;)
Look at what we did in a short time (even in "internet time").

I'm not going to build a menu system that can do everything under the 
sun. I think in 1 or 2 months it could be working.

For the MPEG, it is supposedly possible/working for months but strangely 
we have no code to prove it ;)

And for the control track, that's just as I said. Maybe I'll check with 
bond to see if BIFS need some extra data than just the ones in the 
Control Track.



From paul at msn.com  Sun Jan  4 17:17:23 2004
From: paul at msn.com (Paul Bryson)
Date: Sun, 4 Jan 2004 10:17:23 -0600
Subject: [Matroska-general] Re: Re: New VLC 0.7.0
References: <3FF7E782.8020504@free.fr><3FF7E808.5060009@free.fr>	<3FF7F7A3.2070302@matroska.org><bt9bkc$92h$1@sea.gmane.org>
	<3FF83346.6000200@free.fr>
Message-ID: <bt9e9s$dfc$1@sea.gmane.org>

"Steve Lhomme" wrote...
> Paul Bryson wrote:
> > It won't be 2-3 months.  It will be at least 6 months to get a good
> > implementation of the menus, and that is being generous as it would probably
> > take much longer.  Writing specs is one thing, getting the menus to exist
and to
> > play back in something is completely different.  There isn't much in the way
of
> > programs that will play back normal DVD menus, and loads of people have been
> > working on that for years.
>
> It's good to see how you trust our working force ;)
> Look at what we did in a short time (even in "internet time").

Yes, but just getting reading working took coding from Febuary to May of last
year.  And that was just to pass packets to existing systems.  You want to
create a whole new system to pass stuff to.

> I'm not going to build a menu system that can do everything under the
> sun. I think in 1 or 2 months it could be working.

Again, there isn't an easy solution for this.  Where are the menus going to be
played back?  Specific support could maybe be added to TCMP, but what else could
support it?


Pamel





From steve.lhomme at free.fr  Sun Jan  4 18:21:12 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 04 Jan 2004 18:21:12 +0100
Subject: [Matroska-general] Re: Re: New VLC 0.7.0
In-Reply-To: <bt9e9s$dfc$1@sea.gmane.org>
References: <3FF7E782.8020504@free.fr><3FF7E808.5060009@free.fr>	<3FF7F7A3.2070302@matroska.org><bt9bkc$92h$1@sea.gmane.org>	<3FF83346.6000200@free.fr>
	<bt9e9s$dfc$1@sea.gmane.org>
Message-ID: <3FF84B88.5090304@free.fr>

Paul Bryson wrote:

>>I'm not going to build a menu system that can do everything under the
>>sun. I think in 1 or 2 months it could be working.
> 
> 
> Again, there isn't an easy solution for this.  Where are the menus going to be
> played back?  Specific support could maybe be added to TCMP, but what else could
> support it?

Even if one player does, it's enough. It could be handled transparently 
by something like DVobSub/vsfilter by all apps that can use DVobSub.

As I said on IRC. There is something not covered yet by the specs that 
need to be addressed : not playing some parts of a file (out of chapters 
for example).



From spyder at matroska.org  Sun Jan  4 22:17:42 2004
From: spyder at matroska.org (John Cannon)
Date: Sun, 04 Jan 2004 15:17:42 -0600
Subject: [Matroska-general] New VLC 0.7.0
In-Reply-To: <3FF7FAC1.6080504@free.fr>
References: <3FF7E782.8020504@free.fr>
	<3FF7E808.5060009@free.fr>	<3FF7F7A3.2070302@matroska.org>
	<3FF7FAC1.6080504@free.fr>
Message-ID: <3FF882F6.2030800@matroska.org>


> For the MPEG I wish spyder would stop trying useless solutions and 
> have something working. It doesn't matter if it's clean.


Hmmm, I'm not sure what the useless solutions were but I have a working 
reader for MPEG2 and jcsston has almost finished a working 
muxer(supporting references) which I will use.  I am making a deadline 
of next weekend to have a working (maybe buggy) transmuxer.  If I don't 
make the deadline feel free to beat me up ;)

Spyder



From steve.lhomme at free.fr  Sun Jan  4 22:28:37 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 04 Jan 2004 22:28:37 +0100
Subject: [Matroska-general] New VLC 0.7.0
In-Reply-To: <3FF882F6.2030800@matroska.org>
References: <3FF7E782.8020504@free.fr>	<3FF7E808.5060009@free.fr>	<3FF7F7A3.2070302@matroska.org>	<3FF7FAC1.6080504@free.fr>
	<3FF882F6.2030800@matroska.org>
Message-ID: <3FF88585.4030000@free.fr>

John Cannon wrote:

> 
>> For the MPEG I wish spyder would stop trying useless solutions and 
>> have something working. It doesn't matter if it's clean.
> 
> 
> 
> Hmmm, I'm not sure what the useless solutions were but I have a working 
> reader for MPEG2 and jcsston has almost finished a working 
> muxer(supporting references) which I will use.  I am making a deadline 
> of next weekend to have a working (maybe buggy) transmuxer.  If I don't 
> make the deadline feel free to beat me up ;)

I save this email somewhere...
;)



From moritz at bunkus.org  Tue Jan  6 01:17:34 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 6 Jan 2004 01:17:34 +0100
Subject: [Matroska-general] mkvtoolnix 0.8.1 released
Message-ID: <20040106001734.GA27716@bunkus.org>

Heya list & package maintainers,

the second release in 2004 right after 0.8.0 is 0.8.1. It fixes three
important things, and though I'm quite annoyed at having introduced the
first with 0.8.0 in the first place I'm as pleased to have finally fixed
the other two.

The first bug, introduced with 0.8.0, made muxing RealVideo impossible
(resulting in segfaults / invalid memory access etc.). This bugfix
changed two lines of code.

The second bug fixes the parsing of QuickTime/MP4 files for some special
atom sizes. This mostly affects MP4 files created by NeroDigital and
consists of eight lines of source code being moved down one line.

The third bug fixes the VobSub handling on Windows getting rid of these
illegal memory access / "mkvmerge exited with an error
-13905490871395". The bugfix is exactly one line long.

You see, small changes with big results.

The URLs:
http://www.bunkus.org/videotools/mkvtoolnix/
The source:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-0.8.1.tar.bz2
And the Windows binaries:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.8.1.rar

The ChangeLog:
-------------------------
2004-01-06  Moritz Bunkus  <moritz at bunkus.org>

	* Released v0.8.1.

2004-01-05  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: The I/O classes were not initialized
	correctly on Windows resulting in spontaneous strange error
	messages, especially when muxing VobSubs.

2004-01-03  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: For some special atom sizes in Quicktime and
	MP4 files the size was not read correctly. This affected
	e.g. files created by Nero Digital.

2004-01-02  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: Segfault when muxing some video formats due
	to unchecked data (includes RealVideo).
----------------

Have a pleasant day :)

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From Liisachan at faireal.net  Tue Jan  6 05:15:50 2004
From: Liisachan at faireal.net (Liisachan)
Date: Tue, 06 Jan 2004 13:15:50 +0900
Subject: [Matroska-general] Codec Pack Not Work for Win98
In-Reply-To: <3FF6DC12.1040604@matroska.org>
References: <3FF205B4.3060509@matroska.org> <3FF65B35.5080903@faireal.net>
	<3FF6DC12.1040604@matroska.org>
Message-ID: <3FFA3676.4040302@faireal.net>

Christian HJ Wiesner wrote:

>> but just  to explain how to watch our fansubs ^^; (Or to explain why 
>> we should use this new format)
>> For instance, according to our tests, Matroska Pack 0.5 is safer than 
>> 1.0.0-- i know this result is not what you want,
>> but users have different views
>
>
> Hmmm ..... you are aware you cant use the new mkvmerge then, as the 
> filter in the old pack wont support the new lacing sheme .. but i 
> guess you know how to deactivate the new lacing in mkvmerge.

I know I have to "disable lacing" when I use MKVmerge, and I m doing so.

The biggest problem is, Win 98 users cannot replay MKV files at all if 
they install Codec Packs 0.6+

I'm not absolutely sure, but in my test, the last Splitter that works 
for Win 98 is 1.0.1.5 dated July.
Of cource I'm using "Release" build, not "Unicode Release", when testing 
on Win98

So, I'm guessing if you recommended a codec pack for general ppl 
including win98 users, v0.5 would be the only one possibility.
I'd rather recommend MPC, because it does work for win98 altho DirectX9 
is needed.

Liisachan



From Liisachan at faireal.net  Tue Jan  6 05:36:18 2004
From: Liisachan at faireal.net (Liisachan)
Date: Tue, 06 Jan 2004 13:36:18 +0900
Subject: [Matroska-general] Codec  Pack Prob2
In-Reply-To: <3FFA3676.4040302@faireal.net>
References: <3FF205B4.3060509@matroska.org>
	<3FF65B35.5080903@faireal.net>	<3FF6DC12.1040604@matroska.org>
	<3FFA3676.4040302@faireal.net>
Message-ID: <3FFA3B42.6060800@faireal.net>

Another thing I have to point out is, ... Codec pack 0.5 & 0.6 will 
install files to "Matroska Playback Pack"
while  v1.0.0+ will install files to a different directory, "Matroska Pack"
without cleaning up the old files even if you have 0.5 or 0.6,
causing 2 entries in Add/Remove Programs: "Matroska Playback Pack" and 
"Matroska Pack"
It's not very beautiful, and can be confusing.....

Regards
Liisachan


From steve.lhomme at free.fr  Tue Jan  6 09:35:10 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 06 Jan 2004 09:35:10 +0100
Subject: [Matroska-general] mkvtoolnix 0.8.1 released
In-Reply-To: <20040106001734.GA27716@bunkus.org>
References: <20040106001734.GA27716@bunkus.org>
Message-ID: <3FFA733E.3030801@free.fr>

> The URLs:
> http://www.bunkus.org/videotools/mkvtoolnix/
> The source:
> http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-0.8.1.tar.bz2
> And the Windows binaries:
> http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.8.1.rar

Are these binaries made with libmatroska 0.6.3 ? (from CVS)



From moritz at bunkus.org  Tue Jan  6 10:02:48 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 6 Jan 2004 10:02:48 +0100
Subject: [Matroska-general] mkvtoolnix 0.8.1 released
In-Reply-To: <3FFA733E.3030801@free.fr>
References: <20040106001734.GA27716@bunkus.org> <3FFA733E.3030801@free.fr>
Message-ID: <20040106090248.GC27716@bunkus.org>

Heya,

> Are these binaries made with libmatroska 0.6.3 ? (from CVS)

No, the Linux ones with 0.6.2, the Windows ones against CVS which hasn't
been updated for the last few days.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Wed Jan  7 10:21:19 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 07 Jan 2004 10:21:19 +0100
Subject: [Matroska-general] Spec freezing
Message-ID: <3FFBCF8F.2070400@free.fr>

As you know we'll be soon going into Round 3. Which is, according to the 
specs :

     * Round 1: first complete draft of the specs
     * Round 2: start the alpha development of libmatroska and update 
the specs when needed
     * Round 3: start the beta development of libmatroska, the specs are 
frozen (no changes possible, only additions)
     * Round 4: libmatroska becomes final (1.0.0) and the format too 
(version 1)

The specs could still have some last minutes addition this week and the 
following week (see the sample accurate seeking). Then we'll go into 
Round 3.

libmatroska and libebml already support everything that are in the 
version 1 specs and even more... I suggest to make all elements that 
have been removed from version 1 available with something like :
#define MATROSKA_VERSION 2

The default build value of MATROSKA_VERSION will be 1 for now (should be 
used in the EBML header of the file too).

Also, there are lots of weird features that are probably untested right 
now. I'm almost sure all the scales (timecode, samples, etc) are not 
handled well in most implementations. So I suggest that for each feature 
we make a test file (or mix many features in the same file). That way we 
can easily test players for "1. Matroska compatibility". These files 
should be produced with mkvmerge as it's the program that allow the most 
features in Matroska...

Files that don't meet the specs could also be produced. But the handling 
of these files are not covered by the specs... But we can at least 
produce EBML files that are not matroska files (DocType != "matroska") 
or with version numbers that a current player is not supposed to handle 
(DocTypeReadVersion == 2). These files should not play or crash current 
players.

I'll make my best to have the MatroskaSplitter support all features of 
"Matroska 1." and be the first "Matroska 1. compatible" program. A kind 
of reference code and feature demonstration...



From steve.lhomme at free.fr  Wed Jan  7 10:25:53 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 07 Jan 2004 10:25:53 +0100
Subject: [Matroska-general] Spec freezing
In-Reply-To: <3FFBCF8F.2070400@free.fr>
References: <3FFBCF8F.2070400@free.fr>
Message-ID: <3FFBD0A1.7030102@free.fr>

> I'll make my best to have the MatroskaSplitter support all features of 
> "Matroska 1." and be the first "Matroska 1. compatible" program. A kind 
> of reference code and feature demonstration...

One of the thing I'd also like to test is wether it can handle Master 
elements with an "Unknown Size".



From spyder at matroska.org  Thu Jan  8 00:21:46 2004
From: spyder at matroska.org (John Cannon)
Date: Wed, 07 Jan 2004 17:21:46 -0600
Subject: [Matroska-general] New VLC 0.7.0
In-Reply-To: <3FF88585.4030000@free.fr>
References: <3FF7E782.8020504@free.fr>	<3FF7E808.5060009@free.fr>	<3FF7F7A3.2070302@matroska.org>	<3FF7FAC1.6080504@free.fr>	<3FF882F6.2030800@matroska.org>
	<3FF88585.4030000@free.fr>
Message-ID: <3FFC948A.4000406@matroska.org>

Steve Lhomme wrote:

> John Cannon wrote:
>
>>
>>> For the MPEG I wish spyder would stop trying useless solutions and 
>>> have something working. It doesn't matter if it's clean.
>>
>>
>>
>>
>> Hmmm, I'm not sure what the useless solutions were but I have a 
>> working reader for MPEG2 and jcsston has almost finished a working 
>> muxer(supporting references) which I will use.  I am making a 
>> deadline of next weekend to have a working (maybe buggy) transmuxer.  
>> If I don't make the deadline feel free to beat me up ;)
>
>
> I save this email somewhere...
> ;)

I made it!  Well, I am very very close.  I have an MKV here with a 3 
minute video clip in MPEG2 inside(correct references and timecodes, 
durations aren't written yet but that appears to be a bug in Jory's 
muxing code, I haven't looked).  I can't play it of course as no 
splitter wants to output it right(and even if they did i am still 
missing the sequence header in the private data).  I have to figure out 
how to get the sequence header from libavformat, if that's possible.  
The code also has issues with open GOPs but I'll resolve that somehow 
later.  The important thing is that it's working :)  Once i have the 
sequence header fixed it will be testable.  BTW, I've had this working 
for almost 24 hours but the dsl tech left our phoneline unplugged ;)

Spyder


From steve.lhomme at free.fr  Thu Jan  8 09:40:01 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 08 Jan 2004 09:40:01 +0100
Subject: [Matroska-general] New VLC 0.7.0
In-Reply-To: <3FFC948A.4000406@matroska.org>
References: <3FF7E782.8020504@free.fr>	<3FF7E808.5060009@free.fr>	<3FF7F7A3.2070302@matroska.org>	<3FF7FAC1.6080504@free.fr>	<3FF882F6.2030800@matroska.org>	<3FF88585.4030000@free.fr>
	<3FFC948A.4000406@matroska.org>
Message-ID: <3FFD1761.6020802@free.fr>

John Cannon wrote:

> I made it!  Well, I am very very close.  I have an MKV here with a 3 
> minute video clip in MPEG2 inside(correct references and timecodes, 
> durations aren't written yet but that appears to be a bug in Jory's 
> muxing code, I haven't looked).  I can't play it of course as no 
> splitter wants to output it right(and even if they did i am still 
> missing the sequence header in the private data).  I have to figure out 
> how to get the sequence header from libavformat, if that's possible.  
> The code also has issues with open GOPs but I'll resolve that somehow 
> later.  The important thing is that it's working :)  Once i have the 
> sequence header fixed it will be testable.  BTW, I've had this working 
> for almost 24 hours but the dsl tech left our phoneline unplugged ;)

Very good. Maybe you could get in touch with Toff or Gabest to have the 
correct UUID and codec init for an MPEG2 decoder. As there is the 
possibility to have DVD playback under TCMP and MPC I guess they know 
what needs to be done in the Matroska Splitter.



From chris at matroska.org  Sat Jan 10 09:45:19 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 10 Jan 2004 09:45:19 +0100
Subject: [Matroska-general] koepi leaving XviD team
Message-ID: <3FFFBB9F.7030506@matroska.org>


Hi,

koepi's anger about matroska's success was obviously causing an overload 
yesterday, resulting in some serious flaming and insulting from him 
towards the matroska team, followed by a kick-ban from Edouard Gomez, 
who has now founder rights on #xvid freenode.net. He then decided to 
leave the team :

http://roeder.goe.net/~koepi/xvid.shtml

IMHO he had too much alcohol yesterday night, and i very much hope he 
will regret his decision and join the XviD team ...... its very 
unfortunate that this has happened, but pls. note that no matroska 
people were involved, so nobody can blame us for that.

Christian



From steve.lhomme at free.fr  Sat Jan 10 23:41:00 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 10 Jan 2004 23:41:00 +0100
Subject: [Matroska-general] Matroska in RealPlayer
Message-ID: <40007F7C.8010903@free.fr>

You all know that one of the thing we're missing now is support from an 
industry leader. That would help us go on and make Matroska a known and 
trusted alternative to AVI.

Now it seems that it could come from the side of Real Networks. Karl 
Lillevold from Real said this on Doom9 :

"It would be fantastic if someone wrote a Matroska file-writer plugin 
for Producer. I am pretty sure we would then distribute this file-writer 
with Milestone builds of Helix Producer 10."

http://forum.doom9.org/showthread.php?s=&postid=425891#post425891

So I think we should try to spend some time there !!!

"If there is a volunteer, I would be more than happy to assist as much 
as I can, even though I will have to forward many questions to the 
Producer team."



From moritz at bunkus.org  Sun Jan 11 00:27:39 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 11 Jan 2004 00:27:39 +0100
Subject: [Matroska-general] Re: [Matroska-devel] Matroska in RealPlayer
In-Reply-To: <40007F7C.8010903@free.fr>
References: <40007F7C.8010903@free.fr>
Message-ID: <20040110232739.GP30186@bunkus.org>

Heya,

this sounds pretty cool, but I won't be able to help. As some of you
know I will be more than busy in the next six to seven weeks with part
of my diploma thesis.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Sun Jan 11 00:54:45 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 11 Jan 2004 00:54:45 +0100
Subject: [Matroska-general] Re: [Matroska-devel] Matroska in RealPlayer
In-Reply-To: <20040110232739.GP30186@bunkus.org>
References: <40007F7C.8010903@free.fr> <20040110232739.GP30186@bunkus.org>
Message-ID: <400090C5.5060508@free.fr>

Moritz Bunkus wrote:

> Heya,
> 
> this sounds pretty cool, but I won't be able to help. As some of you
> know I will be more than busy in the next six to seven weeks with part
> of my diploma thesis.

No problem. I may do it myself.



From steve.lhomme at free.fr  Sun Jan 11 10:45:44 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 11 Jan 2004 10:45:44 +0100
Subject: [Matroska-general] Re: [Matroska-devel] Matroska in RealPlayer
In-Reply-To: <400090C5.5060508@free.fr>
References: <40007F7C.8010903@free.fr> <20040110232739.GP30186@bunkus.org>
	<400090C5.5060508@free.fr>
Message-ID: <40011B48.4020802@free.fr>

Apparently there are different kinds of licenses for adding code in the 
Helix platform.

https://www.helixcommunity.org/content/licenses

I don't understand if you have to choose a license or not. But if so, it 
seems that the RPSL is a very good choice :

"RealNetworks Public Source License (RPSL) - no-cost copyleft open 
source license which requires your entire application to be open sourced."

"This license has been approved by the Open Source Initiative as an open 
source license.  It contains some "copyleft" provisions along the lines 
of the GPL, but also clears up patent issues and allows contributed 
changes to be put back into the pool for the entire community.  Hence, 
the RPSL gives you the right to develop and distribute Helix DNA, but 
modifications to the Helix DNA itself need to be supplied back to the 
community under the RPSL.  Also, applications built using the Helix DNA 
must be released wholly as open source."

So I assume it's *very* compatible with the QPL license in 
libmatroska/libebml that states that the application has to be open 
sourced too.

Now I hope we don't have to make libmatroska/libebml RSPL too... Well, 
we could use a triple-license, instead of the current dual-license 
state... But I think we don't need to change this way :

https://www.helixcommunity.org/content/complicense



From kyle.katarn at katarncorp.com  Tue Jan 13 13:07:19 2004
From: kyle.katarn at katarncorp.com (Kyle Katarn)
Date: Tue, 13 Jan 2004 13:07:19 +0100
Subject: [Matroska-general] Matroska Specifications
Message-ID: <001401c3d9cd$cb894580$8e7bd486@Kyle>

Hello,

I'm working on a Matroska-compliant Codec Viewer (VideoToolbox - ftp://ftp2.katarncorp.com/katarnco/beta/videotoolbox.exe ) and i need some help with the specifications :

(by "how can i", i mean "in which part of the segment")
How can i retreive Video & Audio Bitrate ?
How can i retreive total duration ?

Regards,

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-general/attachments/20040113/41ce6f66/attachment.html>

From moritz at bunkus.org  Tue Jan 13 13:23:19 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 13 Jan 2004 13:23:19 +0100
Subject: [Matroska-general] Matroska Specifications
In-Reply-To: <001401c3d9cd$cb894580$8e7bd486@Kyle>
References: <001401c3d9cd$cb894580$8e7bd486@Kyle>
Message-ID: <20040113122319.GW30186@bunkus.org>

Heya,

> (by "how can i", i mean "in which part of the segment")
> How can i retreive Video & Audio Bitrate ?

This information is not always stored, e.g. mkvmerge does not write
these elements yet. 

> How can i retreive total duration ?

This is the 'duration' element under the 'segment information' (KaxInfo)
object.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From kyle.katarn at katarncorp.com  Tue Jan 13 13:45:32 2004
From: kyle.katarn at katarncorp.com (Kyle Katarn)
Date: Tue, 13 Jan 2004 13:45:32 +0100
Subject: [Matroska-general] subscribe
Message-ID: <006601c3d9d3$219cd900$8e7bd486@Kyle>

An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-general/attachments/20040113/7a8ed1ea/attachment.html>

From steve.lhomme at free.fr  Wed Jan 14 16:58:18 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 14 Jan 2004 16:58:18 +0100
Subject: [Matroska-general] Gstreamer
Message-ID: <4005671A.9050600@free.fr>

A good article on GStreamer :
http://www.osnews.com/story.php?news_id=5648



From moritz at bunkus.org  Wed Jan 14 17:13:18 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 14 Jan 2004 17:13:18 +0100
Subject: [Matroska-general] Gstreamer
In-Reply-To: <4005671A.9050600@free.fr>
References: <4005671A.9050600@free.fr>
Message-ID: <20040114161318.GC30186@bunkus.org>

Heya,

> A good article on GStreamer :
> http://www.osnews.com/story.php?news_id=5648

Yes, Ronald and I have already talked about it a bit. This article is
also linked to on /. with a couple of interesting comments (and a couple
of trollish comments, but that's /.):
http://developers.slashdot.org/article.pl?sid=04/01/13/2043223&mode=thread&tid=131&tid=188&tid=189

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Wed Jan 14 17:19:00 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 14 Jan 2004 17:19:00 +0100
Subject: [Matroska-general] Gstreamer
In-Reply-To: <20040114161318.GC30186@bunkus.org>
References: <4005671A.9050600@free.fr> <20040114161318.GC30186@bunkus.org>
Message-ID: <40056BF4.1050803@free.fr>

Moritz Bunkus wrote:

> Heya,
> 
> 
>>A good article on GStreamer :
>>http://www.osnews.com/story.php?news_id=5648

"Another interesting development is that we currently got a team of 
about 7 french students who are going to make a GStreamer-based 
non-linear video editor as the final year project."

Ok, where are they ! If there is a VFR editor it could be this one !

> Yes, Ronald and I have already talked about it a bit. This article is
> also linked to on /. with a couple of interesting comments (and a couple
> of trollish comments, but that's /.):
> http://developers.slashdot.org/article.pl?sid=04/01/13/2043223&mode=thread&tid=131&tid=188&tid=189

I'll have a look.



From chris at matroska.org  Fri Jan 16 04:11:45 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 16 Jan 2004 04:11:45 +0100
Subject: [Matroska-general] TCMP, MILK, matroska, mkvmerge,
 avi-mux  ..... what a mess !! Cant
 we come up with a common Corecodec strategy ?
Message-ID: <40075671.20409@matroska.org>


Hi folks,

when lying awake in my bed tonight, i was thinking again of the way we 
are working currently, and to be honest, i dont like it a lot. Lets see 
how many APIs and or platforms we have ( planned or used ) alone inside 
our small number of projects :

- CCAS for TCMP
- MILK
- UDub plugin API
- mkvmerge internal API ( sorry, dont know how to name it better )
- VfW ( VCM / ACM )
- DirectShow

My question : is there really no way to set all of this on a common 
platform ? I know this kind of work is unwanted, as it doesnt give you 
quick results. It maybe requires long term planning until you have the 
common platform and API working ( i guess BBB and the Gstreamer guys can 
sing a song here ), but dont you agree that, once this is done, we could 
progress much much faster ?


A big question in this respect, as raised by robux4 again lately, is how 
about porting Gstreamer to Windows ? We could call it   'WinStreamer'  
and make a project on cc.org from it, as Gstreamer itself has recently 
moved to freebsd.org AFAIK, i guess they wont object if the Windows port 
is hosted on another server. Just think of the huge number of 
possibilities :

- TCMP6 for Linux/Windows
- UDub, with the comfort to be able to use *ALL* existing format plugins 
and codecs for gstreamer
- the ability to use most of the apps designed for the official GNOME 
media interface on Windows
etc.

What you think ?

Christian




From moritz at bunkus.org  Fri Jan 16 09:33:09 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 16 Jan 2004 09:33:09 +0100
Subject: [Matroska-general] TCMP, MILK, matroska, mkvmerge,
	avi-mux ..... what a mess !! Cant we come up with a common Corecodec
	strategy ?
In-Reply-To: <40075671.20409@matroska.org>
References: <40075671.20409@matroska.org>
Message-ID: <20040116083309.GK30186@bunkus.org>

Heya,

> - mkvmerge internal API ( sorry, dont know how to name it better )

I strongly doubt my API would be 'convertable'. Basically I have three
componentes:
1) readers (demuxers) which handle different container formats, file type
recognition and stuff. This is more or less easy.
2) packetizers (framers) which handle different media types - one for
Vorbis, one for video etc.pp.
3) The muxer (called cluster_helper) which requests packets from the
packetizers which request packets from the readers and then stuffs those
into clusters which then are rendered to the output file.

Now what makes this complicated? One thing is that all the command line
parameters actually have to reach the packetizers (and yes, I do mean
all or nearly all), that the cluster_helper needs access to a lot of
internal stuff of the packetizers. I can't really describe it, but my
stuff is really involved. If you want a common API that API would have
to be as extensive as mine is, and I don't think anyone else wants
that. My idea has never been to have a modular system for which everyone
can write a plugin (be it a reader or packetizer, doesn't matter) but to
have a system that can control almost every aspect of Matroska file
creation. This does not fit well into a common API.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Fri Jan 16 09:52:14 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 16 Jan 2004 09:52:14 +0100
Subject: [Matroska-general] Re: TCMP, MILK, matroska, mkvmerge,
 avi-mux  ..... what a mess !!
 Cant we come up with a common Corecodec strategy ?
In-Reply-To: <40075671.20409@matroska.org>
References: <40075671.20409@matroska.org>
Message-ID: <4007A63E.5030809@free.fr>

Christian HJ Wiesner wrote:

> 
> Hi folks,
> 
> when lying awake in my bed tonight, i was thinking again of the way we 
> are working currently, and to be honest, i dont like it a lot. Lets see 
> how many APIs and or platforms we have ( planned or used ) alone inside 
> our small number of projects :
> 
> - CCAS for TCMP
> - MILK
> - UDub plugin API
> - mkvmerge internal API ( sorry, dont know how to name it better )
> - VfW ( VCM / ACM )
> - DirectShow
> 
> My question : is there really no way to set all of this on a common 
> platform ? I know this kind of work is unwanted, as it doesnt give you 
> quick results. It maybe requires long term planning until you have the 
> common platform and API working ( i guess BBB and the Gstreamer guys can 
> sing a song here ), but dont you agree that, once this is done, we could 
> progress much much faster ?

Yes, but you can't expect DirectShow or VfW working on other platforms 
that MS ones. And we want to be cross-platform. Now there could be 
GStreamer but it's not working on anything other than unices. And they 
have no intention on endorsing other platforms (if you want it, that's 
your problem). That's a pity but the situation seems to be locked right now.

> A big question in this respect, as raised by robux4 again lately, is how 
> about porting Gstreamer to Windows ? We could call it   'WinStreamer'  

That would mean that we become *the* maintainers of this port as they 
don't give a shit about Windows (unless it's close enough to a UNIX 
using cygwin). And therefore, as I said already, I can't endorse that 
responsability because I want to concentrate on Matroska and Ordinateur-DJ.

> and make a project on cc.org from it, as Gstreamer itself has recently 
> moved to freebsd.org AFAIK, i guess they wont object if the Windows port 
> is hosted on another server. Just think of the huge number of 
> possibilities :
> 
> - TCMP6 for Linux/Windows

And OSX :)

> - UDub, with the comfort to be able to use *ALL* existing format plugins 
> and codecs for gstreamer
> - the ability to use most of the apps designed for the official GNOME 
> media interface on Windows
> etc.
> 
> What you think ?

This is indeed needed ! It will take a lot of time.

Maybe today I'm going to try to make real Mingw makefiles for GStreamer 
and its dependencies. And hopefully if it works I'll make an HTML doc of 
how to be able to do it... It would be even better to have MSVC project 
files after that. But I don't have it here...



From steve.lhomme at free.fr  Fri Jan 16 09:56:06 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 16 Jan 2004 09:56:06 +0100
Subject: [Matroska-general] Re: TCMP, MILK, matroska, mkvmerge,
 avi-mux  .....	what a mess !!
 Cant we come up with a common Corecodec strategy ?
In-Reply-To: <40077257.8050602@hrz.tu-chemnitz.de>
References: <40075671.20409@matroska.org> <40077257.8050602@hrz.tu-chemnitz.de>
Message-ID: <4007A726.1080104@free.fr>

Alexander No? wrote:

> Christian HJ Wiesner wrote:
> 
>>
>> Hi folks,
>>
>> when lying awake in my bed tonight, i was thinking again of the way we 
>> are working currently, and to be honest, i dont like it a lot. Lets 
>> see how many APIs and or platforms we have ( planned or used ) alone 
>> inside our small number of projects :...
> 
> 
> You know that, if your idea came true, *all* matroska tools would 
> instantly break
> the next time Cyrius sends 'libmatroska b0rked' on the ML?

I understand your point. But that doesn't mean a unification, merging 
efforts is not needed. And BTW the GStreamer read/write is done in C and 
done by Ronald.
IMO that's another problem with GStreamer, they won't accept C++ code. 
But if we do WinStreamer we are free from them :D... As for VDM compared 
to VirtualDub when they release new code we'll have to merge it with ours.



From steve.lhomme at free.fr  Fri Jan 16 09:59:06 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 16 Jan 2004 09:59:06 +0100
Subject: [Matroska-devel] Re: [Matroska-general] TCMP, MILK, matroska,
	mkvmerge,
	avi-mux ..... what a mess !! Cant we come up with a common Corecodec
	strategy ?
In-Reply-To: <20040116083309.GK30186@bunkus.org>
References: <40075671.20409@matroska.org> <20040116083309.GK30186@bunkus.org>
Message-ID: <4007A7DA.908@free.fr>

Moritz Bunkus wrote:

> Now what makes this complicated? One thing is that all the command line
> parameters actually have to reach the packetizers (and yes, I do mean
> all or nearly all), that the cluster_helper needs access to a lot of
> internal stuff of the packetizers. I can't really describe it, but my
> stuff is really involved. If you want a common API that API would have
> to be as extensive as mine is, and I don't think anyone else wants
> that. My idea has never been to have a modular system for which everyone
> can write a plugin (be it a reader or packetizer, doesn't matter) but to
> have a system that can control almost every aspect of Matroska file
> creation. This does not fit well into a common API.

That's what makes your tools so special. They are the only ones that can 
make real use of Matroska because they don't have the limitations of 
legacy systems. Now maybe GStreamer doesn't have this limitation (as 
they claim it's almost perfect ;). Maybe Ronald could tell us about it, 
like what features are and aren't possible, and if it's possible to 
(re)write something like mkvmerge entirely with GStreamer.



From christian at matroska.org  Fri Jan 16 23:57:09 2004
From: christian at matroska.org (ChristianHJW)
Date: Fri, 16 Jan 2004 23:57:09 +0100
Subject: [Matroska-general] Re: Looking for a file format
In-Reply-To: <20040115170455.GD257@brightrain.aerifal.cx>
References: <Pine.LNX.4.44.0401142115180.1593-100000@x-wing.tmmm.home>
	<yw1xbrp5vaow.fsf@kth.se> <40069E59.5020305@web.de>
	<yw1xu12xthtv.fsf@kth.se>
	<20040115170455.GD257@brightrain.aerifal.cx>
Message-ID: <40086C45.80402@matroska.org>

D Richard Felker III wrote:

> On Thu, Jan 15, 2004 at 03:19:40PM +0100, M?ns Rullg?rd wrote:
>>OK, but it's still way too complex.  I was hoping there would be
>>something simple.  I need only a single audio stream, but the
>>timestamping is important.
> 
> The solution is the nut format, created by Michael and Alex. But there
> isn't any complete working code for it. Alex was working on nut muxer
> & demuxer for libavformat, but he says libavformat makes it difficult
> to handle pts and subpackets correctly. You can read the (slightly
> outdated) spec in DOCS/tech/mpcf.txt from MPlayer CVS. The first fully
> functional nut muxer will probably be in MPlayer G2.
> Rich


See Richard, thats the difference. We dont accuse you of 'pimping' a 
'vapourware' container, like many of you did with us at the time we were 
telling people we're working on new container specs.

BTW, matroska audio ( .mka ) supports all kinds of different PCM 
formats, different sampling rates, bitdepths and endianess, its 
timestamp based, can be muxed into a matroska video file ( .mkv ) with
- MPEG1
- MPEG2 ( yes, we have it working :-) )
- MPEG4
- RealVideo9
- any VCM/VfW video codec
- raw video
and its streamable via Http ( no UDP payload yet )

... ah yes, and we have working code for Linux, Windows, MacOSX and 
BeOS, a fully supported and powerful tagging system, a nice descriptive 
homepage, etc. pp .... :P ....

Regards

Christian
matroska project admin
http://www.matroska.org



From chris at matroska.org  Sat Jan 17 00:13:07 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 17 Jan 2004 00:13:07 +0100
Subject: [Matroska-general] C demuxer for matroska files patch for mplayer 
Message-ID: <40087003.5070106@matroska.org>

http://article.gmane.org/gmane.comp.video.mplayer.devel/14806

I like that :) ... thanks Aurelien !! If you need some tips, you are 
always welcome on irc.corecodec.com #matroska ....

Christian



From christian at matroska.org  Sat Jan 17 09:32:42 2004
From: christian at matroska.org (ChristianHJW)
Date: Sat, 17 Jan 2004 09:32:42 +0100
Subject: [Matroska-general] Re: help on libmpdemux usage
 =?iso-8859-1?q?=28Modifi=E9_par_J=E9?=
 =?iso-8859-1?q?r=F4me_Cornet=29?=
In-Reply-To: <20040113191843.GC257@brightrain.aerifal.cx>
References: <31BE606C-459B-11D8-BB3C-003065EC20CA@club-internet.fr>	<20040113095754.587f0a18.albeu@free.fr>	<90DC9038-45AC-11D8-BB3C-003065EC20CA@aldorande.net>	<20040113145301.GX257@brightrain.aerifal.cx>	<40042167.3010103@ntlworld.com>
	<20040113191843.GC257@brightrain.aerifal.cx>
Message-ID: <4008F32A.2090800@matroska.org>

D Richard Felker III wrote:
> On Tue, Jan 13, 2004 at 04:48:39PM +0000, Adam Rice wrote: 
>>D Richard Felker III wrote:
>>>QuickTime itself is non-free. Making a derivative work of MPlayer
>>>which is linked in as a component of non-free code (QuickTime) is not
>>>permitted by the GPL, as far as I can tell. LGPL would be required for
>>>something like this, and MPlayer is intentionally GPL rather than
>>>LGPL. Whether you release source is irrelevant.
>>As far as I know, QuickTime loads codecs at runtime. Thus the codec is 
>>not linked into QuickTime. So the only two relevant questions are:
>>a) Does Apple place restrictions on the licenses under which third-party 
>>QuickTime codecs may be distributed?
>>b) Is binary code under a GPL-incompatible license linked into the codec?
>>I would expect the answer to both of these questions to be "no". In some 
>>circumstances it could be legal even if the answer to the second 
>>question was "yes", as QuickTime is an OS component under MacOS, and the 
>>GPL has a specific exception for that.
>>As an aside, the GPL places no restrictions on "Making" anything. It 
>>only places restrictions on distribution, and only on binaries at that.
>>I should point out that these comments apply to GPL v2. Some people 
>>consider the ability to make GPL'd plugins for proprietary software to 
>>be a loophole that needs to be fixed in a future version. It seems to me 
>>this can't be done without placing restrictions on use, which would make 
>>the GPL no better than the proprietary software licenses it seeks to 
>>replace.
> Not at all. Someone is perfectly free to make a plugin for a
> proprietary system out of GPL code for their own private use, but the
> GPL does not give them permission to distribute this derived work
> since it is linked (even dynamically) to proprietary code.
> Rich


Hmmm, interesting discussion. I have to think through this a second 
time, but it seems Richard has just been proving to me that a GPL 
license is basically incompatible with *M$ DirectShow* also, and thus we 
presently dont allow anybody else to make and release a DirectShow 
parser filter for our stuff, as long as we have this license type for 
our main lib. Have to check if QPL would maybe allow, but i dont think 
it will be less restrictive in this respect.

Of course, this is currently no issue as we, the license holders, are 
distributing our own DShow parser/muxer filters, but to stress the same 
example as discussed here, if anybody wanted to make a Quicktime plugin 
using libmatroska/libebml, he'd violate the GPL doing so :O !! And 
jcsston is just working on a Helix/RealNetworks muxer for matroska, and 
using libmatroska for that ! As Helix itself is not GPL, but using a 
different license style to the best of my knowledge, you basically cant 
use any GPL plugins with it without violating GPL itself ?

I was actually never aware of that, and at first i was scared to death 
when thinking about FFdshow, Milan Cutka's great DirectShow decoder 
filter based on FFMPEG, but then of course the latter is using L-GPL, so 
Milan is fine and not violating anything. But, i will really start 
watching now how many DShow filters out there are using GPL'ed stuff, 
there may be a few and authors think they are fine by releasing their 
work under GPL also, but in fact they are not. After all, i was 
promoting since a long time now to change our license to L-GPL, as BBB's 
C lib is available under this license and there are allogether 6! 
different matroska implementations existing ( but most under GPL ), 
usage of the main lib should not be restricted to GPL apps any longer IMO.

Richard, thanks for pointing this out in detail, i honestly was not aware !

Christian
matroska project admin
http://www.matroska.org



From steve.lhomme at free.fr  Sat Jan 17 11:24:26 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 17 Jan 2004 11:24:26 +0100
Subject: =?ISO-8859-1?Q?Re=3A_=5BMatroska-general=5D_Re=3A_help_o?=
	=?ISO-8859-1?Q?n_libmpdemux_usage_=28Modifi=E9_par_J=E9r=F4me_?=
	=?ISO-8859-1?Q?Cornet=29?=
In-Reply-To: <4008F32A.2090800@matroska.org>
References: <31BE606C-459B-11D8-BB3C-003065EC20CA@club-internet.fr>	<20040113095754.587f0a18.albeu@free.fr>	<90DC9038-45AC-11D8-BB3C-003065EC20CA@aldorande.net>	<20040113145301.GX257@brightrain.aerifal.cx>	<40042167.3010103@ntlworld.com>	<20040113191843.GC257@brightrain.aerifal.cx>
	<4008F32A.2090800@matroska.org>
Message-ID: <40090D5A.1000909@free.fr>

ChristianHJW wrote:

> D Richard Felker III wrote:
>> Not at all. Someone is perfectly free to make a plugin for a
>> proprietary system out of GPL code for their own private use, but the
>> GPL does not give them permission to distribute this derived work
>> since it is linked (even dynamically) to proprietary code.
>> Rich
> 
> 
> 
> Hmmm, interesting discussion. I have to think through this a second 
> time, but it seems Richard has just been proving to me that a GPL 
> license is basically incompatible with *M$ DirectShow* also, and thus we 
> presently dont allow anybody else to make and release a DirectShow 
> parser filter for our stuff, as long as we have this license type for 
> our main lib. Have to check if QPL would maybe allow, but i dont think 
> it will be less restrictive in this respect.

Don't worry, you're not the first person to ask about this. And if there 
was a definitive answer noone would need to question it again. But 
actually there is *no* answer to this... My opinion is that a DSF is 
just a standalone piece of code, that could be used by a DirectShow 
clone that could be GPLed. So it's not hard linked in any kind to 
anything proprietary. Sowe don't mind about it.

> Of course, this is currently no issue as we, the license holders, are 
> distributing our own DShow parser/muxer filters, but to stress the same 
> example as discussed here, if anybody wanted to make a Quicktime plugin 
> using libmatroska/libebml, he'd violate the GPL doing so :O !! And 
> jcsston is just working on a Helix/RealNetworks muxer for matroska, and 
> using libmatroska for that ! As Helix itself is not GPL, but using a 
> different license style to the best of my knowledge, you basically cant 
> use any GPL plugins with it without violating GPL itself ?

The license for Helix is compatible with the GPL. It's stated on Real's 
site. Of course Quicktime may be another problem...






From chris at matroska.org  Sun Jan 18 15:08:06 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 18 Jan 2004 15:08:06 +0100
Subject: =?ISO-8859-1?Q?Re=3A_=5BMatroska-general=5D_Re=3A_help_o?=
	=?ISO-8859-1?Q?n_libmpdemux_usage_=28Modifi=E9_par_J=E9r=F4me_?=
	=?ISO-8859-1?Q?Cornet=29?=
In-Reply-To: <40090D5A.1000909@free.fr>
References: <31BE606C-459B-11D8-BB3C-003065EC20CA@club-internet.fr>	<20040113095754.587f0a18.albeu@free.fr>	<90DC9038-45AC-11D8-BB3C-003065EC20CA@aldorande.net>	<20040113145301.GX257@brightrain.aerifal.cx>	<40042167.3010103@ntlworld.com>	<20040113191843
	<40090D5A.1000909@free.fr>
Message-ID: <400A9346.3000309@matroska.org>

Steve Lhomme wrote:

> ChristianHJW wrote:
>
>> D Richard Felker III wrote:
>>
>>> Not at all. Someone is perfectly free to make a plugin for a
>>> proprietary system out of GPL code for their own private use, but the
>>> GPL does not give them permission to distribute this derived work
>>> since it is linked (even dynamically) to proprietary code.
>>> Rich
>>
>> Hmmm, interesting discussion. I have to think through this a second 
>> time, but it seems Richard has just been proving to me that a GPL 
>> license is basically incompatible with *M$ DirectShow* also, and thus 
>> we presently dont allow anybody else to make and release a DirectShow 
>> parser filter for our stuff, as long as we have this license type for 
>> our main lib. Have to check if QPL would maybe allow, but i dont 
>> think it will be less restrictive in this respect.
>
>
> Don't worry, you're not the first person to ask about this. And if 
> there was a definitive answer noone would need to question it again. 
> But actually there is *no* answer to this... My opinion is that a DSF 
> is just a standalone piece of code, that could be used by a DirectShow 
> clone that could be GPLed. So it's not hard linked in any kind to 
> anything proprietary. Sowe don't mind about it. 

Even this question seemed to be discussed within the FSF in great 
detail, and they finally seemd to have agreed that DirectShow is  part 
of the OS, and as such falls under the exception the FSF has made for 
the usage of OS related libraries etc.

>> Of course, this is currently no issue as we, the license holders, are 
>> distributing our own DShow parser/muxer filters, but to stress the 
>> same example as discussed here, if anybody wanted to make a Quicktime 
>> plugin using libmatroska/libebml, he'd violate the GPL doing so :O !! 
>> And jcsston is just working on a Helix/RealNetworks muxer for 
>> matroska, and using libmatroska for that ! As Helix itself is not 
>> GPL, but using a different license style to the best of my knowledge, 
>> you basically cant use any GPL plugins with it without violating GPL 
>> itself ?
>
> The license for Helix is compatible with the GPL. It's stated on 
> Real's site. Of course Quicktime may be another problem...

Steve, the reason i was copying the helix-general list on this email was 
obvious :

I wanted to see if anybody from them has the balls to comment. I know 
they made Helix GPL, but dont you see that they are violating the GPL 
with this ? Helix is linking to proprietary code, i.e. the codecs, and 
this is strictly forbidden by the GPL license. The argument that there 
'.... may be a similar plugin/framework which happens to have the same 
interface, and is GPL ...'  is void. If its released under the GPL, it 
must be released. If you have the sources on your HDD, and dont release 
them, you cant apply the GPL to them, as GPL strictly regulates the 
*DISTRIBUTION* of code, so a code that is not released can not comply 
with the GPL.

In short, as long as there is no GPL or L-GPL RealVideo/Audio 
de/encoder, the complete Helix framework can not be released under GPL, 
and is a contradiction in itself. In return, we have to make 
libmatroska/libebml L-GPL, or we violate the GPL ourselves, now that we 
know this.

Christian



From steve.lhomme at free.fr  Sun Jan 18 15:36:01 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 18 Jan 2004 15:36:01 +0100
Subject: =?ISO-8859-1?Q?Re=3A_=5BMatroska-general=5D_Re=3A_help_o?=
	=?ISO-8859-1?Q?n_libmpdemux_usage_=28Modifi=E9_par_J=E9r=F4me_?=
	=?ISO-8859-1?Q?Cornet=29?=
In-Reply-To: <400A9346.3000309@matroska.org>
References: <31BE606C-459B-11D8-BB3C-003065EC20CA@club-internet.fr>	<20040113095754.587f0a18.albeu@free.fr>	<90DC9038-45AC-11D8-BB3C-003065EC20CA@aldorande.net>	<20040113145301.GX257@brightrain.aerifal.cx>	<40042167.3010103@ntlworld.com>	<20040113191843	<40090D5A.1000909@free.fr>
	<400A9346.3000309@matroska.org>
Message-ID: <400A99D1.4050303@free.fr>

Christian HJ Wiesner wrote:

> I wanted to see if anybody from them has the balls to comment. I know 
> they made Helix GPL, but dont you see that they are violating the GPL 
> with this ? Helix is linking to proprietary code, i.e. the codecs, and 
> this is strictly forbidden by the GPL license. The argument that there 
> '.... may be a similar plugin/framework which happens to have the same 
> interface, and is GPL ...'  is void. If its released under the GPL, it 
> must be released. If you have the sources on your HDD, and dont release 
> them, you cant apply the GPL to them, as GPL strictly regulates the 
> *DISTRIBUTION* of code, so a code that is not released can not comply 
> with the GPL.
> 
> In short, as long as there is no GPL or L-GPL RealVideo/Audio 
> de/encoder, the complete Helix framework can not be released under GPL, 
> and is a contradiction in itself. In return, we have to make 
> libmatroska/libebml L-GPL, or we violate the GPL ourselves, now that we 
> know this.

Real has used lawyers to work on them. So I trust them more than you or 
any other coder on that matter. This problem is really not my priority :)



From moritz at bunkus.org  Mon Jan 19 23:31:59 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 19 Jan 2004 23:31:59 +0100
Subject: [Matroska-general] mplayer with new, C based Matroska demuxer
Message-ID: <20040119223159.GK26064@bunkus.org>

Heya,

for those who didn't know: Someone wrote a new C based Matroska demuxer
for mplayer which I've committed today. The threads in question:

http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-January/023405.html
http://mplayerhq.hu/pipermail/mplayer-users/2004-January/042061.html

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Tue Jan 20 13:34:41 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 20 Jan 2004 13:34:41 +0100
Subject: [Matroska-general] Open Source politics
Message-ID: <400D2061.7050704@free.fr>

http://www.linuxworld.com/story/39211.htm?DE=1

Interresting article to read.



From moritz at bunkus.org  Tue Jan 20 22:40:14 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 20 Jan 2004 22:40:14 +0100
Subject: [Matroska-general] mkvtoolnix 0.8.2 released
Message-ID: <20040120214014.GT26064@bunkus.org>

Heya mailing lists and package maintainers,

here's another release of mkvtoolnix, 0.8.2. A few usability
enhancements together with a couple of minor bug fixes make up this
release. Please note that Windows users need to re-download the runtime
package also available on my home page because I've switched to more
DLLs.

The mkvtoolnix homepage:
http://www.bunkus.org/videotools/mkvtoolnix/
The sources:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-0.8.2.tar.bz2
The Windows binaries and the Windows runtime package:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.8.2.rar
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-runtime.rar

And finally the ChangeLog since 0.8.1:
----------------------------
2004-01-21  Moritz Bunkus  <moritz at bunkus.org>

	* Released v0.8.2.

2004-01-19  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: The PCM handling was broken resulting in
	packets that did not end on sample boundaries.

2004-01-17  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: AVIs with uncompressed sound were leading to
	buffer overflows.

	* mkvmerge/mmg: allow the track names to be empty so that you can
	remove them when muxing Matroska files. Same for the file title.

	* mkvmerge: new feature: The track headers will be rendered
	completely including the elements that are set to their default
	values. Causes less confusion and allows the setting of e.g. the
	track language without having to remux the file completely.

	* mkvmerge: bug fix: If remuxing a file that contains frames with
	a reference to the same timecode those references were lost
	turning such P frames into I frames. This was the case for some
	RealAudio stuff.

2004-01-15  Moritz Bunkus  <moritz at bunkus.org>

	* mmg: new feature: Automatically pre-set the attachment's MIME
	type if the file has a known extension (e.g. 'text/plain' for
	'.txt').

	* mkvmerge: new feature: Unknown/unsupported track types can be
	copied 1:1 from Matroska input files.

	* mkvmerge: new feature: Added proper support for
	AAC-inside-RealMedia files.

2004-01-14  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: new feature: Write cues for audio-only files as well
	(not more than one cue entry during a two seconds period).

2004-01-12  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: The default track flags could not be
	overriden on the command line when reading Matroska files.

	* Windows binaries after v0.8.1 require a new runtime DLL
	archive. Please download it from
	http://www.bunkus.org/videotools/mkvtoolnix/ Thanks.

2004-01-11  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: new feature: Added the two new chapter flags 'hidden'
	and 'enabled'.

	* mkvmerge: new feature: Added a new format for the external
	timecode files.

2004-01-09  Moritz Bunkus  <moritz at bunkus.org>

	* mkvmerge: bug fix: The VobSub handling was on occasion putting
	SPU packets for the wrong MPEG stream into the current stream
	resulting in that particular entity not being displayed.
-----------------

Have fun :)

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From kintarojiro at hotmail.com  Wed Jan 21 18:24:09 2004
From: kintarojiro at hotmail.com (=?iso-8859-1?B?S2ludGFybyBIb+k=?=)
Date: Wed, 21 Jan 2004 17:24:09 +0000
Subject: [Matroska-general] question
Message-ID: <Law10-F93I5RTHrS0WE00008c4d@hotmail.com>

hello,

there is a divx living room player the kiss (http://www.kiss-technology.com) 
it support the ogg vorbis (sound only)
but no the ogm and the matroska is the best codec for all my videos but it 
doesn't work with it can u try something for us and you can take the source 
code of the lastest update
im sorry if i disturb you but i know nothing about programming at the moment 
(im working on it)
^^;

cheers :D

_________________________________________________________________
En avant-premi?re sur MSN Auto, le Calendrier Pirelli 2004 ! 
http://automobile.fr.msn.be/pirelli2004/



From chris at matroska.org  Wed Jan 21 19:44:00 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 21 Jan 2004 19:44:00 +0100
Subject: [Matroska-general] question
In-Reply-To: <Law10-F93I5RTHrS0WE00008c4d@hotmail.com>
References: <Law10-F93I5RTHrS0WE00008c4d@hotmail.com>
Message-ID: <400EC870.9030200@matroska.org>

Kintaro Ho? wrote:

> hello,
> there is a divx living room player the kiss 
> (http://www.kiss-technology.com) it support the ogg vorbis (sound only)
> but no the ogm and the matroska is the best codec for all my videos 
> but it doesn't work with it can u try something for us and you can 
> take the source code of the lastest update
> im sorry if i disturb you but i know nothing about programming at the 
> moment (im working on it)
> ^^;
> cheers :D 

Kintaro,

we are in contact with KiSS since several months now. However, adding 
MKV support to current KiSS devices, which are based on the SIGMA EM 
85xx programmable decoder chips, seems to be more or less impossible. 
These decoders simply dont offer enough processing power to decode the 6 
most used encoding profiles for MKV files ( read more about that here : 
http://forum.doom9.org/showthread.php?s=&threadid=68623 ) :

DivX/XviD video ( max. 720 * 576 ) + MP3 Stereo audio
DivX/XviD video ( max. 720 * 576 ) + AC3 2.0 oder 5.1 audio
DivX/XviD video ( max. 720 * 576 ) + DTS audio
DivX/XviD video ( max. 720 * 576 ) + Vorbis Stereo audio
DivX/XviD video ( max. 720 * 576 ) + AAC LC Stereo
DivX/XviD video ( max. 720 * 432 ) + AAC SBR ( Nero6 HE-AAC ) 5.1 Dolby 
Digital

Only the first 3 could be supported by current SIGMA chips, and they 
likely represent less than 20% of all MKV files out there, as these 
audio formats are possible in AVI also.

Another very big issue for matroska support in hardware devices was the 
missing RealVideo9 support, a very good video codec especially for anime 
and 1 CD rips. It takes a good bit more of decoding power than MPEG4 
ISO, again very hard to do for a hardware standalone unit, but enjoys a 
growing number of fans, and it seems like matroska is one of the major 
reasons behind this boom.

And no, there is no way to update the firmware of the KiSS player, as 
despite other messages, its *NOT* opensource ( KiSS only released the ?C 
Linux kernel, as requested by GPL for Linux, and not the complete 
firmware ).

Sorry if i dont have any better news yet, but rest assured we are 
working hard to make this happening.

ChristianHJW
matroska project admin
http://www.matroska.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-general/attachments/20040121/7e579d6f/attachment.html>

From hubereevez at yahoo.fr  Sun Jan 25 23:17:06 2004
From: hubereevez at yahoo.fr (Hubereevez)
Date: Sun, 25 Jan 2004 23:17:06 +0100
Subject: [Matroska-general] better hide your mailing list
Message-ID: <20040125221702.D4183440026@p15097576.pureserver.info>

free for spammers
	erf
	google search :
	http://lists.matroska.org/pipermail/matroska-users.mbox/matroska-users.mbox



From steve.lhomme at free.fr  Mon Jan 26 10:14:32 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 26 Jan 2004 10:14:32 +0100
Subject: [Matroska-general] Microsoft patent on XML
Message-ID: <4014DA78.70805@free.fr>

The way Office XML files are read.

http://news.com.com/2100-1013_3-5146581.html?tag=nefd_top

Apparently either they have a new technique to parse XML files and they 
can have this patent (and nobody will care) or they use an old technique 
and there will be lots of prior art anyway...



From chris at matroska.org  Mon Jan 26 16:57:07 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 26 Jan 2004 16:57:07 +0100
Subject: [Matroska-general] Variable Framerate,
	plugin based video editing tool
Message-ID: <401538D3.1020609@matroska.org>


Hi,

i have the pleasure to tell you that there is a good chance that Mosu 
and Cyrius will work together on a new video editing tool. The new tool 
should not be based on any existing programs, but be more or less 
started from scratch. Mosu and Cyrius are currently in the process to 
agree on basic structure, and the matroska-devel ML will be used for 
these initial steps.

A first draft of the scope of the program could look like that :

- Variable Framerate ( VFR ) capable
- Extendable via plugins, for both input/output containers
- Standard editing Format is MKV ( matroska )
- Can handle at least one video stream, plus several audio and subtitles 
streams
- X-platform, GUI made with wxwindows for improved portability
- Possibility to extend to handling of multiple video streams for NLE ( 
Non-Linear Editing )

A possible road map could look like

1. Define basic structure, including the internal 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 you all might be aware, this is a huge task and can not be completed 
by the two alone. It must be the goal of the complete matroska team to 
contribute to this project, mainly by adding usable input modules, so 
that step 4. could be achieved in reasonable time, so that the full 
scope of mkvmerge is matched by the new editor. After that, the 
definition of a codec plugin API and the creation of codecs based on 
this should be the mian goal, so we could finally lift matroska to a 
level where it can truely overcome AVI and VfW, and will get a general 
standard status for the future of video and audio encoding.

I expect Mosu will have something to say here now, and i suppose he will 
get a lot more technical than i did, and also will answer with a lot of  
'BUT's :-) . So please, before you reply to this email to tell us your 
opinion about it, wait for his email first. After all, i might have seen 
things too optimistic, as always ;-) ....

Christian




From steve.lhomme at free.fr  Mon Jan 26 17:08:24 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 26 Jan 2004 17:08:24 +0100
Subject: [Matroska-general] Re: [Matroska-devel] 	Variable Framerate,
 plugin based video editing tool
In-Reply-To: <401538D3.1020609@matroska.org>
References: <401538D3.1020609@matroska.org>
Message-ID: <40153B78.5010605@free.fr>

I think it would be good if you have a capture system directly to 
Matroska (no problems with dropped frames as in AVI) from either 
video-in, tuner or DV. Similar to what you can do with VDub but a bit 
better.

Another idea would be to post a thread in a few forums (Doom9, VD) to 
ask all the features people can think of for a good editor. Then we'll 
pick the most important ones we want.



From ploum at mitose.net  Mon Jan 26 19:05:59 2004
From: ploum at mitose.net (Ploum)
Date: Mon, 26 Jan 2004 19:05:59 +0100
Subject: [Matroska-general] Variable Framerate, plugin based video editing
	tool
In-Reply-To: <401538D3.1020609@matroska.org>
References: <401538D3.1020609@matroska.org>
Message-ID: <40155707.1030001@mitose.net>

Christian HJ Wiesner wrote:
> 
> Hi,
> 
> i have the pleasure to tell you that there is a good chance that Mosu 
> and Cyrius will work together on a new video editing tool.

This is really a great news !  :)

Good work to Mosu and Cyrius..

Do you need some suggestions ?  Or have you already a todo list until 
2017 ? ;)

We really need this kind of tool. wxWindow is a really good widget. I 
only hope that it will soon use Gtk2 under Linux.

I suppose that the language is C. Am I wrong ?

And do you use a backend like xine or *gstreamer* ?  Or do you write all 
from scratch ?


I will try to follow this project as much as possible. Please post your 
CVS adress or anything else as soon as possible so we can read, compile 
  and test your code.

Really good idea..  I dream of a good DV editor using Matroska by default.

Ploum


From suiryc at yahoo.com  Mon Jan 26 21:18:38 2004
From: suiryc at yahoo.com (Cyrius)
Date: Mon, 26 Jan 2004 12:18:38 -0800 (PST)
Subject: [Matroska-general] Re: Variable Framerate,
	plugin based video editing tool
In-Reply-To: <401538D3.1020609@matroska.org>
Message-ID: <20040126201838.16629.qmail@web12902.mail.yahoo.com>

Hi

--- Christian HJ Wiesner <chris at matroska.org> wrote:
> 
> Hi,
> 
> i have the pleasure to tell you that there is a good chance that Mosu
> and Cyrius will work together on a new video editing tool. The new
> tool 
> should not be based on any existing programs, but be more or less 
> started from scratch. Mosu and Cyrius are currently in the process to
> agree on basic structure, and the matroska-devel ML will be used for 
> these initial steps.
> 
> A first draft of the scope of the program could look like that :
> 
> - Variable Framerate ( VFR ) capable
> - Extendable via plugins, for both input/output containers
> - Standard editing Format is MKV ( matroska )
> - Can handle at least one video stream, plus several audio and
> subtitles 
> streams
> - X-platform, GUI made with wxwindows for improved portability
> - Possibility to extend to handling of multiple video streams for NLE
> ( 
> Non-Linear Editing )
> 
> A possible road map could look like
> 
> 1. Define basic structure, including the internal scripting
> 2. Define API for input/output modules
> 3. Allow muxing of MKV files, using different source formats

I agree that Matroska may be one of the first output formats supported.
But I think we should try to also support an 'easy' format from the
beginning too (thinking of AVI or OGM).
>From my point of view when you design the code you need to try and
prepare it for its future purpose (i.e. generally more advanced
features). When testing the code it may be better to have both
'basic'/'limited', and 'advanced' cases to test.
In other words it's good to test it to produce Matroska files which
support various things such as Variable FrameRate and exotic codec
combinations. But it may also be good to test it on more limited
formats such as AVI (I mean Constant FrameRate video, preferably CBR
audio, or VBR with a few workarounds in the specs ;); but e.g. no
Vorbis allowed :p).
Since I may be wrong, I invite people to tell here what they think
about it :)

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

That would indeed be a good roadmap to replace mkvmerge and
virtualdubmod step by step ...
However I'm not sure you can separate that easily steps 4 and 6.
Maybe it's only me, but I think that if you start only doing too simple
editing features then it might be quite hard to then implement more
advanced ones.
For other parts of the program (such as handling codec plugins, etc)
you can somewhat add them later (by taking into account what it will
need in the code), but upgrading a framework from too basic editing
capabilities to complex editing features may need to rewrite the code.

> As you all might be aware, this is a huge task and can not be
> completed 
> by the two alone. It must be the goal of the complete matroska team
> to 
> contribute to this project, mainly by adding usable input modules, so
> that step 4. could be achieved in reasonable time, so that the full 
> scope of mkvmerge is matched by the new editor. After that, the 
> definition of a codec plugin API and the creation of codecs based on 
> this should be the mian goal, so we could finally lift matroska to a 
> level where it can truely overcome AVI and VfW, and will get a
> general 
> standard status for the future of video and audio encoding.
>
> I expect Mosu will have something to say here now, and i suppose he
> will 
> get a lot more technical than i did, and also will answer with a lot
> of  
> 'BUT's :-) . So please, before you reply to this email to tell us
> your 
> opinion about it, wait for his email first. After all, i might have
> seen 
> things too optimistic, as always ;-) ....

Sorry for not waiting for his mail ;)
And yes you are always too optimistic (I'm still waiting a good
x-platform media api ;)) :p


Best regards
Cyrius

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/


From fortune_magazine at customersvc.com  Mon Jan 26 21:17:23 2004
From: fortune_magazine at customersvc.com (fortune_magazine at customersvc.com)
Date: Mon, 26 Jan 2004 12:17:23 -0800
Subject: [Matroska-general] hi
Message-ID: <20040126201910.C6401440021@p15097576.pureserver.info>

test

-------------- next part --------------
A non-text attachment was scrubbed...
Name: document.zip
Type: application/octet-stream
Size: 22798 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-general/attachments/20040126/98db86cf/attachment.obj>

From steve.lhomme at free.fr  Mon Jan 26 21:28:57 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 26 Jan 2004 21:28:57 +0100
Subject: [Matroska-general] Re: Variable Framerate,
	plugin based video editing tool
In-Reply-To: <20040126201838.16629.qmail@web12902.mail.yahoo.com>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>
Message-ID: <40157889.3060408@free.fr>

Cyrius wrote:

> And yes you are always too optimistic (I'm still waiting a good
> x-platform media api ;)) :p

Actually, I think you don't necessarily need a media-api that already 
exists for it. This API is just a building block. But making an editor 
require much more than that. IMO it's the most simple part of the job. 
And you can always design your own plugin API if none suits your needs. 
As long as it's clean and the project is doing well, you won't have 
problems getting help from a few hackers.

Audacity is meant to be the Gimp for audio but it sucks.
I hope this TCVE will be a better the Gimp for video :)



From spyder at matroska.org  Tue Jan 27 01:41:38 2004
From: spyder at matroska.org (John Cannon)
Date: Mon, 26 Jan 2004 18:41:38 -0600
Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate,
 plugin based video editing tool
In-Reply-To: <40157889.3060408@free.fr>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>
	<40157889.3060408@free.fr>
Message-ID: <4015B3C2.4040604@matroska.org>

Steve Lhomme wrote:

> Cyrius wrote:
>
>> And yes you are always too optimistic (I'm still waiting a good
>> x-platform media api ;)) :p
>
>
> Actually, I think you don't necessarily need a media-api that already 
> exists for it. This API is just a building block. But making an editor 
> require much more than that. IMO it's the most simple part of the job. 
> And you can always design your own plugin API if none suits your 
> needs. As long as it's clean and the project is doing well, you won't 
> have problems getting help from a few hackers.
>
> Audacity is meant to be the Gimp for audio but it sucks.
> I hope this TCVE will be a better the Gimp for video :)
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>
Hmmm, why do we always send messages to BOTH devel and users?  I get 
double mail :)

Spyder


From spyder at matroska.org  Tue Jan 27 05:51:13 2004
From: spyder at matroska.org (John Cannon)
Date: Mon, 26 Jan 2004 22:51:13 -0600
Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate,
 plugin based video editing tool
In-Reply-To: <4015B3C2.4040604@matroska.org>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>	<40157889.3060408@free.fr>
	<4015B3C2.4040604@matroska.org>
Message-ID: <4015EE41.10309@matroska.org>

John Cannon wrote:

> Steve Lhomme wrote:
>
>> Cyrius wrote:
>>
>>> And yes you are always too optimistic (I'm still waiting a good
>>> x-platform media api ;)) :p
>>
>>
>>
>> Actually, I think you don't necessarily need a media-api that already 
>> exists for it. This API is just a building block. But making an 
>> editor require much more than that. IMO it's the most simple part of 
>> the job. And you can always design your own plugin API if none suits 
>> your needs. As long as it's clean and the project is doing well, you 
>> won't have problems getting help from a few hackers.
>>
>> Audacity is meant to be the Gimp for audio but it sucks.
>> I hope this TCVE will be a better the Gimp for video :)
>>
>> _______________________________________________
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>>
> Hmmm, why do we always send messages to BOTH devel and users?  I get 
> double mail :)
>
> Spyder
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>
Back to what I originally intended to say...

I love this idea!  In fact I would work on it too if you would let me 
;)  Of course, I probably wouldn't let myself if I were you :P  I 
promise I won't b0rk anything too badly.  I need the coding experience 
so maybe I will just watch and experiment until you think I am ready :)  
I am good at finding bugs in code :)

John


From steve.lhomme at free.fr  Tue Jan 27 09:57:26 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 27 Jan 2004 09:57:26 +0100
Subject: [Matroska-general] On Intellectual Property
Message-ID: <401627F6.7030509@free.fr>

http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=789

"Since intellectual property doesn't exist in the physical world, my 
ownership is based on convincing others that I can own something that is 
completely immaterial."



From steve.lhomme at free.fr  Tue Jan 27 10:23:50 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 27 Jan 2004 10:23:50 +0100
Subject: [Matroska-general] Re: Variable Framerate,
	plugin based video editing tool
In-Reply-To: <4015EE41.10309@matroska.org>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>	<40157889.3060408@free.fr>	<4015B3C2.4040604@matroska.org>
	<4015EE41.10309@matroska.org>
Message-ID: <40162E26.4040200@free.fr>

Some thoughts about the editor...

I was just reading the interresting IP article, and read about editing 
and how studios can have 2 or 3 different edits of the same movie. That 
made me think of how you could compare them easily. And as we do with 
software sources, we just make a diff. But it is impossible with binary 
data. So I suggests that TCVE could store an edit as an XML file. This 
way you can compare and create new edits easily from the same "raw" source.



From steve.lhomme at free.fr  Tue Jan 27 10:27:30 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 27 Jan 2004 10:27:30 +0100
Subject: [Matroska-general] Re: Variable Framerate,
	plugin based video editing tool
In-Reply-To: <40162E26.4040200@free.fr>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>	<40157889.3060408@free.fr>	<4015B3C2.4040604@matroska.org>	<4015EE41.10309@matroska.org>
	<40162E26.4040200@free.fr>
Message-ID: <40162F02.30809@free.fr>

Steve Lhomme wrote:

> Some thoughts about the editor...
> 
> I was just reading the interresting IP article, and read about editing 
> and how studios can have 2 or 3 different edits of the same movie. That 
> made me think of how you could compare them easily. And as we do with 
> software sources, we just make a diff. But it is impossible with binary 
> data. So I suggests that TCVE could store an edit as an XML file. This 
> way you can compare and create new edits easily from the same "raw" source.

And now pushing the idea further, we should be able to play a movie from 
that XML source file. Just like an AVIsynth script but with more 
features : at least VFR, but probably multi-tracks, chapters, control 
tracks, menus, etc.



From steve.lhomme at free.fr  Tue Jan 27 10:37:22 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 27 Jan 2004 10:37:22 +0100
Subject: [Matroska-general] Re: Variable Framerate,
	plugin based video editing tool
In-Reply-To: <40162F02.30809@free.fr>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>	<40157889.3060408@free.fr>	<4015B3C2.4040604@matroska.org>	<4015EE41.10309@matroska.org>	<40162E26.4040200@free.fr>
	<40162F02.30809@free.fr>
Message-ID: <40163152.5060203@free.fr>

Steve Lhomme wrote:

> Steve Lhomme wrote:
> 
>> Some thoughts about the editor...
>>
>> I was just reading the interresting IP article, and read about editing 
>> and how studios can have 2 or 3 different edits of the same movie. 
>> That made me think of how you could compare them easily. And as we do 
>> with software sources, we just make a diff. But it is impossible with 
>> binary data. So I suggests that TCVE could store an edit as an XML 
>> file. This way you can compare and create new edits easily from the 
>> same "raw" source.
> 
> 
> And now pushing the idea further, we should be able to play a movie from 
> that XML source file. Just like an AVIsynth script but with more 
> features : at least VFR, but probably multi-tracks, chapters, control 
> tracks, menus, etc.

Pushing it even further... I think this file format to save an "editing 
session" is actually the heart of TCVE. It should be possible to store 
everything in that file format. And therefore TCVE simply becomes a GUI 
editor for that file format.

So if everyone agree, we should concentrate on this file format a lot.



From intel69160 at hotmail.com  Tue Jan 27 18:03:40 2004
From: intel69160 at hotmail.com (Info)
Date: Tue, 27 Jan 2004 18:03:40 +0100
Subject: [Matroska-general] Bad Boys II en bobdown
Message-ID: <20040127170352.58D71440021@p15097576.pureserver.info>

An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-general/attachments/20040127/523e8bd8/attachment.html>

From chris at matroska.org  Wed Jan 28 10:07:28 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 28 Jan 2004 10:07:28 +0100
Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate,
 plugin based video editing tool
In-Reply-To: <40163152.5060203@free.fr>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>	<40157889.3060408@free.fr>	<4015B3C2.4040604@matroska.org>	<4015EE41.10309@matroska.org>	<40162E26.4040200@free.fr>	<40162F02.30809@free.fr>
	<40163152.5060203@free.fr>
Message-ID: <40177BD0.6040200@matroska.org>

Steve Lhomme wrote:

> Pushing it even further... I think this file format to save an 
> "editing session" is actually the heart of TCVE. It should be possible 
> to store everything in that file format. And therefore TCVE simply 
> becomes a GUI editor for that file format.

Steve, dont you think one step too much into the future here, scaring 
all developers away ? This editing language is certainly a good idea, 
but shouldn't we concentrate on the very basic sceleton for now, means 
to create a framework that will allow

- input plugins
- muxing of MKV files

??

If you look at my roadmap below

-------------------------------------------
1. Define basic structure, including the internal 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.
--------------------------------------------

you will find that the first goal must be to come to step 4. , means to 
replace the basic muxing functionality of mkvmerge. Your 'editing 
command file format' would become interesting from step 6. no ?

> So if everyone agree, we should concentrate on this file format a lot.

We shouldnt take the same risk as with matroska here, wanting too much 
at a time, risking everything goes down the drain. Lets make a policy of 
small steps here, first make a working muxer with a plugin structure, 
then add file splitting, then editing, then reencoding using codec 
plugins, then NLE . We need help for this huge task, and we should have 
learned from experience that you dont get support from people when you 
are in the planning stage still, nobody will give a dime for our nice 
plans. Give them something basic and working to play with, and interest 
and support will come all of a sudden. Just my 2 cents

Christian



From moritz at bunkus.org  Wed Jan 28 10:44:22 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 28 Jan 2004 10:44:22 +0100
Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate,
	plugin based video editing tool
In-Reply-To: <40177BD0.6040200@matroska.org>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>
	<40157889.3060408@free.fr> <4015B3C2.4040604@matroska.org>
	<4015EE41.10309@matroska.org> <40162E26.4040200@free.fr>
	<40162F02.30809@free.fr> <40163152.5060203@free.fr>
	<40177BD0.6040200@matroska.org>
Message-ID: <20040128094422.GN14653@bunkus.org>

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.

I like Chris' roadmap so far, especially the first four points. What I
really want to have is to have the core and the GUI separated from each
other. I also want to have the core being completely scriptable. Ideally
the GUI would only translate its actions (open file, seek to time x, get
the number of tracks etc) into such script commands. Therefore this
script language needs some thinking. I have very little experience with
such stuff, so others are probably more knowledgable (avisynth users?).

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

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
number of GUI toolkits to chose from is very, very small. Qt is out of
the loop as it cannot be used royalty-free on Windows anymore
(especially not if we ever want to accept money for it if I understand
it correctly). Gtk might be a solution as it does run on Windows. I'd
prefer wxWindows as it is very comprehensive and takes care of a lot of
xplatform issues right away.

What else? Hmmm... I'd also prefer to use Subversion as the version
control system as it has numerous advantages over plain CVS, but as this
will be a Corecodec project I guess that is out of the question, and
we're stuck with CVS again.

You see, Steve, I definitely do not want to discredit your ideas. It's
just that we have more than enough work ahead of us that is totally
independant of what you want to achieve. Let's concentrate on this
instead, please.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Wed Jan 28 11:20:39 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 28 Jan 2004 11:20:39 +0100
Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate,
 plugin based video editing tool
In-Reply-To: <20040128094422.GN14653@bunkus.org>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>	<40157889.3060408@free.fr>
	<4015B3C2.4040604@matroska.org>	<4015EE41.10309@matroska.org>
	<40162E26.4040200@free.fr>	<40162F02.30809@free.fr>
	<40163152.5060203@free.fr>	<40177BD0.6040200@matroska.org>
	<20040128094422.GN14653@bunkus.org>
Message-ID: <40178CF7.3090700@free.fr>

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 like Chris' roadmap so far, especially the first four points. What I
> really want to have is to have the core and the GUI separated from each
> other. I also want to have the core being completely scriptable. Ideally

Mmm, that script your talking about for phase 1 is the same one I was 
talking about...

> the GUI would only translate its actions (open file, seek to time x, get
> the number of tracks etc) into such script commands. Therefore this
> script language needs some thinking. I have very little experience with
> such stuff, so others are probably more knowledgable (avisynth users?).

Maybe Cyrius has some. Because VDub is also scriptable a bit (at least 
exectue batch processings).

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

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

> number of GUI toolkits to chose from is very, very small. Qt is out of
> the loop as it cannot be used royalty-free on Windows anymore

Uh ? I didn't know something has changed here !

> (especially not if we ever want to accept money for it if I understand

If we want money we need to pay a license of a few 1,000 USD (IIRC).

> it correctly). Gtk might be a solution as it does run on Windows. I'd
> prefer wxWindows as it is very comprehensive and takes care of a lot of
> xplatform issues right away.

Yes, and it looks native ! Which is the best way to have a user feel 
comfortable. (and is probably the most efficient CPU wise).

> What else? Hmmm... I'd also prefer to use Subversion as the version
> control system as it has numerous advantages over plain CVS, but as this
> will be a Corecodec project I guess that is out of the question, and
> we're stuck with CVS again.

We might talk to Cyt0plas about it. But we could also use your 
subversion system. And only feed CVS for the tagged versions. (extra 
work for no gain...)

> You see, Steve, I definitely do not want to discredit your ideas. It's
> just that we have more than enough work ahead of us that is totally
> independant of what you want to achieve. Let's concentrate on this
> instead, please.

Well, you're not that far from my ideas :)



From steve.lhomme at free.fr  Wed Jan 28 11:35:32 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 28 Jan 2004 11:35:32 +0100
Subject: [Matroska-general] Re: [Media-api] Design ideas for the editing
	system.
In-Reply-To: <20040128003313.7954.qmail@mail.com>
References: <20040128003313.7954.qmail@mail.com>
Message-ID: <40179074.3070403@free.fr>

Toby Hudon wrote:

> Ok, now that we're supposedly working on the file format, I've been thinking about what we really need to put in there.
> 
> Basicly my main idea is that we have something that looks like this:
> 1 or more major media types (audio/video/text), specifics like codec or colorspace are unimportant.

I agree if the architecture can be extended later. Any hacker will be 
able to add it's own format then. As long as we can handle the most 
tricky cases.

One feature we need is the easy transcoding of AVI files into MKV/MKA 
files. With an option to keep VfW/DShow/ACM compatibility or convert to 
the native Matroska format.

> For each media type, there exists ONE control stream, and one or more source streams. All have timecodes.
> 
> The control stream basicly is the master timecode system, and the timecodes in each control stream (not source streams) should be linked so they always sync, this way we can make sure our video and audio line up.

Why do you need a 3rd stream to have 2 streams in sync ?

> The source streams each have their own (relative) timecode sequences that we can access.

Roger that.

> So, to edit a file, for simple things like cuts, speed up, slow down, and reverse, all we have to do is in the master control stream indicate what timecode of what source track we want at a given "master clock" in the control stream, and the direction and rate of play. We just indicate which tracks are active then and what relative timecodes from those tracks we want to use. Since we can associate with any timecode from the source tracks looping or time scaling is not a problem, and just changing which track is active or inactive or which timecode we wish to display in a track lets us perform cuts. This would basicly be able to perform most of what VirtualDub and such do without much effort, all it takes is editing which track and position you want at each point in time.
> 
> Now, as for more complex effects, you'd have to have an external system to render them, so it would be a bit more like function calls or ML tags. I.e., for a fade effect, we might indicate two active tracks in the control stream, and their start timecode, rate, and direction of play, then have another variable which tells the editor we wish to render an effect or apply some filter here. The parameters passed to that effect or filter would probably vary depending on which one it is, so it probably needs to be a bit more thought out than what I've done so far. So basicly to fade we say something in the control stream like:
> 
> 50: <track ID="1" timeindex="13953" rate="24" direction="forward"><track ID="3" timeindex="2234" rate="30" direction="reverse"><fade input1="1" input2="3" duration="300">

I suggest we have a look at the possibilities of SMIL instead of 
reinventing the wheel.

> By putting everything in the control stream, this means we can take source tracks from existing files (direct stream copy) without modification other than just parsing them into the container, regardless of codec or attributes. This means adding a new video source track to an existing edit project should be as simple as selecting a new file to read source from, and doing a data copy into a new track on the project file. Granted there's probably going to be some sort of fun involving interleaving the new data etc, but that should be transparent to this process and handled by the container for the editing file format.

Yes, the Direct Stream Copy is something really important.

> Rendering a project to a final output file is as simple as reading the control stream in order, displaying the relative parts of the source streams as needed, and calling various rendering plugins to handle transitions and effects at specified times. All we need to do is take the desired output samplerate/framerate of the video we're creating, and generate the result at each point in time we need a frame. This may require some interpolation but that's things that should probably be handled "transparently" by the editor for ease of use. I realize this will be much harder than it sounds but at least it should only need to be written once if done right.

IMO the pull model might not be a good idea. But why not. We need to 
make sure it works fine with VFR content too.




From jcsston at wiesneronline.net  Wed Jan 28 19:01:23 2004
From: jcsston at wiesneronline.net (Jory)
Date: Wed, 28 Jan 2004 12:01:23 -0600
Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate,
	plugin based video editing tool
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>	<40157889.3060408@free.fr><4015B3C2.4040604@matroska.org>	<4015EE41.10309@matroska.org><40162E26.4040200@free.fr>	<40162F02.30809@free.fr><40163152.5060203@free.fr>	<40177BD0.6040200@matroska.org><20040128094422.GN14653@bunkus.org>
	<40178CF7.3090700@free.fr>
Message-ID: <000001c3e5ca$996da4c0$0200a8c0@jcsston>


----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>; "General talk about Matroska and other
products" <matroska-general at lists.matroska.org>
Sent: Wednesday, January 28, 2004 4:20 AM
Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate,
plugin based video editing tool


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


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

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

Also the plugins would need a good options interface/GUI. Prehaps we could
do something like I prototyped in LemAPI.
"
 // Here you supply your supported options, names, types (Integer, String,
Boolean), and supply a short description about the option
<Option name="Copy Info Frames" desc="If set to True Info Frames will be
copied" type="Boolean">True</Option>
<Option name="Read LAME Info Frame" desc="If set to True Info Frames will be
copied" type="Boolean">False</Option>
<Option name="Frame Size" desc="This is a dummy to show Integer"
type="Integer" range="0-10">10</Option>
"
then for each plugin we could generate a small options dialog with the XML
options fragment.
----------------------------------------------------------
|                              MPA Input Options                          |
|      Plugin by Steve Lhomme <steve.lhomme at free.fr>    |
|
|
|                            X Copy Info Frames                          |
|                            O Read LAME Info Frame                |
|                           Frame Size : 10 (a spinbox control)     |
|
|
|                             OK           Cancel
|
----------------------------------------------------------

The checkbox would have the desc fields as tooltips. With that type of data
it should also be easy to create .htm/.txt docs for those who want to script
from scratch.

> > it correctly). Gtk might be a solution as it does run on Windows. I'd
> > prefer wxWindows as it is very comprehensive and takes care of a lot of
> > xplatform issues right away.
>
> Yes, and it looks native ! Which is the best way to have a user feel
> comfortable. (and is probably the most efficient CPU wise).
>
I wouldn't use anything but wxWindows. :)
GTK, along with it not looking native, requires a ton of version dependant
.dll's. Which under Windows is just asking for trouble. GIMP doesn't work
here because of that, some rogue png.dll is the wrong version and crashes
it.

Later,
Jory



From steve.lhomme at free.fr  Wed Jan 28 20:10:03 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 28 Jan 2004 20:10:03 +0100
Subject: [Matroska-general] Re: Variable Framerate,
	plugin based video editing tool
In-Reply-To: <000001c3e5ca$996da4c0$0200a8c0@jcsston>
References: <20040126201838.16629.qmail@web12902.mail.yahoo.com>	<40157889.3060408@free.fr><4015B3C2.4040604@matroska.org>	<4015EE41.10309@matroska.org><40162E26.4040200@free.fr>	<40162F02.30809@free.fr><40163152.5060203@free.fr>	<40177BD0.6040200@matroska.org><20040128094422.GN14653@bunkus.org>	<40178CF7.3090700@free.fr>
	<000001c3e5ca$996da4c0$0200a8c0@jcsston>
Message-ID: <4018090B.6080409@free.fr>

Jory wrote:

> Also the plugins would need a good options interface/GUI. Prehaps we could
> do something like I prototyped in LemAPI.
> "
>  // Here you supply your supported options, names, types (Integer, String,
> Boolean), and supply a short description about the option
> <Option name="Copy Info Frames" desc="If set to True Info Frames will be
> copied" type="Boolean">True</Option>
> <Option name="Read LAME Info Frame" desc="If set to True Info Frames will be
> copied" type="Boolean">False</Option>
> <Option name="Frame Size" desc="This is a dummy to show Integer"
> type="Integer" range="0-10">10</Option>
> "
> then for each plugin we could generate a small options dialog with the XML
> options fragment.
> ----------------------------------------------------------
> |                              MPA Input Options                          |
> |      Plugin by Steve Lhomme <steve.lhomme at free.fr>    |
> |
> |
> |                            X Copy Info Frames                          |
> |                            O Read LAME Info Frame                |
> |                           Frame Size : 10 (a spinbox control)     |
> |
> |
> |                             OK           Cancel
> |
> ----------------------------------------------------------
> 
> The checkbox would have the desc fields as tooltips. With that type of data
> it should also be easy to create .htm/.txt docs for those who want to script
> from scratch.

Yup.
One interresting thing I saw in the iTunes library is the way they store 
data in XML. They do something like :
<integer name="Frame Size" range="0-10">8</integer>

This way you only have a limited set of XML tags and you can verify the 
content easily.
...just an idea :)




From chris at matroska.org  Fri Jan 30 12:13:17 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 30 Jan 2004 12:13:17 +0100
Subject: [Matroska-general] License Form for TCME
Message-ID: <401A3C4D.1030108@matroska.org>


Hi,

there has been a lot of discussion about the license for TCME, before 
even a single line was coded, but thats actually not a bad thing either.

Here the options and the Pro's / Con's , in a summary :

*1. Closed source / no license :*

Pro : allows selling ; no forks possible ; all binaries fully 
controllable with respect to their functionality
Con : nobody from outside will contribute to it, we have to do 
everything ourselves ; bad commercial reputation

My vote : not a bad option with some advantages, but not my favourite

*2. QPL / GPL dual license*

Pro : allows selling of the program later, for everything contributed 
under the QPL license
Con : contributors can choose either license for for their patches, 
doesnt prevent forking at all

My vote : BAD !

*3. QPL single license*

Pro : Makes forking not so easy, and always obvious to informed users ; 
allows selling of the program ; patches sent by contributors can be sold 
also
Con : Gives the whole project a bad, commercial smell, even if we never 
plan to market the program

My vote : We have better options

*4. GPL single license*

Pro : well accepted license type with good reputation in the OSS 
community ; contributors will feel safe about doing so ; free protection 
from the GNU lawyers in case a company will steal the code ; lot of code 
out there that could be reused
Con : an invitation to fork the project, as GPL is pro-fork

My vote : maybe the best option we have, if we dont make 5.

*5. New license, 'Corecodec Public Antifork License'*

Explanation : We can basically copy some paragraphs from the GPL, but 
add other paragraph to strictly forbid to fork from the project, means 
the complete source/binary distribution has to be changed compared to 
the GPL, making it ( of course ) completely incompatible with the GPL 
itself ; special paragraphs have to deal with what's happening in case
- the original host ( Corecodec ) disappears, and the devs cant agree on 
a new host
- the project is declared dead by the majority of the main devs/admins
- the originall devs decide to relicense and sell the code
For these cases a 'fallback to GPL' should be part of the license, 
making the program free-software in the terms of the FSF again, to avoid 
abuse and to help contributors to trust in the goals. I expect that many 
other projects may also have a use for the license that way.
Pro :  raises public awareness for Corecodec, especially if we manage to 
get OSI approval for it ( i checked many other licenses, there is no 
similar license existing )
Con : people will instantaneously cry : 'yet another license, and why ?' 
; higher explanation effort

My vote : lets discuss that here, i'd love to hear your opinions


Guys, its essential that you all give some input here. Dont complain 
afterwards that you dont like our decision !

Christian



From moritz at bunkus.org  Fri Jan 30 12:28:52 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 30 Jan 2004 12:28:52 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A3C4D.1030108@matroska.org>
References: <401A3C4D.1030108@matroska.org>
Message-ID: <20040130112852.GE14653@bunkus.org>

Heya,

How I see it:

two decisions. First: closed or open, and I think we all agree on
'open'. Second: which one?

Here Chris has a lot of fear that others will fork from us. I don't see
that. Neither do I see a problem with people DOing a fork. Why should we
try to prevent it? A fork cannot use the original name just like that. A
fork will only occur if we drive other developpers away, or if they want
to head in a totally different direction than we go. Then by all means
they should fork away. It won't hurt us. It would only hurt us if we
ourselves fork from us dividing our development power.

For me this is really not an issue. I strongly believe in the freedom
the GPL offers. I don't see forks happening all that often. When it does
happen (e.g. Samba) those projects usually profit from each other. In
other cases (e.g. mplayer) the forked project will not have the momentum
the original one has.

Next point: extra license. I don't see any need for yet another license
if we don't have that anti-fork-panic. We may have a problem with 3rd
party plugins, though, if we chose the GPL as I'm not really sure how a
closed source plugin would work with a GPL'ed program that links that
plugin in. I think it's ok, but IANAL.

Another problem. This project is HUGE (as in HUUUUGE). People are
talking about a complete NLVE (non linear video editor), people talk
about a very powerful program. Now you want to add the work of designing
a new license on top of that?

I don't see us getting anywhere anytime soon...

Another license won't attract other developpers, btw. Most know the GPL,
no one will know the CC.org license. They'll all ask those questions
('why?', 'what does that mean?'), and we'll spend even more time with
this issue that could have been spent much more productive.

I don't want to earn money with this thing. I want to produce something
useable, free of charge and have fun creating it. I want to work with
others on it, and if others may benefit from our work then I'm all for
it.

Use the GPL.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Fri Jan 30 13:13:38 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 30 Jan 2004 13:13:38 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A3C4D.1030108@matroska.org>
References: <401A3C4D.1030108@matroska.org>
Message-ID: <401A4A72.4050201@free.fr>

Christian HJ Wiesner wrote:

> *3. QPL single license*
> 
> Pro : Makes forking not so easy, and always obvious to informed users ; 
> allows selling of the program ; patches sent by contributors can be sold 
> also
> Con : Gives the whole project a bad, commercial smell, even if we never 
> plan to market the program
+ not GPL compatible

> *4. GPL single license*
> 
> Pro : well accepted license type with good reputation in the OSS 
> community ; contributors will feel safe about doing so ; free protection 
> from the GNU lawyers in case a company will steal the code ; lot of code 
> out there that could be reused

That's what GNU says when they get the copyright ownership of a 
software. I don't know any case where it actually happened. The GPL has 
never been tested against a real court.

> Con : an invitation to fork the project, as GPL is pro-fork

How many program fork do you know ? When a project gets quite consistent 
with a solid dev involvement there is no good reason to start it again 
to do something very different. (that's also why we should work with the 
GStreamer ppl instead of making WinStreamer if we ever choose this 
solution).

> My vote : maybe the best option we have, if we dont make 5.

How about LGPL ? Or BSD ?
After all Xiph use the BSD and noone ever used a fork of their code (or 
maybe OGM can be considered as such ?)

Of course it's very hard to sell the software if the code is LGPL or 
BSD. But IMO wether it's GPL, LGPL or BSD isn't really what you sell. 
You sell some support for the software (which we also offer for free to 
the community) and corrections when needed... What would be sold in the 
commercial version that would not be in the free one ?

> *5. New license, 'Corecodec Public Antifork License'*
> 
> Explanation : We can basically copy some paragraphs from the GPL, but 
> add other paragraph to strictly forbid to fork from the project, means 

That's easy, if you do so you're reinventing the QPL (which is like a 
GPL with patches required).

> For these cases a 'fallback to GPL' should be part of the license, 
> making the program free-software in the terms of the FSF again, to avoid 
> abuse and to help contributors to trust in the goals. I expect that many 
> other projects may also have a use for the license that way.

Believe me, there are really enough OSI licenses around. Making a new 
license is a complicated + long task. And none of us are lawyers... I've 
worked on such a new license for months until I realised the QPL+GPL was 
what I needed.

> Con : people will instantaneously cry : 'yet another license, and why ?' 
> ; higher explanation effort

And more time spent on something other than the actual project...




From steve.lhomme at free.fr  Fri Jan 30 13:15:27 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 30 Jan 2004 13:15:27 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A4A72.4050201@free.fr>
References: <401A3C4D.1030108@matroska.org> <401A4A72.4050201@free.fr>
Message-ID: <401A4ADF.4010705@free.fr>

Steve Lhomme wrote:

>> Con : an invitation to fork the project, as GPL is pro-fork
> 
> 
> How many program fork do you know ? When a project gets quite consistent 

OK, I forgot a major one : VirtualDubMod. Which happened just because 
Avery wanted to keep control on everything with his own view. I don't 
think we can fear such a thing among us.



From suiryc at yahoo.com  Fri Jan 30 13:28:53 2004
From: suiryc at yahoo.com (Cyrius)
Date: Fri, 30 Jan 2004 04:28:53 -0800 (PST)
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A3C4D.1030108@matroska.org>
Message-ID: <20040130122853.29132.qmail@web12908.mail.yahoo.com>

--- Christian HJ Wiesner <chris at matroska.org> wrote:
> 
> Hi,
> 
> there has been a lot of discussion about the license for TCME, before
> 
> even a single line was coded, but thats actually not a bad thing
> either.
> 
> Here the options and the Pro's / Con's , in a summary :
> 
> *1. Closed source / no license :*
> 
> Pro : allows selling ; no forks possible ; all binaries fully 
> controllable with respect to their functionality
> Con : nobody from outside will contribute to it, we have to do 
> everything ourselves ; bad commercial reputation
> 
> My vote : not a bad option with some advantages, but not my favourite

Closed source means you won't get a lot of supports from 'free' coders.
Such a huge project will already progress slowly so ... :p

> *2. QPL / GPL dual license*
> 
> Pro : allows selling of the program later, for everything contributed
> 
> under the QPL license
> Con : contributors can choose either license for for their patches, 
> doesnt prevent forking at all
> 
> My vote : BAD !

Indeed not the best solution if you want to merge changes made under
the GPL license by other people, and plan to sell the code :p

> *3. QPL single license*
> 
> Pro : Makes forking not so easy, and always obvious to informed users
> ; 
> allows selling of the program ; patches sent by contributors can be
> sold 
> also
> Con : Gives the whole project a bad, commercial smell, even if we
> never 
> plan to market the program
> 
> My vote : We have better options

As I already said I don't think QPL will prevent determined people from
forking the project. So it is good only for comercial reasons (and in
this case bad for the people who contributed by patches since only the
original authors will get something).

> *4. GPL single license*
> 
> Pro : well accepted license type with good reputation in the OSS 
> community ; contributors will feel safe about doing so ; free
> protection 
> from the GNU lawyers in case a company will steal the code ; lot of
> code 
> out there that could be reused
> Con : an invitation to fork the project, as GPL is pro-fork
> 
> My vote : maybe the best option we have, if we dont make 5.

Yes it allows forking. But as explained by Mosu when this happens it's
generally all for the best ;).

> *5. New license, 'Corecodec Public Antifork License'*
> 
> Explanation : We can basically copy some paragraphs from the GPL, but
> 
> add other paragraph to strictly forbid to fork from the project,
> means 
> the complete source/binary distribution has to be changed compared to
> 
> the GPL, making it ( of course ) completely incompatible with the GPL
> 
> itself ; special paragraphs have to deal with what's happening in
> case
> - the original host ( Corecodec ) disappears, and the devs cant agree
> on 
> a new host
> - the project is declared dead by the majority of the main
> devs/admins
> - the originall devs decide to relicense and sell the code
> For these cases a 'fallback to GPL' should be part of the license, 
> making the program free-software in the terms of the FSF again, to
> avoid 
> abuse and to help contributors to trust in the goals. I expect that
> many 
> other projects may also have a use for the license that way.
> Pro :  raises public awareness for Corecodec, especially if we manage
> to 
> get OSI approval for it ( i checked many other licenses, there is no 
> similar license existing )
> Con : people will instantaneously cry : 'yet another license, and why
> ?' 
> ; higher explanation effort
> 
> My vote : lets discuss that here, i'd love to hear your opinions

Doing yet another license require time and money (you certainly need to
hire a lawyer to ensure the new license will do exactly what you
meant).
Moreover this new license, due to its restriction, will likely be
listed as 'incompatible with GPL' and thus prevent many people from
contributing.


So I am also for a GPL license.
BBB mentioned on IRC that he was using L-GPL even for programs (because
he found it more convenient). Maybe he could join the discussion and
explain why LGPL could be better than GPL for programs.


Best regards
Cyrius

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/


From steve.lhomme at free.fr  Fri Jan 30 13:40:01 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 30 Jan 2004 13:40:01 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <20040130122853.29132.qmail@web12908.mail.yahoo.com>
References: <20040130122853.29132.qmail@web12908.mail.yahoo.com>
Message-ID: <401A50A1.80108@free.fr>

Cyrius wrote:

> So I am also for a GPL license.
> BBB mentioned on IRC that he was using L-GPL even for programs (because
> he found it more convenient). Maybe he could join the discussion and
> explain why LGPL could be better than GPL for programs.

Then we are already 2 in favor of the LGPL :)



From moritz at bunkus.org  Fri Jan 30 14:10:43 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 30 Jan 2004 14:10:43 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <20040130112852.GE14653@bunkus.org>
References: <401A3C4D.1030108@matroska.org> <20040130112852.GE14653@bunkus.org>
Message-ID: <20040130131043.GA3114@bunkus.org>

Heya,

just to clarify this: I'm all for the GPL OR the LGPL. Either license is
fine with me, although we might have fewer legal problems with 3rd party
stuff if it is LGPL. And if people want to take our source into a GPL
program then that's perfectly fine as the LGPL explicitely allows the
relicensing of the stuff under the GPL.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From chris at matroska.org  Fri Jan 30 14:39:15 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 30 Jan 2004 14:39:15 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A50A1.80108@free.fr>
References: <20040130122853.29132.qmail@web12908.mail.yahoo.com>
	<401A50A1.80108@free.fr>
Message-ID: <401A5E83.9050604@matroska.org>

Steve Lhomme wrote:

> Cyrius wrote:
>
>> So I am also for a GPL license.
>> BBB mentioned on IRC that he was using L-GPL even for programs (because
>> he found it more convenient). Maybe he could join the discussion and
>> explain why LGPL could be better than GPL for programs.
>
> Then we are already 2 in favor of the LGPL :) 

Going L-GPL, please correct me if i'm wrong, would allow companies to 
use our video editor for their larger works, and sell it . Is this what 
we want ?

I agree that for a library, like libmatroska/libebml, or frameworks like 
gstreamer, this can be pretty interesting because they can strenghten 
their position as standards with every single app using the library of 
the framework, but why should we allow anybody to make profit from our 
video editor ?

Steve, if you think about it, there is a much better reason to release 
libmatroska/libebml under a L-GPL license than TCME ?

Christian



From steve.lhomme at free.fr  Fri Jan 30 14:43:43 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 30 Jan 2004 14:43:43 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A5E83.9050604@matroska.org>
References: <20040130122853.29132.qmail@web12908.mail.yahoo.com>	<401A50A1.80108@free.fr>
	<401A5E83.9050604@matroska.org>
Message-ID: <401A5F8F.4060907@free.fr>

Christian HJ Wiesner wrote:

>> Then we are already 2 in favor of the LGPL :) 
> 
> 
> Going L-GPL, please correct me if i'm wrong, would allow companies to 
> use our video editor for their larger works, and sell it . Is this what 
> we want ?

Any OSI approved license will not prevent any company from doing it. 
Open means at least you can do whatever you want with the code. 
Especially sell it.

With LGPL if they make modifications to the core (not the plugins) they 
have to give the modified source when you buy the software.

> I agree that for a library, like libmatroska/libebml, or frameworks like 
> gstreamer, this can be pretty interesting because they can strenghten 
> their position as standards with every single app using the library of 
> the framework, but why should we allow anybody to make profit from our 
> video editor ?

Anybody will be able to make profit from it. But will there be any dumb 
enough people to buy a software you can get for free ?

> Steve, if you think about it, there is a much better reason to release 
> libmatroska/libebml under a L-GPL license than TCME ?

indeed...



From chris at matroska.org  Fri Jan 30 15:05:25 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 30 Jan 2004 15:05:25 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A5F8F.4060907@free.fr>
References: <20040130122853.29132.qmail@web12908.mail.yahoo.com>	<401A50A1.80108@free.fr>	<401A5E83.9050604@matroska.org>
	<401A5F8F.4060907@free.fr>
Message-ID: <401A64A5.4000203@matroska.org>

Steve Lhomme wrote:

> Christian HJ Wiesner wrote:
>
>> Steve, if you think about it, there is a much better reason to 
>> release libmatroska/libebml under a L-GPL license than TCME ?
>
> indeed...

Great !! I recommend to relicense under a L-GPL/QPL dual license then. 
Cyrius, Mosu : do you both agree ?

Christian



From moritz at bunkus.org  Fri Jan 30 15:12:59 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 30 Jan 2004 15:12:59 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A64A5.4000203@matroska.org>
References: <20040130122853.29132.qmail@web12908.mail.yahoo.com>
	<401A50A1.80108@free.fr> <401A5E83.9050604@matroska.org>
	<401A5F8F.4060907@free.fr> <401A64A5.4000203@matroska.org>
Message-ID: <20040130141259.GA15283@bunkus.org>

Heya,

> Great !! I recommend to relicense under a L-GPL/QPL dual license then. 
> Cyrius, Mosu : do you both agree ?

I don't understand...

a) ... in which way the QPL differs from GPL and
b) ... why we need two licenses.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From chris at matroska.org  Fri Jan 30 15:35:44 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 30 Jan 2004 15:35:44 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <20040130141259.GA15283@bunkus.org>
References: <20040130122853.29132.qmail@web12908.mail.yahoo.com>	<401A50A1.80108@free.fr>
	<401A5E83.9050604@matroska.org>	<401A5F8F.4060907@free.fr>
	<401A64A5.4000203@matroska.org> <20040130141259.GA15283@bunkus.org>
Message-ID: <401A6BC0.9000709@matroska.org>

Moritz Bunkus wrote:

>Heya,
>
>>Great !! I recommend to relicense under a L-GPL/QPL dual license then. 
>>Cyrius, Mosu : do you both agree ?
>>    
>>
>
>I don't understand...
>a) ... in which way the QPL differs from GPL and
>b) ... why we need two licenses.
>Mosu
>  
>
I was just talking about this on IRC in detail, and BBB confirmed there 
is use for the dual license.

The L-GPL makes us compatible with practically any OSS project under the 
sun. Thats great. On the other hand, it would also allow commercial apps 
to use libmatroska for free, as long as they stick to the rules for 
using L-GPL libs in closed software, i.e. :
- They distribute the library sourcecode, as well as modifications they 
made to it to be able to use it, together with their program
- They create object files which will allow the user of their software 
to update the library by themselves
Both is certainly feasible for them, but could be considered as a real 
pain in the ass by them, so they wont support matroska.

The QPL license would give them the chance to overcome those rules, and 
simply implement our libs into their programs, after we granted them the 
explicit right to do so. Of course you might now argue that this is well 
possible with L-GPL also, as we can relicense our code under whatever 
form we like to, so they can us it. The nice thing by doing this via 
QPL, as i see it,  is that those companies can automatically update 
their apps against our latest version of the libs ( if the modifications 
are released under QPL also, thats the control we have ), and we dont 
have to relicense new versions of the code for them all the time.

Does this make sense to you ?

Christian



From joerg at britannica.bec.de  Fri Jan 30 16:09:23 2004
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Fri, 30 Jan 2004 16:09:23 +0100
Subject: [Matroska-general] License Form for TCME
In-Reply-To: <401A6BC0.9000709@matroska.org>
References: <20040130122853.29132.qmail@web12908.mail.yahoo.com>
	<401A50A1.80108@free.fr> <401A5E83.9050604@matroska.org>
	<401A5F8F.4060907@free.fr> <401A64A5.4000203@matroska.org>
	<20040130141259.GA15283@bunkus.org> <401A6BC0.9000709@matroska.org>
Message-ID: <20040130150923.GB45652@britannica.bec.de>

On Fri, Jan 30, 2004 at 03:35:44PM +0100, Christian HJ Wiesner wrote:
> The L-GPL makes us compatible with practically any OSS project under the 
> sun. Thats great. On the other hand, it would also allow commercial apps 
> to use libmatroska for free, as long as they stick to the rules for 
> using L-GPL libs in closed software, i.e. :
> - They distribute the library sourcecode, as well as modifications they 
> made to it to be able to use it, together with their program

Well, they must provide modifications under the LGPL and hand out the
code on request.

> - They create object files which will allow the user of their software 
> to update the library by themselves

This is only true for statically linking. Most apps are dynamically
linked anyway.

Joerg

> Christian