A short update on MCF development

[ChristianHJW]

Hi,

i hope the mods here allow me to post a quick update of current MCF development status :

1. We have test files with
- PCM audio
- MP2 audio
- MP3 audio
- RGB uncompressed video
- YUV uncompressed video
- Xvid video
All test files are created based on the old version of libmcf ( in MCF CVS, see sf.net/projects/mcf ), so they are outdated already and will not be made public, only a small alpha test team has access to them. The reason we play with those is to test the tools we have, means

Spyder's JMF based muxer/parser
myFUN's Dshow based muxer/parser

The plan is to be able to bring the working tools quickly to MCF-1 final specs with an updated libmcf, once specs are finally freezed.

2. We have ongoing development ( same level as above ) to have MPC audio files in MCF, hopefully soon. For MPC we plan to have a win32 decoder in our Dshow MCF parser, as long as MPC has no UCI interface

3. It was finally decided to use UCI ( http://uci.sourceforge.net ) to interface codecs from libmcf ( encoder ) and MCF parsers ( decoder ). MCF will never use the old VfW API, unlike other new containers. Of course, there will be a way to transmux all or single streams from an AVI into MCF files, in a so called AVI compatibility mode ( similar to what OGM does now ). In this case a Dshow filter will be called for decoding, no UCI decoder ( normal AVI playback graph ).

4. robux4 is about to freeze the MCF-1 specs, we have a number of new people contributing to them ( mainly Alex 'Foogod' Stewart and Frank Klemm ), but mainly we have all important details discussed now. robux4 has transferred the old MCF specs into a DocBook format and will update the specs now to final MCF-1 status. We hope this will be finalized by end of this year. Updating libmcf to MCF-1 Beta status should happen shortly after that.

Our roadbook is here :

- Freeze and document MCF-1 specs
- update libmcf to MCF-1 Beta status
- update all existing tools to MCF-1 Beta status
- assist Foogod with UCI spec freezing, if possible
- implement libuci into libmcf and parsers
- add UCI interfaces to most used opensource codecs ( XviD, Vorbis, MPC, Lame, Theora, FLAC, HuffYuv, etc. )
- try to make general UCI --> VfW wrappers to be able to use all VfW codecs ( with limited possibilities )
- try to make general UCI --> ACM wrappers for audio codecs ( only CBR )
- try to make a UCI wrapper for DivX5 ( only possible with support by DivX N ; else we can may only use it via VfW wrapper )
- Add the possibility to call UCI codecs in a Vdub mod ( talked to Suiryc about that ; this mod could create MCF or OGM files )
- Create subs codecs with UCI interface for SSA, Vobsub, etc.
- Develop MCF authoring tools for Menue and chapter creation, etc.
......

Dont ask me when we will be able to release first files. With the limited coding power we have now ( 4 developers only ) this will take us at least 6 - 8 months. First MCF-1 spec compliant files can maybe be created in about 3 - 4 months from now, we'll see.

Please forgive me my long posting, i hope you dont mind.

ChristianHJW

[Nic]

Long time no see, Mr. Wiesner ;)

Glad things are progressing...

-Nic

[robUx4]

Originally posted by ChristianHJW
3. It was finally decided to use UCI ( http://uci.sourceforge.net ) to interface codecs from libmcf ( encoder ) and MCF parsers ( decoder ). MCF will never use the old VfW API, unlike other new containers. Of course, there will be a way to transmux all or single streams from an AVI into MCF files, in a so called AVI compatibility mode ( similar to what OGM does now ). In this case a Dshow filter will be called for decoding, no UCI decoder ( normal AVI playback graph ).

Well, actually that's not the way it should be done. The right way is to use a UCI codec which is an DShow wrapper. So it's still a UCI codec that can use any DShow decoder.

[goweropolis]

Originally posted by ChristianHJW
2. We have ongoing development ( same level as above ) to have MPC audio files in MCF, hopefully soon. For MPC we plan to have a win32 decoder in our Dshow MCF parser, as long as MPC has no UCI interface
This is great news. I recently switched to MPC from MP3 as my choice for archiving high quality music in a lossy format. I was very impressed by three things:

1. sound quality as good or better than MP3
2. smaller filesizes than MP3
3. encoder & decoder is way faster than MP3

I don't think I'd use MPC for many movie DVD rips, but I would definitely use it for any music DVDs to preserve the best sound quality possible.

Looking forward to trying your great program.

[Acaila]

It's great indeed that MPC has made it into the specs. I always use it to backup my audio CD's as well as it's IMHO the very best audio codec out there for pure music.

Good to hear you are making such progress Chris, but it seems like there is still a long way to go unfortunately.

[ChristianHJW]

Hi Acaila,

thanks for the motivating words, we need them.

As in respect to MPC, its not correct to say that it 'had made its way into the MCF specs' . Actually, every codec with a UCI interface will be supported by MCF, unlike other containers where video has to be VfW and audio is more or less hardcoded in the muxer/demuxer/parser .

Its important to understand that MCF in conjunction with UCI is capable of replacing the complete VfW framework, not only AVI as a container.

To be able to support MPC quicker than other codecs ( as long as UCI isnt ready ) we are using the same solution as OGM with Vorbis though, means there will be a muxer/converter to create MCF files with MPC content and we include the MPC decoder into the MCF parser. Note that this is just a temporary solution, but the files created this way will be fully valid MCF files, once they are created on the basis of the final MCF-1 spec compliant libmcf. Later we of course plan to call the MPC decoder via UCI again, so we can remove the decoder from the MCF parser.

It is possible that we will have such a 'interims' way of MCF file creation for XviD, Vorbis and MPC earlier to be able to convince people about using MCF. But Steve ( robux4 ) doesnt like the idea, he is a perfectionist ;-) ...

[ChristianHJW]

Latest update :

MCF-1 specs will probably be freezed and documented before the end of this year !!

The latest ( pretty much half way finished ) draft of the MCF-1 specs can be seen here :

http://mcf.sf.net/EBMLed/

As you can see we are about to use EBML ( Extensible Binary Markup Language ), thanks to some great suggestions from Frank Klemm, the main developer of MPC audio codec ( musepack ), to the mcf-devel mailing list.

The main goal here is to be able to extend the format later without breaking backwards compatibility with old files/parser.

Comments should go to mcf-devel at lists dot sf dot net

[BlackSun]

I want to seek :p

[ChristianHJW]

Originally posted by BlackSun
I want to seek :p

LOL .... Sorry, Steve's old libmcf doesnt support seek entries as of yet, but i heard Suiryc has uploaded some changes to CVS recently, as he had probs with libmcf interfacing to VdubMod_MCF with respect to seeking .... maybe he himself can clarify ?

[Suiryc]

Seek entries are not yet handled in libmcf, but the changes I made didn't concerned this ;)
For the moment I build my own "Seek table" (done when parsing the file) but this is not a good solution for a player ;)

Blacksun : EBML specs for MCF have been updated recently and there is a part concerning Seeking entries (near the end IIRC)

[BlackSun]

Originally posted by Suiryc
Seek entries are not yet handled in libmcf, but the changes I made didn't concerned this ;)
For the moment I build my own "Seek table" (done when parsing the file) but this is not a good solution for a player ;)

Blacksun : EBML specs for MCF have been updated recently and there is a part concerning Seeking entries (near the end IIRC)

Nice :) I saw the EBML specs and I am surprised that there is only ONE field for aspect ratio. I may ask Chibi to come here if you want :)

A field for DAR, PAR and video size would be sweet, isn't it ?

[Chibi Jasmin]

There she is... :D Talking about DVD-resolutions for example, actually all you need is one value for PAR. But that way you wouldn't even come close to some of the 'normal' flags of 4:3 or 16:9...you could also take just one value for DAR, but even then 16:9 or 4:3 is close but not correct. So either you live with that or you can for example make a dar flag and set it to 16:9 and do the remaining corrections to get correctly resized video by PAR...

you all know the site, but just for reference:

http://www.uwasa.fi/~f76998/video/conversion/

I personally would think one field for ar is sufficient (if you ask me, I prefer it to be defined as PAR), if you have the possibility to add any PAR/DAR you like in terms of two integers, not just predefined 16:9 and stuff. Or you can have one flag to define whether aspect ratio means DAR or PAR...or you can have both PAR and DAR, that way you have to define in which order to process them...

In my experience it's easiest to deal with just one aspect ratio value: only PAR. I have played a lot with adding black borders to video and stuff and if you deal with DAR there, it's a lot of added calculations...

Hope this is not too complicated, I am a bit tired of this subject :-) I vote for one flag being defined as PAR and being able to take any two integers as input!

[BlackSun]

:D

[Chibi Jasmin]

:)

[BlackSun]

hey don't ignore us !!! :o

[robUx4]

I'm going to read all this thread and document and update the specs accordingly. As I'm not an expert in video in general, I will trust you more than myself :)

If you see other missing things or inaccurate in the current EBMLed specs, just say it !

[ChristianHJW]

Originally posted by BlackSun
hey don't ignore us !!! :o

http://article.gmane.org/gmane.comp.video.mcf.devel/650

Nobody would dare to ignore you Ludovic ;) .... i just felt like pasing the info to the dev team to find out their feelings about it ... and it sems that PAR is a part of the specs since about one year :D ..

[BlackSun]

My bad, I should read the ML more often :p

[Chibi Jasmin]

@Christian:

DAR = Display Aspect Ratio...

There are many better explanations for the PAR/DAR thing than the one you quoted by me...I am too busy at the moment to search them, but I have been talking about this a lot in the Beta forum of powerdivx and also sometime ago a bit on inmatrix forum, AFAIK even here...

Thank you developers, that PAR is part of the specs, I still think, that is all you need.

The main point is the same as the explanation for the ITU-Option of Gordian Knot (simply resizing to 16:9 dimensions is about 2.5% off...etc.), although, Gordian Knot's solution is also not fully correct, as TheWEF already knows btw.

But as this is not about how to resize DVDs correctly, but just about specs for a container format I think, the question is, what data do you need to reproduce an encoded video in the correct size/dimensions...isn't it?

You need:

1. width and height in pixels (video width * height )
2. Pixel aspect ratio (fraction of two integers (x/y))
->
DISPLAY width = video width (from point 1) * PAR
or
DISPLAY width = video width (from point 1) * x/y (from point 2)
DISPLAY height = video height (from point 1)

You can calculate the DAR out of this, so you don't need an additional setting for DAR in the specs:

DAR = DISPLAY width / DISPLAY height

For a better understanding of the difference I recommend http://www.iki.fi/znark/video/conversion/ (already mentioned above). You can also try to understand my following table :D It's about mpeg-resizing, but you can try to follow the calculations made...


Resizing of MPEG-sources compliant to ITU-R BT.601 standard

PAR=pixel aspect ratio – DAR=display aspect ratio

According to ITU-R BT.601:

PAL PAR 117/128 (y/x), x/y=1.094 [128/117] PAR
NTSC PAR 79/72 (y/x), x/y=0.911 [ 72/ 79] PAR

All correct resizing is based on 79/72 and 117/128.

anamorphic -> reduce height 3/4

DVD (D1=720) - PAL = 720x576 / NTSC = 720x480

PAL-anamorphic: 1.459:1 [512/351] PAR -> 1.823:1 [ 640/ 351] DAR (720x1.094 PAR=788, /432 (3/4 height) -> 1.823 DAR, 576x1.823=1050, /720=1.459 PAR)
PAL-nonanam.: 1.094:1 [128/117] PAR -> 1.368:1 [ 160/ 117] DAR (720x1.094 PAR=788, /576 -> 1.368 DAR)
NTSC-anam.: 1.215:1 [ 96/ 79] PAR -> 1.823:1 [ 144/ 79] DAR (720x0.911 PAR=656, /360 (3/4 height) -> 1.823 DAR, 480x1.823= 875, /720=1.215 PAR)
NTSC-nonanam.: 0.911:1 [ 72/ 79] PAR -> 1.367:1 [ 108/ 79] DAR (720x0.911 PAR=656, /480 -> 1.367 DAR)

SVCD (2/3 D1=480) - PAL = 480x576 / NTSC = 480x480

PAL-anamorphic: 2.188:1 [256/117] PAR -> 1.823:1 [ 640/ 351] DAR (1050x576 (2/3 D1=D1), 1050/480 (width)=2.188 PAR)
PAL-nonanam.: 1.641:1 [ 64/ 39] PAR -> 1.368:1 [ 160/ 117] DAR ( 788x576 (2/3 D1=D1), 788/480 (width)=1.641 PAR)
NTSC-anam.: 1.823:1 [144/ 79] PAR -> 1.823:1 [ 144/ 79] DAR ( 875x480 (2/3 D1=D1), 875/480 (width)=1.823 PAR)
NTSC-nonanam.: 1.367:1 [108/ 79] PAR -> 1.367:1 [ 108/ 79] DAR ( 656x480 (2/3 D1=D1), 656/480 (width)=1.367 PAR)

VCD - PAL = 352x288 / NTSC = 352x240

PAL: 1.094:1 [128/117] PAR -> 1.337:1 [1408/1053] DAR (352x1.094 PAR=385, /288=1.337:1 DAR)
NTSC: 0.911:1 [ 72/ 79] PAR -> 1.337:1 [ 528/ 395] DAR (352x0.911 PAR=321, /240=1.337:1 DAR)



Well, maybe you already know all of this, as long as you have a PAR flag in the specs, I am happy with it...I only hope people will set it correctly and not - for example - encode a 720x480 anamorphic ntsc-dvd (without resizing) and then put 16/9 into the par-field, because they don't understand... (correct was 96/79).

[pirata]

Please everybody have a look at this post of mine.

"
Well! Just had my first experience with OGM chapters. It hasn't been quite satisfactory, even though I can appreciate all the effort to put that feature together.

I normally use BSPlayers chaptering system. I miss some of its features in Tobias' OGM implementation. The following features are present in BSPlayer but not in OGM-chaptering:

-I'd like to have frame accurate chaptering. In OGM, you can only go up to seconds (not even tenths of second).

-when playing, going to a chapter means actually going to the keyframe nearest to the chapter's starting point in time. That happens with both players tested (BSlayer and Zoom Player).

-chaptering should be multi-CD aware: all chapters should be selectable at any point of the movie. If the selected chapter is out of the movie fragment currently played, the adequate CD should be played (or asked for). That is implemented in BSPlayer.

(OGM files generated with Cyrius VDubMod; BSPlayer and Zoom Player used for playback testing; the test file contained DivX videop lus one vorbis audio stream, and the file was cut in two halfes; chapters were introduced according to Tobias specs in the video stream comments)

Moreover, Zoom Player didn't manage good the chapters of the second half of the film. Next Chapter didn't Work (Only Previous chapter).

Any comment on this?

"

I don't know how MCF deals with chaptering, but I'd like to know if this features have been considerated.

Greetings.

[robUx4]

Hi pirata, could you have a look at the Matroska format (an evolution of MCF) and tell me if it would fit your needs ? I think it does :)

http://matroska.sf.net/specs/

edit: the chaptering span on various files (CDs) is possible, because we can link different segments (next / previous) and the timecode is continuous. Which is not possible in MCF.

[pirata]

I really had put hopes in MCF, and now I heard that the coding power has been divided by 2 again. With MCF we were talking about mounths before the format could be usable. Now we talk about more, maybe a year.

So the community has no completely reliable cross-format container.

OGM is fine, but still incomplete. I put ac3 in it and got lotta problems (I can only play movies with Zoom Player, which I really dislike, freezings are more than frequents...). Tobias does not release an improved version, so...

Well... There is nothing I or any other can do about it.

About specs:
I am no programmer, and the specs are too much for my limited comprehension power. Could you point me out exactly which cases to look at?

[ChristianHJW]

Originally posted by pirata I really had put hopes in MCF, and now I heard that the coding power has been divided by 2 again. With MCF we were talking about mounths before the format could be usable. Now we talk about more, maybe a year.

Says who ? 95% of the coding power ( i have no confirmation from myFUN/kromyx yet, but have high hopes he will join us also ) has moved to the new format, plus 50% of the specs creation/discussing ( Alex 'Foogod' Stewart made clear he will not contribute to matroska, and his input was admittedly precious ) and 100% of the forces making specs documentation ( means only robux4 :D ) .

The old MCF project team was going to be freezing MCF-1 specs by the end of this year before the split, now admittedly its hard to tell when Tronic will be able to find the time to define specs as he likes them and also to document them. As he admits he is not a good coder also he then has to find somebody to adapt these changes to libmcf ( although this shouldnt be too hard ), which was written in C++ .

As for matroska, the timeline is defined in another thread here. Depending on spyder's coding speed you will be able to create spec compliant matroska files ( means you can even consider them for archiving ) pretty soon, using JMF ( requires JRE ). Of course, it will take some time until all possible aspects of matroska will be available, but basic spec compliant files with XviD and Vorbis or MP3 could be on your HDD pretty soon, maybe even in 2002 ( go Spyder, go ;) ) ... VirtualdubMod and a working Dshow filter are the next steps, and robux4 is talking to Suiryc on an almost daily basis about how to make this possible, in #matroska on irc.freenode.net ....

So the community has no completely reliable cross-format container.
OGM is fine, but still incomplete. I put ac3 in it and got lotta problems (I can only play movies with Zoom Player, which I really dislike, freezings are more than frequents...). Tobias does not release an improved version, so...

Tobias is alone and very busy with his private Life. I still dont fully understand why he doesnt make his specs and filter sourcecode completely open, but we have to accept his decision.

Well... There is nothing I or any other can do about it.

Are you sure ? Its breaking my heart if i see excellent codec developers like Monty from xiph.org fiddling with mailservers, spam filters and the like, because obviously nobody of the 100+ folks idling in #vorbis has enough knowledge to do this for him, so he may concentrate on developing Theora or improve Vorbis ?

matroska team has a lot to do now, just look at the ugly homepage i fitted together very quickly, just to give some basic idea what we are.

Its not so difficult to contribute to an opensource project, and its wrong to assume you have to be a developer for this. For example, matroska needed a nice logo badly, as mf's MCF logo cant be used anymore. Steve had plans to make one, based on the russian dolls ... but shouldnt he concentrate on libmatroska instead ?


About specs: I am no programmer, and the specs are too much for my limited comprehension power. Could you point me out exactly which cases to look at?

Dont worry, i am working with these guys now for about 2 years, and they still dont understand why the specs are like Chinese letters for me :D .... coders always have problems to see things from the perspective of a simple user with no programming background, like i am.

Its probably sufficient to understand that matroska specs will allow to span a movie across multiple segments ( CDs ), with every segment pointing to the ( unfakeable ) ID nr. of the next and the previous segment ( nice feature for p2p :D ) . This ID nr. i calculated by making a MD5 of the block headers ( not the complete file ), so as long as nothing is really changed or edited in the file the ID will always be the same. The timecode of all the blocks in the movie is persistent across these segments, so of course the chaptering will be also.

[robUx4]

Hey Christian, you're getting very good at explaining the inners of the format !
:D

One addition maybe, you can merge different segments in a file. So a 4CD movie could be merged (just append the data into the final file) and be put on a DVD :) The same kind of thing you can do with MPEG.

[pirata]

@ ChristianHJW, robUx4:

Well, sorry everybody. I thought that the forking was 50-50%, not 1-99%.

Look: I amwilling to help in coding. I have programmed in ANSI C / C++ under Unix using the QT API for graphical applications (OpenGL, OpenInventor). Also during my study years (some superior engineering), I've dealt with ANSI C in some practical courses. However, I haven't ever dealt with "higher things" like codec programming in Windows. So: I aint't no profi coder, cannot code at lightspeed, but I do have 2 hands and a brain and can improve if you share your infinite knowledge and experience ( :-) ).

I am 2 mounths away of being definitely done with his studies. By that time I could consider joining you if you want me, because I feel it is going to be a real wide, lasting and useful standard, a good thing to be involved with if you want to contribute code to the community. I won't earn money, but much knowledge and fun.

I imagine you all are people coding for big software companies, getting always the best algorithm for each part of a program, so maybe I am being very naive to propose this. I'd like to hear you say "No experience? No problem! We help you do it.", but I guess it will go "You are lacking too much". It it goes so, please tell me some roadmap of skills I should consider elarning before offering my help next time. Just the most important stuff.

I look forward to your reply. Pirata

[robUx4]

Hey pirata, thanx for the offer !

AFAIK, none of us are working for big software companies nor do we have unlimited resources to work on the format. That's why MCF took so long ! We plan to be faster on Matroska because we have the MCF experience now, and that we can use existing code and update it (libmcf).

So whenever you want to join the team, we'll gladly accept you. There are many things that need to be done. libmatroska will be in beta for probably a long period. Because there are so many features in Matroska that it will still that some time to have all of them working. The priority is to have muxing of audio and video working. If you want to work on the Chapter feature or any other else, there will be plenty of room for you :)

The library is written in C++ and you can check out the code from the MCF CVS on SourceForge to try to understand the architecture (not very complicated).

[ChristianHJW]

pirata,

what could i add, i hope Steve could motivate you to join our small team and to dissolve some misunderstandings about the quality it needs to be able to contribute.

Dont forget to join us on irc.freenode.net #matroska , so we can talk in detail where you could contribute to the project ( Steve mentioned chapters, that was a good thing to look at indeed ) ...

[pirata]

As I said in my post, I am right now involved with the most delicate phase of my final project. I'll be done in 2 mounths (at least, if nothing terrible happens ~:-o ).

This last sentence is not meant to decline your offer, but to ask you for some time until I get my diplom and some spare time.

Give me some times, boys. I'll let you know when I am ready.

[ChristianHJW]

Originally posted by pirata Give me some times, boys. I'll let you know when I am ready.

Take your time ! We really appreciate your offer to help if everything is fine ... after all, this here is ment to be fun, not stress :-) ...

[spyder]

In the mean time, one of us coders should start writing out a detailed decription of the format in regular lanuage not coder speek. :)

I will try to do this though I will need some advice from robUx4 on some aspects. It should be a well formed document ready for public reading by tech people but not coders. It will take a while to complete though as I am still coding on my EBML parser and then will start on matroska parsers. I know, don't think "It'll take forever to finish." Christian can attest to my coding speed and I will have a working EBML implementation(useable outside of matroska) by the end of this week.

Spyder

PS: My new code is fully documented, ensured to work properly at each level and is not sloppy. It is taking longer than before because I even do the tedious Javadoc documentation. I will have the final EBML parser(not matroska parser) release ready for CVS by next week. Yes release. It will be thoroughly checked before continuing with Javatroska and made RELEASE level before continuing. I will maintain the EBML implementation as a seperate package. The entire Matroska parser should be fairly easy to code once the EBML stuff is in order. If any Java coders would like to help, I would really appreciate it. Even if it's just something simple like maintaining the documentation. :)

[robUx4]

Spyder, good idea for the specs.
The preferred format would probably be DocBook as we'll do that next (Round 3 I think). You can check the old MCF one. It's quite easy to learn when you know HTML.

[spyder]

And it's Java too...

[Milkman Dan]

Originally posted by robUx4
Spyder, good idea for the specs.
The preferred format would probably be DocBook as we'll do that next (Round 3 I think). You can check the old MCF one. It's quite easy to learn when you know HTML.

He means the documentation in his source, not documentation on the whole EBML thingy. The JavaDoc standard is a way to format the comments so that they can be automatically extracted and added in HTML to the normal Java Documentation.

[spyder]

Originally posted by Milkman Dan
He means the documentation in his source, not documentation on the whole EBML thingy. The JavaDoc standard is a way to format the comments so that they can be automatically extracted and added in HTML to the normal Java Documentation.

Actually, I was meaning a technical document describing the entire Matroska file format in non-coder terms, starting with the EBML part. :)

I believe it is necessary to make EBML a seperate piece from the rest. This way it's easily updateable. ;)

[robUx4]

Yeah, I'm understanding english better than Jan now ;)
Anyway, yeah it's a good idea.

One of the thing missing in EBML now is the equivalent of XML parameters. As you can see in Matroska we deal with levels and everything is a parameter or a sub-element (you choose which one).

For example the BlockAddition should be a parameter of the Block and not a separate element. Mmm... maybe it just means it should be one level down ;)