Monty
2002-Dec-07 15:10 UTC
[theora-dev] Re: [advocacy] 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.
AK Palmware
2002-Dec-07 15:36 UTC
[theora-dev] Re: [advocacy] Project Announcement : New Media Container Format ''matroska''
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 newproject,> > 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 willdecide> > 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.
ChristianHJW
2004-Sep-10 16:45 UTC
[Flac-dev] Project Announcement : New Media Container Format 'matroska'
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
Steve Lhomme
2004-Sep-10 16:45 UTC
[Flac-dev] Re: [advocacy] Project Announcement : New Media Container Format 'matroska'
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'. YouIt 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.
Reasonably Related Threads
- Re: [advocacy] Project Announcement : New Media Container Format 'matroska'
- Project Announcement : New Media Container Format 'matroska'
- Project Announcement : New Media Container Format 'matroska'
- Re: [advocacy] Project Announcement : New Media Container Format 'matroska'
- [Flac-dev] Re: [advocacy] Project Announcement : New Media Container Format 'matroska'