[Flac-dev] Re: [advocacy] Project Announcement : New Media Container Format 'matroska'

Monty xiphmont at xiph.org
Sat Dec 7 15:11:02 PST 2002



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






More information about the Flac-dev mailing list