theora dev - Sep 2004 - Project Announcement : New Media Container Format 'matroska'

On Sat, Dec 07, 2002 at 10:29:29PM +0100, ChristianHJW
wrote:
> 
> Please allow me to announce the creation of a new open source Media
> Container Format, named 'matroska'
> 
> Project page is here http://sf.net/projects/matroska ; homepage is
> http://matroska.sourceforge.net , HTML should be online soon.
Another redundant project? 

"ten BSD programmers are sealed in a computer lab for a month.  At the
end of the month, the door is opened.  Investigators discover,
bloodied and dead, all ten programmers--- and thirteen new flavors of
BSD."
> I am personally not happy about the fact that we had to found a new
project,
> but it seems that it was the only alternative now. Of course we are well
> aware of the fact that both projects will become weaker this way, but we
> hope to be able to release the container including creation tools and
> playback filters until January/February 2003, and then the users will
decide
> what format they prefer.
This announcement is not about 'letting the users decide'.  You
haven't released or produced anything yet. This is the grown-up
equivalent of declaring 'I didn't get to do it my way, so I'm taking
my toys home with me' and watching to see which kids in the crowd are
going to follow you home.  We're on the way to having every dissident
hacker pushing his own incompatable container format, most based on
someone else's container format.  OK, sure, whatever.

"Step one: Achieve something. Step two: toot horn"

If you were really interested only in doing something different or
trying out something new, you'd just have gone off and done it, and
let the world know if it did/didn't work out. We already went through
all this a year or two ago when you all declared the beginning of MCF
and sent mail to the Ogg lists that it would be better than our
project in every way and we should abandon Ogg and use MCF.  It was
quite the initial introduction and left a lasting impression.  So,
I'll repeat a previous flame that the original MCF folks never really
rebutted (just seemed to ignore).

Quite a few MCF proponents keep touting things that Ogg can't
do... except they're wrong.  For example, somone told with great
confidence on HA that he was going with MCF because there was no way
to figure out what codecs Ogg used and that each mixed stream type was
hardwired.  That would really suck if it were true.  It isn't.

Looking at it from a high level, Ogg (the software) is full of feature
hooks for which no one has written the code yet.  But it's apparently
easier to start from scratch (again), effectively abandoning a half
completed system that's already running, solid, and deployed
worldwide, and then use my own lists to pull people out of the project
that works and has forward momentum.  A second time.  It's in poor
taste all over again.

</flame>

Personally, my position is that XML (binary or no) belongs in a stream
or at a higher non-linear level-- not defining the lowest level
transport attributes.  The correct way to build a large system is not
to smash every conceivable feature into a single monolithic API layer.
Build small pieces that work together. 

We here at Xiph started with:

1) a nice, robust linear transport layer that's optimized specifically
and only for linear transport, ie, 'does one thing very well and can
be used to build larger things'

2) filters, aka OggFile, the first 'larger thing', now in progress
along with resource usage optimizations (eg, zero-copy). 

We're going to get that right before building a huge feature-rich
system on a foundation that's unproven / doesn't exist.

In summary, I'd prefer you let the people here who have demonstrated
they're capable of working together without forking continue to do so
without this ongoing pseudotechnical distraction.  

(And if you want to do something productive with XML, how about
contribute to the metaheader or XML page stream type in Ogg?  Hmmm?)

I'm not on most of the lists in the cc: line.  If you want to make
sure I read your flames before ignoring them, please make sure I'm
copied.

Monty

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Who in their right mind would go out and advertise on another project''s
mailing list that a new project is being started?

----- Original Message -----
From: "Monty" <xiphmont@xiph.org>
To: <advocacy@xiph.org>
Cc: <flac-dev@lists.sourceforge.net>; <theora-dev@xiph.org>;
<gstreamer-devel@lists.sourceforge.net>;
<uci-devel@lists.sourceforge.net>;
<virtualdubmod-devel@lists.sourceforge.net>; <xvid-devel@xvid.org>;
<0@main.gmane.org>
Sent: Saturday, December 07, 2002 3:10 PM
Subject: [theora-dev] Re: [advocacy] Project Announcement : New Media
Container Format ''matroska''

<p>>
>
>
> On Sat, Dec 07, 2002 at 10:29:29PM +0100, ChristianHJW wrote:
> >
> > Please allow me to announce the creation of a new open source Media
> > Container Format, named ''matroska''
> >
> > Project page is here http://sf.net/projects/matroska ; homepage is
> > http://matroska.sourceforge.net , HTML should be online soon.
>
> Another redundant project?
>
> "ten BSD programmers are sealed in a computer lab for a month.  At the
> end of the month, the door is opened.  Investigators discover,
> bloodied and dead, all ten programmers--- and thirteen new flavors of
> BSD."
>
> > I am personally not happy about the fact that we had to found a new
project,
> > but it seems that it was the only alternative now. Of course we are
well
> > aware of the fact that both projects will become weaker this way, but
we
> > hope to be able to release the container including creation tools and
> > playback filters until January/February 2003, and then the users will
decide
> > what format they prefer.
>
> This announcement is not about ''letting the users
decide''.  You
> haven''t released or produced anything yet. This is the grown-up
> equivalent of declaring ''I didn''t get to do it my way, so
I''m taking
> my toys home with me'' and watching to see which kids in the crowd
are
> going to follow you home.  We''re on the way to having every
dissident
> hacker pushing his own incompatable container format, most based on
> someone else''s container format.  OK, sure, whatever.
>
> "Step one: Achieve something. Step two: toot horn"
>
> If you were really interested only in doing something different or
> trying out something new, you''d just have gone off and done it,
and
> let the world know if it did/didn''t work out. We already went
through
> all this a year or two ago when you all declared the beginning of MCF
> and sent mail to the Ogg lists that it would be better than our
> project in every way and we should abandon Ogg and use MCF.  It was
> quite the initial introduction and left a lasting impression.  So,
> I''ll repeat a previous flame that the original MCF folks never
really
> rebutted (just seemed to ignore).
>
> Quite a few MCF proponents keep touting things that Ogg can''t
> do... except they''re wrong.  For example, somone told with great
> confidence on HA that he was going with MCF because there was no way
> to figure out what codecs Ogg used and that each mixed stream type was
> hardwired.  That would really suck if it were true.  It isn''t.
>
> Looking at it from a high level, Ogg (the software) is full of feature
> hooks for which no one has written the code yet.  But it''s
apparently
> easier to start from scratch (again), effectively abandoning a half
> completed system that''s already running, solid, and deployed
> worldwide, and then use my own lists to pull people out of the project
> that works and has forward momentum.  A second time.  It''s in poor
> taste all over again.
>
> </flame>
>
> Personally, my position is that XML (binary or no) belongs in a stream
> or at a higher non-linear level-- not defining the lowest level
> transport attributes.  The correct way to build a large system is not
> to smash every conceivable feature into a single monolithic API layer.
> Build small pieces that work together.
>
> We here at Xiph started with:
>
> 1) a nice, robust linear transport layer that''s optimized
specifically
> and only for linear transport, ie, ''does one thing very well and
can
> be used to build larger things''
>
> 2) filters, aka OggFile, the first ''larger thing'', now in
progress
> along with resource usage optimizations (eg, zero-copy).
>
> We''re going to get that right before building a huge feature-rich
> system on a foundation that''s unproven / doesn''t exist.
>
> In summary, I''d prefer you let the people here who have
demonstrated
> they''re capable of working together without forking continue to do
so
> without this ongoing pseudotechnical distraction.
>
> (And if you want to do something productive with XML, how about
> contribute to the metaheader or XML page stream type in Ogg?  Hmmm?)
>
> I''m not on most of the lists in the cc: line.  If you want to make
> sure I read your flames before ignoring them, please make sure I''m
> copied.
>
> Monty
>
>
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to
''theora-dev-request@xiph.org''
> containing only the word ''unsubscribe'' in the body.  No
subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
''theora-dev-request@xiph.org''
containing only the word ''unsubscribe'' in the body.  No
subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Please allow me to announce the creation of a new open source Media
Container Format, named 'matroska'

Project page is here http://sf.net/projects/matroska ; homepage is
http://matroska.sourceforge.net , HTML should be online soon.

Steve 'robux4' LHomme and myself have left the MCF project because of
incompatibilities of our work with the project goals defined by the founder
of MCF ( TMF ), Lasse 'Tronic' Karkainen, especially with respect to the
latest specs Steve had been writing and documenting here
http://matroska.sourceforge.net/specs/ ( replace libmcf with libmatroska,
will be updated soon ) .

Tronic himself could not be actively participating on the project lately,
due to the fact that his courses at university didnt leave him much time to
do so. Steve and myself have been developing the project further, and now we
find ourselves in the situation that the result of this work does not comply
with the goals the original project leader was defining for it. As a
consequence we decided to leave MCF and found our own project.

matroska will of course be based on MCF, but the EBML based specs that were
developed together with Frank Klemm ( main MPC developer ) make the format
very extensible on the one hand, but harder to parse on the other hand.
Steve and myself do believe that easiness of parsing is a minor thing today,
with respect to the fast development of modern CPUs, but extensability has
proven to be a steady issue for container formats, as nobody can predict
what future requirements may be.

EBML, being a kind of binary equivalent to XML, can be supported on all
platforms easily and we hope that by using it we can differentiate our
project from other known containers significantly.

I am personally not happy about the fact that we had to found a new project,
but it seems that it was the only alternative now. Of course we are well
aware of the fact that both projects will become weaker this way, but we
hope to be able to release the container including creation tools and
playback filters until January/February 2003, and then the users will decide
what format they prefer.

About the project name : we needed one quickly and amongst the numerous
trials to find a 'friendly name' for MCF matroska seemd to be the best
one.
As it was Frank's idea and we knew he wouldnt mind we went for it, but
please be aware we will listen closely to your considerations in this
respect, as nothing has to be made in concrete yet.

Thanks for your interest


ChristianHJW
matroska project administrator

Monty wrote:
> On Sat, Dec 07, 2002 at 10:29:29PM +0100, ChristianHJW wrote:
>
> >Please allow me to announce the creation of a new open source Media
> >Container Format, named 'matroska'
> >
> >Project page is here http://sf.net/projects/matroska ; homepage is
> >http://matroska.sourceforge.net , HTML should be online soon.
>
> Another redundant project?
Well, if you think anything new with just a few variations is redundant, 
then it surely is. As OGG and Vorbis are too and a thousand other 
projects I won't name here (vi vs pico vs emacs, etc).
> "ten BSD programmers are sealed in a computer lab for a month.  At the
> end of the month, the door is opened.  Investigators discover,
> bloodied and dead, all ten programmers--- and thirteen new flavors of
> BSD."
Yeah, it's sad but true (that this could exist).
> >I am personally not happy about the fact that we had to found a new 
> project,
> >but it seems that it was the only alternative now. Of course we are
well
> >aware of the fact that both projects will become weaker this way, but
we
> >hope to be able to release the container including creation tools and
> >playback filters until January/February 2003, and then the users will 
> decide
> >what format they prefer.
>
>
> This announcement is not about 'letting the users decide'.  You
It wasn't sent to users, but developpers. Users will decide later. But 
as some people heard of MCF, the same one would probably like to know 
about matroska. In a perfect world I would expect technical person to 
get a minimum interrest and if they find it interresting, dig more in 
the specs. But since it hardly happened with MCF, I doubt it will with 
matroska. Apparently people prefer to code, comment the code and later 
analyse what they did. We tried and keep on trying the reverse way :)

BTW, for the record, Matroska is a simplified version of matrioshka (or 
MATP?WKA in russian), the original name of the russian dolls. The idea 
comes from me and Frank Klemm gave us the name in russian. It just 
symbolises the fact that, like IFF formats, Matroska contains other 
Matroska elements.
> haven't released or produced anything yet. This is the grown-up
> equivalent of declaring 'I didn't get to do it my way, so I'm
taking
> my toys home with me' and watching to see which kids in the crowd are
> going to follow you home.  We're on the way to having every dissident
> hacker pushing his own incompatable container format, most based on
> someone else's container format.  OK, sure, whatever.
Well, this is not exactly what is happening. Tronic gave me full control 
of the MCF specs and that's exactly what I did. I tried to take the 
specs and add what we thought would be needed/good/possible features. 
And I ended up with Matroska which borrows a lot from MCF, but is very 
different in the "syntax". So basically it was meant to become MCF v1 
very soon, as the format is passing Round 1 soon (see spec for more 
details). But now Tronic is back and don't want MCF to become that 
format I worked on. And since I consider it fills all past missing gaps 
in the specs and is far superior in expandability, I don't want that 
format to die.

There is also a libmcf library already existing that I coded 90% a while 
back. And since MCF and Matroska are twins this code will be used for 
libmatroska, and I think we'll be able to parse/create Matroska files 
quite fast (we're only missing UCI then).
> "Step one: Achieve something. Step two: toot horn"
I strongly agree with this. But Christian's announcement wasn't to 
announce that the format is final and the code is existing (AFAIK 
neither OGG nor Vrobis are final), just that it has been created. He 
didn't even tell the most important : it is already far closer to be 
final and a working code is not far neither. So this is no vaporware (as 
MCF tended to be perceived like).
> If you were really interested only in doing something different or
> trying out something new, you'd just have gone off and done it, and
> let the world know if it did/didn't work out. We already went through
> all this a year or two ago when you all declared the beginning of MCF
> and sent mail to the Ogg lists that it would be better than our
> project in every way and we should abandon Ogg and use MCF.  It was
> quite the initial introduction and left a lasting impression.  So,
> I'll repeat a previous flame that the original MCF folks never really
> rebutted (just seemed to ignore).
Yes, I know it sounded like vaporware. But in the mean time a lot of 
work has been done, lots of people contacted, only few reactions, even 
fewer help. And the result of all this (unknown) work from the 2 most 
active person in the MCF team is now turning into a new project.
> Quite a few MCF proponents keep touting things that Ogg can't
> do... except they're wrong.  For example, somone told with great
> confidence on HA that he was going with MCF because there was no way
> to figure out what codecs Ogg used and that each mixed stream type was
> hardwired.  That would really suck if it were true.  It isn't.
I don't want to start a long falme war (we all have better things to 
do), so I won't reply here. If you want my point of view, just email me 
in private.
> Looking at it from a high level, Ogg (the software) is full of feature
> hooks for which no one has written the code yet.  But it's apparently
> easier to start from scratch (again), effectively abandoning a half
> completed system that's already running, solid, and deployed
> worldwide, and then use my own lists to pull people out of the project
> that works and has forward momentum.  A second time.  It's in poor
> taste all over again.
We never said OGG should be abandoned. We just hope MCF-now-Matroska 
will fill all the needed use for a multimedia container, so that 
probably (hopefully) covers all that OGG can do. It might sound 
pretentious but all this year I've been working hard (not alone and I've
learned a lot from other people) on just a container. Something 
versatile and build to last long (even though we can't predict the future).
> Personally, my position is that XML (binary or no) belongs in a stream
> or at a higher non-linear level-- not defining the lowest level
> transport attributes.  The correct way to build a large system is not
> to smash every conceivable feature into a single monolithic API layer.
> Build small pieces that work together. 
Well, yes that's a difference in our point of view. I don't know OGG 
very well, but it seems that you went a level too low in the format 
(AFAIK all is based on small packets of data). This is actually only 
usefull on a limited number of transport layers like streaming (I've had 
a look at the draft RFC for OGG in RTP). For most of the time it's 
overkill. So we avoid that part. For streaming, we have already thought 
about it (to make sure the format could fit in) with Frank Klemm. And 
he's actually been working a lot lately on the way it should be 
technically done and what ECC would be needed for reliable transport 
(even over UDP). So even this possibility is not left out of what we 
want to do/cover.
>
> We here at Xiph started with:
>
> 1) a nice, robust linear transport layer that's optimized specifically
> and only for linear transport, ie, 'does one thing very well and can
> be used to build larger things'
>
> 2) filters, aka OggFile, the first 'larger thing', now in progress
> along with resource usage optimizations (eg, zero-copy).
>
> We're going to get that right before building a huge feature-rich
> system on a foundation that's unproven / doesn't exist.
Well, that's one way of doing. We try to think in advance, from very low 
level, coding to high level and interfacing with the rest of the 
world/OSes. And then code. Sadly we don't have the coding resources or 
support Xiph has (been building) so our solution seem to be appropriate 
to what we do. We can't afford to code 10 different non working 
versions, but we already coded 2 minimal parsers for MCF and it's 
working well.
> In summary, I'd prefer you let the people here who have demonstrated
> they're capable of working together without forking continue to do so
> without this ongoing pseudotechnical distraction.
I didn't see anything in Christian's message that would let you think we
want to distract people. And nothing against OGG (which I assume you're 
talking about). So I would be glad if you would not try to discourage 
anyone to get interrest in our project as much as we don't force anyone 
to leave OGG. I just hope you don't consider OGG as the one and only 
format. (this is the polite version)
> (And if you want to do something productive with XML, how about
> contribute to the metaheader or XML page stream type in Ogg?  Hmmm?)
Because so far, all the contacts I had with you and other people of the 
OGG/Vorbis was never friendly (this message is just one more example). 
This is a major reason for me. For example we leave the MCF project in 
good terms and I will still be a (small) part of it. Working "against"
people is something I want to avoid.