Project Announcement : New Media Container Format

[ChristianHJW]

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

[spyder]

I am switching projects as well.

I need a new avatar I guess......

[Acaila]

Chris,

I don't get it...

For a long time it's been "MCF this", "MCF that" and now all of a sudden you're leaving the project? I know it's probably not all of a sudden, but it does seem like that from my perspective. Of course I understand that people don't like having their work gone to waste, but MCF was going to be THE new format and you've all put a lot of work into it already.

Ogg doesn't seem to be moving forward a lot lately (at least I haven't heard of anything new in a long time), and so I (and I'm sure a lot of others as well) were really looking forward to seeing MCF becoming a reality. But now, as I understand it, some of the best people on the project are leaving for greener pastures. :(

Although I'm sorry to hear you leaving MCF, I still wish all of you good luck on the new project.

Ps.
What does 'matroska' mean and what language is it?

[spyder]

Matroska is Russian. It's a name for a toy doll that has another inside and another inside of that one and so on...

It has been deceloping for a while now. Steve had bigger plans for MCF than Tronic but when Tronic left the project, Steve was in charge. We developed the new specs and changed a few things in the format that should be changed to make the format more flexible. As a result of this, we adopted the EBML form of coding element IDs and sizes. Tronic strongly disagrees with this choice. He came back from his time away and refused to accept the EBML specs as the new spec but never voiced that until recently. He just put it aside in his mind as a side project. Steve didn't want to argue about it and refused to give up all of this great work he did on the new format. So Matroska was formed. The main benefits of Matroska over MCF are:

-Highly flexible structure
-Easily extendable
-Broadcast and file modes merged
-Unlimited frame sizes
-Infinite number of element styles
-Easily backwards compatible with new specs
-reduced overhead for smaller frame sizes(7,14,21,28-56 bit or higher sizes may be used)

The disadvantages as Tronic sees them:

-No fixed positions of elements
-File must be completely rewritten for small changes in the headers
-Complex to parse

Both formats have their advantages. But Tronic's is limited while Matroska is not. I will code an MCF parser one day when the spec is ready. I have joined Matroska as an active member however as I believe it has great capability and needs input on the structure. I have agreed to advise on MCF specs if Tronic needs help. Tronic wants his format the way he wants it though so I will not be an active member because of that. He doesn't accept the work Steve put into making the format great.

[KAMiKAZOW]

IIRC, the MCF project started because the OGG container is not specified/good enough. Correct me if I'm wrong.

Why don't you work with Xiph.org on improving the OGG container? :confused:

[ChristianHJW]

Originally posted by KAMiKAZOW
Why don't you work with Xiph.org on improving the OGG container? :confused:

Because Ogg container is fixed as is, the only thing you can do to improve it is to decide HOW EXACTLY to put your data in it, thats it. You cant have anthing changed on the container itself, without breaking compatibility with existing Ogg ( audio ) parsers ....

[JohnMK]

Best of luck.

[Teegedeck]

Good luck - and: sorry to hear that at the same time. :(

[KAMiKAZOW]

Originally posted by ChristianHJW
Because Ogg container is fixed as is, the only thing you can do to improve it is to decide HOW EXACTLY to put your data in it, thats it. You cant have anthing changed on the container itself, without breaking compatibility with existing Ogg ( audio ) parsers ....
Ah, OK.

Another question: Which license(s) will you use?
Will you use the combo of 'Specification license' and License for the libraries as MCF (LGPL). I ask, because the SF project page says " License: GNU General Public License (GPL), Qt Public License (QPL)".

[Lazy_Ranma]

Originally posted by spyder
Matroska is Russian. It's a name for a toy doll that has another inside and another inside of that one and so on...

"Matreshka" is the right word. "Matroska" means "sailor's jacket".

[sillKotscha]

Originally posted by Lazy_Ranma
"Matreshka" is the right word.

isn't it "Matryoshka" ;)

and about the nMCF... I think Acaila used to say the right words

'sorry' for you Chris or even good luck with your new project!!

[Atamido]

Originally posted by Lazy_Ranma
"Matreshka" is the right word. "Matroska" means "sailor's jacket".

"Matroshka" is the Germanized version of the Russian word. "Matroska" is the simplified, Germanized, version of the Russian name.

It really is a bad name. The whole reason they are using it is that they wanted to come up with a user friendly way to say "MCF". And because of this it had to start with an "M". There honestly weren't any good suggestions.

But, since they are branching to a different project, they need to come up with a user friendly name, and then create a a three letter acronym for it. If anyone has any ideas for a good name, please suggest them. Also, look to see if an appropriate file extension is available here. (http://filext.com/index.htm)

[MfA]

Originally posted by ChristianHJW
Because Ogg container is fixed as is, the only thing you can do to improve it is to decide HOW EXACTLY to put your data in it, thats it.

What is wrong with that?

There is no reason to insist the container format should allow you to put new datafields in the page header ... put that stuff in a seperate stream. Ogg's "inflexibility" presents no problems which cant be solved in an efficient manner, as long as you are not too inflexible in the ways you choose to solve them.

For instance, you can use a meta data stream for an application specific translation of whatever indexing/time-keeping method you want to use to granulepos+packetno in the data stream. Use skip pointers in the meta data for faster seeking if you want. Etc etc.

[sillKotscha]

Originally posted by Pamel
If anyone has any ideas for a good name, please suggest them.

I don't know if it's any good but what about

- *.omp = OpenMediaPack
- *.omf = OpenMediaFormat
- *.omc = OpenMediaContainer

or

- *.ocb = OpenContainerBackbone

and of course OCB as another container for another content... :D ' insane in the membrane'

[DSPguru]

Originally posted by KAMiKAZOW
Why don't you work with Xiph.org on improving the OGG container? :confused: http://www.xiph.org/archives/advocacy/0455.html

[MfA]

He might be abrasive but that doesnt mean he isnt right.

It was poor form to send it to the Ogg lists anyway. They are in the process of standardizing storage of I/P/B-framed and timestamped video in Ogg ... sending it to theora-dev (where that is happening at the moment) was a questionable decision, sending it to the ogg advocacy list of all places was wrong.

[ChristianHJW]

Originally posted by MfA He might be abrasive but that doesnt mean he isnt right.

You obviously forgot to paste the URL of Steve's reply to Monty, and his reply back, so i do it for you :

http://article.gmane.org/gmane.comp.video.uci.devel/224
http://article.gmane.org/gmane.comp.video.uci.devel/225

It was poor form to send it to the Ogg lists anyway. They are in the process of standardizing storage of I/P/B-framed and timestamped video in Ogg ... sending it to theora-dev (where that is happening at the moment) was a questionable decision, sending it to the ogg advocacy list of all places was wrong.

MfA, i respect you very much as a person and a valuable contributor to XviD, but you're making a very big mistake here IMHO. Your proposing something thats simply not existing, that is a form of 'competition' between Ogg Theora and MCF/matroska.
It is maybe worthwhile mentioning in this respect that on the very same day when Steve and me decided to leave the MCF team i had a very friendly conversation with Emmett Plant, the CEO of xiph.org, on IRC about the whole situation. Emmett offered to help us, and i know he ment that when he said it.

Both, matroska and MCF, have a completely different focus than Ogg Theora ( of course, this is not valid for OGM, which is not supported by xiph.org ). Ogg Theora is focussed on Vorbis and Theora, and unless i am completely wrong here the Xiph people will never aim to put MP3, XviD or AC3 into Ogg. They want to be able to offer a framework around their codes, being based onOgg, thats it. On the other side, Vorbis and its outstanding quality was the main reason for the founding of MCF, as we couldnt use it in AVI without introducing big hacks, so its also responsible for the existence of matroska that way.

Both codecs, Vorbis and Theora, will be very important for matroska, so we would be fools to piss xiph.org people. Please, dont see problems here that are not existing.

[robUx4]

Originally posted by Pamel
"Matroshka" is the Germanized version of the Russian word. "Matroska" is the simplified, Germanized, version of the Russian name.

It really is a bad name. The whole reason they are using it is that they wanted to come up with a user friendly way to say "MCF". And because of this it had to start with an "M". There honestly weren't any good suggestions.

Well, that's not how we got to this name. Given the way Matroska is architecture I thought the russian dolls would be a good symbol for the format. And so I asked around for the name in russian. And it ended up like MATPËWKA (that's what Frank Klemm said) and the german name is Matrioschka or something like that. Since some people thought that the russian name and the german name would be too hard for Joe Average, we came up with a more simple one. Which actually is our creation, like the format :)

[MfA]

I didnt posted the original link, and he took back nothing of what he said so from my point of view hist last reply was irrelevant.

With only one small exception, streaming, Ogg's purpose is an exact subset of MCF/Matroska. The overhead introduced by it supporting streaming is negligible, since there is a large overlap in the requirements for multiplexing.

As a whole you arent competing with Ogg, but Ogg was competing to be part of your standard ... and it lost out. Personally I find focus a poor reason for that, I never believed focus was the reason why there are so many BSDs either. Their focus presents no problem for Ogm, Ogm doesn't need Xiph's support ... it only needed Ogg.

[JohnMK]

Is there any hope for compromise, a soothing of passions, and eventual re-joining of MCF & Matroska? It really would be grand if both sides could do this. We'd all benefit naturally.

[spyder]

JohnMK:

The problem here is that the creator of MCF, Tronic, does not like the ideas behind Matroska. That makes it very difficult for the two sides to work together. I like MCF's structure. Hell I spent hours on hours coding for it. But it does not easily support streaming or linear writes. Also, small changes to the structure easily break compatibility. These are the reasons I like Matroska. I am not saying MCF is bad, it's just not suited for some uses. Tronic has made it clear that he does not want the complexity of Matroska. Matroska would lose all of it's flexibility if you took away the EBML. That's what makes it Matroska. I will code an MCF parser for Java one day if Tronic wants me too. But right now I am furthering the development of what I see as a great format. robUx4 and I work well together and we both listen to each other. I am not knocking Tronic for standing up for what he wants out of MCF. We just believe this format has too great of potential to abandon. I would love to rejoin the projects as I have worked for nearly a year with ALL of these people. But I just don't see this as being possible. At least not with Tronic's current goals.

Spyder

[robUx4]

Originally posted by JohnMK
Is there any hope for compromise, a soothing of passions, and eventual re-joining of MCF & Matroska? It really would be grand if both sides could do this. We'd all benefit naturally.

Actually Matroska is basically MCF. Tronic gave me full rights to change what was needed in the format to finish the spec. And I came up with Matroska. But just before we go to Round 2 of the process (start coding, initial freezing of the format) he comes back and say it's not MCF and will only be considered if the "old one" can't fit.

I think my work and all contributions made in the mean time deserve more than this, and I already came to the conclusion that MCF is bad when I changed it to something new/better.

MCF has a few advantages over Matroska and some major drawbacks. So if Tronic finally decides that the old one can't be used, Matroska=MCF. Otherwise Matroska=MCF++.

[JohnMK]

Well I hope he reads this forum . . . I would really like to see people leave pride and vanity somewhere else, and work together. I still think it can be done if you're careful not to let passions interfere.

[ChristianHJW]

JohnMK,

yes, there is a very small chance of the 2 projects reunifying, but its a very hypothetical thing to happen IMHO and maybe only possible if one of the 2 projects would come to a halt somehow and the remaining developers decided to join the other team.

Our first priorities are now to

- get the specs completely finished and documented ( DocBook ), so we can publish and spread them ( 95% done ; ETA : December 2002 )

- Update Steve's C++ code from libmcf so that we have a working libmatroska ( 5% done ; ETA : January 2003 )

- test first files, created with spyder's matroska implementation on Java ( 60% done ; ETA : January 2003 )

- motivate Suiryc to adapt VirtualdubMod_MCF to statically or dynamically link to libmatroska ( 80% done, API is basically the same for both ; ETA : January 2003 )

- find somebody to help myFUN/kromyx to get the DShow filter working for video, and for more than one stream/track to allow switching ( ETA : ? ; until then only spyder's 'javatroska' ( ;)) could be used to watch the movies )

- x-check files created with spyder's Java implementation with VirtualdubMod, and vice versa


As for me, contributing to matroska will look completely different than what i did for MCF, now that we have a fully motivated team and a clear timeline. Its becoming obvious that people are starting to get annoyed by the constant announcements without the chance to get their hands onto something working.

I promise now that this post here is my last post about matroska until we can start public alpha testing, unless somebody will flame the project here and i feel i have to defend it, that is. I guess nobody will mind me doing so ;) ...

BTW : mailing lists will be up tomorrow, namely

matroska-devel@freelists.org
matroska-general@freelists.org

( subscribe here : http://www.freelists.org/signup.html )

matroska-cvs@lists.sf.net

( subscribe here : http://sourceforge.net/mail/?group_id=68739 )

Gmane NNTP interface will be

news://news.gmane.org

gmane.comp.multimedia.matroska.devel
gmane.comp.multimedia.matroska.general
gmane.comp.multimedia.matroska.cvs ( read only )

[temporance]

IMHO you've made am excellent decision opting for an extensible format. Fixed field sizes and fixed field offsets were features of file formats of the 1980's, and we're now in 2002!

However, why don't you build upon the ISO / mp4 file format? This is now a family of file formats and is extensible with UUID atoms. It will be supported by hardware DivX players. IANAL, and AFAIK, there are no patents covering the mp4 file format. And the specs are online somewhere.

The only problem with mp4 are that:
* When capturing to an mp4 file, the already-captured part of the file is not playable until the file is closed (and MovieAtom written). [there could be ways around this]

Btw, what is EBML? I can't find a spec anywhere.

Cheers.

[BlackSun]

EBML is the binary version of XML

[robUx4]

Originally posted by temporance
The only problem with mp4 are that:
* When capturing to an mp4 file, the already-captured part of the file is not playable until the file is closed (and MovieAtom written). [there could be ways around this

At least we don't have such problems. Also we support some kind of UUID but with varying sizes. If the specs are readable somewhere (and easy to read for a human being) I will. It's good to know if we are better/worse and what we could borrow to make Matroska even better :)

[robUx4]

Originally posted by BlackSun
EBML is the binary version of XML

Yes, but it's not something official, like XML. We just invented it because we borrow some ideas of XML :

tag information, so that we can skip unknown informations
variable size of all elements
differentiate the data syntax and the semantic (known by the code, not the file), like an XML file and the related DTD/Schema


Eveywhere where XML is used, it could be turned into EBML. And the opposite is true too. So in the future you might be able to write all the informations about a Matroska file in XML and then use an XSLT processor and transform it into a "mastered" Matroska file ! All this without a single line of code (only a "standard" XLST stylesheet).

[rjamorim]

Originally posted by temporance
IANAL, and AFAIK, there are no patents covering the mp4 file format.


http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,134,243.WKU.&OS=PN/6,134,243&RS=PN/6,134,243

Apple already stated that they are not interested in charging license fees from the usage of technologies included in that patent.

Of course, it's up to you to believe them or not.

And the specs are online somewhere.

http://developer.apple.com/techpubs/quicktime/qtdevdocs/QTFF/qtff-1.html

IIRC, MP4 specs are slightly different, but qtff is good start to understand how it works and what are it's capabilities.

Regards;

Roberto.

[robUx4]

Thanx for all these info.

I've had a look at the patent, and clearly the format is made to be mapped to a C structure. This is not the case in Matroska/EBML because there is no order of elements and the size of the same element can vary from 1 byte to an infinite number of bytes (theoretically). And we use the same variable size for all "Atom IDs" (to use the Quicktime terminology) too.

Hey, we're in 2002 ! ;)

[robUx4]

...Which leads me to another reflection. If any company want to make smething similar to EBML, it won't be "patentable" ! Because there is a prior art : Matroska :)

I just hope noone already did something similar. But I doubt there would be patents on the EBML, because it's similar to UTF-8 coding which AFAIK has no patent (at least it's free to use it).

[Latexxx]

I hope that you won't keep matroshka as the final name for the format. Imagine when h4x0rs start to use it: ThE_rEaLly_CoOl_mOVie-xvid-570-320-no-shit-non-cam-version.2002.matroshka Matroshka is a great name, but it is too long. I would suggest that you would select something like .mc2 to the end of the file name. Mc2 come from something like mcf^2 because matroshka is based on mcf and it is better version. Mc2 also refers to Einstein famous e=mc^2 thing(don't know what to call it in english).

[robUx4]

Matroska is the name human beings should use to refer to the format. For the file extension you're talking about, we have (nearly) decided to use .kas for matroska files containing Sound only, and .kav containing at least Video. Later extensions will be created when required.

[bond]

uhh that sounds too russian...

Why dont you use mc2 or omp, omf or omc...

kas is a slang word in german for cheese -> if something is shit you can say that it is "a kas"! :D

[Atamido]

MC2..... I like it. And the whole E=MC2, thats pure genius. Also, the reference to MCF version 2 is nice. Except it could be the Matroska Container Format version 2. Nobody ever wants to go with the version 1.0 of something, so we could start off with the 2.0 version. ;)

The only issue is that it doesn't differenciate between audio and video in the extension. Unless of course you did MC2 and MC3.

I can think of some pretty cool banners containing something along the lines of "E=mc2, A=mc3, V=mc4... Matroska, it just makes sense"

Does that sound cool to anyone else? (the A is for audio, and the V is for video. Kinda plays off of the mp3 and mp4 phenomenon too.)

[robUx4]

Yeah, that will just lead to confusion with MCF (no competition, please) and the MPEG files. Also for the version number, I hope there will never be a need for Matroska version 2 ! That's why it's designed with all possibilities in mind.

[Atamido]

Originally posted by robUx4
Also for the version number, I hope there will never be a need for Matroska version 2 ! That's why it's designed with all possibilities in mind. I know, I just really liked the e=mc2 bit.

[Latexxx]

Choose what ever name you want as long it is easy to remember.

BTW. What does kas / kav refer to?

[robUx4]

Hopefully nothing, but most people will know how to pronounce it :)
It can be taken as matrosKA Sound or matrosKA Video... But it doesn't really matter.

[Ookami]

I think the most appropriate name would be "Mmmm, let's wonder how long this will last before some politics ruin it".

Or "M" or "Most valuabled container format" or "Most advertised container format" or...

Even here we have a thread http://www.hydrogenaudio.org/index.php?act=ST&f=2&t=4746 .

Anyone who keeps track of all "whatever the new name and project is" threads? ;)

Cheers,

Mijo.

[robUx4]

He he.
Hopefully we don't just talk. We work too.
And apparently the most advertised format is not getting more help anyway... :sly:

[ChristianHJW]

Originally posted by Ookami Anyone who keeps track of all "whatever the new name and project is" threads? ;)

me .. :P

Hey Ookami, a bit more enthusiasm about the future of video encoding please.

The split was not planned, believe me. But i swear it was the best thing we could do actually. Please, be a little bit more patient and we wont disappoint you mate, i promise.

Christian

[Ookami]

Hello Christian...

I am enthusiastic. Remember, I inserted the link to TMF in my programmers corner before you or anyone else from the scene was in it...

Because I believe we need a new container format...

I'm just disappointed with the current events.

I wish you all the luck and fun. You and your team have my moral support (I know it's not much worth, but still...)!

Cheers,

Mijo.

[robUx4]

He he. Thanx for the support.

And don't worry, the wait for a new container has been long. But it won't be long now until people can use it. And I hope (think) that it was worth the wait.

As a side not, there is also a need for a codec architecture (UCI is supposed to fill that gap) and a Menu system (that should be integrated in other containers too), AFAIK there is no menu system existing. I mean something like advanced stuff like on DVD menu (hotspots, variable settings, etc).

[ChristianHJW]

Originally posted by Ookami
[B]Hello Christian...
I am enthusiastic. Remember, I inserted the link to TMF in my programmers corner before you or anyone else from the scene was in it...
Because I believe we need a new container format...

Really, i had no idea ! It as Ingo Ralf Blum pointing us to TMF, i wouldnt know you found it before he did. A good proff you know whats going on ;) ...


I'm just disappointed with the current events.

So are we :( ... really, if anybody believes it was easy for me to abandon my beloved child, you are wrong. But sometimes its better to make a clear cut.

'Lieber ein Ende mit Schrecken als Schrecken ohne Ende ...'

( 'Better and end with terror than never ending terror..' )

I guess this German saying hits the point here.

I wish you all the luck and fun. You and your team have my moral support (I know it's not much worth, but still...)!

You're wrong, it is precious for us. Many believers in MCF are disapointed now and turn their back on us. Hopefully we will be able to convince them that only the name has changed, not the team behind it and by no means the mission ...

[OUTPinged_]

We dont turn our backs on you. Never. We do need alternative container format, and ogm seems not enough.

Good luck on 'matroska' container.

(Btw, 'matroska' is giving me laughs as to a person with russian lang. as primary. I will send you a photo of actual thing (a sailor tshirt, not some silly wooden toy) to use it as a banner, will be fun. As soon as i will find it hehe.)

[robUx4]

We know that the russian name is MAPTËWKA, which is pronounced Matrioshka, and we decided to simplify it for the lazy (USAns) people. You'll see that on our webpages we use the russian name too.

[^^-+I4004+-^^]

is this new container XCD,or MCF,or,or?
(yes,yes XCD is cd container...but still...)

i don't care much for the name of it ( matroška? some kind of
cookie , outpinged? hehe ) but if you keep splitting
( XCD from MCF,you guys from MCF....then poor MCF(?))
where does it lead to?
seems like no one agrees there and it's enogh for two people to disagree to found their own project....
i wonder if it's good idea.....

anyhow, anyone that comes up with something better than .avi will be
appreciated so don't mind me bitchin a bit on the splitting thing
and try to give us some tools for creating and watching "matroška's"
(it's š or sh in my lang.) soon

cheers_

ps. ohh and btw. "MAPTEWKA" can't be pronounced as "Matrioshka" as
"P" is "R" in cyrillic alphabet.....
but "Marteshka"......."Mapt" is "Mart" is "May"
( as "month" )
you made a typo there....

[ChristianHJW]

Originally posted by ^^-+I4004+-^^ and try to give us some tools for creating and watching "matroška's" (it's š or sh in my lang.) soon

Alpha testing has just started, but it seems our tools are still so buggy that we probably cant even call it 'alpha' but better 'pre-pre-alpha' ... lol .. :D

Actual Status :

- MP3 and MP2 audio alone works fine, when created with old mpa2mcf.exe ( originally made for MCF project )

- DivX3/4/5 video works ok, but picture is still flickering

- XviD doesnt work at all ( oh my, DivX decoder is trying to decode it in the playback graph, and we have no f..ing clue why )

- MP3 sound inserted by VdubMod together with video doesnt play in the Dshow parser, seems some blocks get incorrect time stamps

- no Vorbis still ( needs to be hardcoded in VdubMod and parser first )

- no MPEG2 video still ( Suiryc doesnt understand pulco-citrons MPEG2 parser code :P )

- no AC3 audio AFAIK

Sounds we still have a lot to do guys :D :D .. but we dont give up !!

[^^-+I4004+-^^]

>Sounds we still have a lot to do guys .. but we dont give up !!

piece of cake,i'm sure.....

btw.i took a look at draft for standard,and i wonder why
am i not seeing any real support for interlaced
stuff
(like the support for proper playback,field order->which field comes first,etc.)
but perhaps it's still to early to discuss it(?)

though you have some interlaced flag
so obviously you have it in mind.......