Tobias has joined xiph.org

[tangent]

[23:30:30] <Emmett> People are gonna lose their fuckin' minds when they hear this one.
[23:31:11] <Snow> o_O
[23:31:29] <Emmett> Ready?
[23:31:33] <Aksu> sure
[23:31:46] <Emmett> Tobias Waldvogel
[23:31:52] <Emmett> Theora Project Scientist
[23:31:55] <Emmett> Xiph.Org Foundation
[23:32:14] <Emmett> There ya go.
[23:32:16] <jonI> oh, cool. he's the guy who wrote the Windows .ogg container code?
[23:32:22] <Emmett> the DS filters, yeah
[23:32:23] * Joins: Yog-Soth (~ysothoth@xiph-EALJ.csi.cuny.edu)
[23:32:28] <Yog-Soth> har
[23:32:36] <tuxisuau> sure?
[23:32:41] <Snow> wow
[23:33:02] <jonI> what's happening to the code he wrote?
[23:33:10] <tuxisuau> the ogm guy?
[23:33:16] <Emmett> It's going BSD-licensed and being put in Xiph CVS.
[23:33:32] <tuxisuau> and what about OGM?
[23:33:32] <volsung> Score!
[23:33:34] <jonI> great news.
[23:33:45] <Emmett> OGM is just a file extension.
[23:33:46] <tangent> whoa
[23:33:49] <tangent> finally!
[23:33:52] <tuxisuau> nice
[23:34:00] <tangent> WHAT THE FUCK TOOK YOU GUYS SO LONG?!?!?!
[23:34:00] <Emmett> Tobias will be coming on and working with us on Theora and on the toolchain of same.

[tangent]

W00T! Great things are coming!

[ChristianHJW]

Finally ! I cant help but agree with tangent, wtf took them so long to find each other :D !!

[kxy]

Does it mean that all the bugs that has being reported will be fixed sooner?

[bond]

...and what does this mean for the ogm-container directshow filters. Is there any further progress? (I cant wait for matroska :rolleyes: )

[ChristianHJW]

Emmett said the sources of Tobias' filter will be put into Xiph CVS and be released under a BSD style license ... so literally everybody can work on it now and submit his changes to Xiph ...

[Koepi]

So now OGM is Ogg ;)

Regards
Koepi

[Neo Neko]

Originally posted by ChristianHJW
Finally ! I cant help but agree with tangent, wtf took them so long to find each other :D !!

They knew eachother for a long time. IIRC the major hold-up was from Tobias's end. If I understood Blacksun correctly Tobias is a relatively new coder and kinda shy to boot. He did not want to release his code untill he was sure he had polished it good.(something about him thinking his code might be sloppy and embarrasing) So either he got it polished or Blacksun gave Tobias a good pep talk.

You have to admit. It could be a bit much going from an obscure nobody in Spain to a well known famous though somewhat reclusive figure on the encoding sceen. How would any of us react in his place. ;)

[BetaBoy]

Funny how this has all gone down. A few other people along with myself have different perspectives if and why Tobias might have joined XIPH. Some good some bad.

[09:18] <Emmett> Jesus Fucking Christ.
[09:18] <tuxisuau> It seems like they're insane
[09:18] <lev> I would also like to use flash. :P
[09:18] <Tessai> lol
[09:18] <Tessai> no flash for ppc?
[09:18] <Tessai> (:
[09:18] <Emmett> It is *so* fucking time to crack down on this OGM shit.
[09:18] <lev> No. Not in linux, that is.
[09:18] <Tessai> ):
[09:19] <tuxisuau> Emmett: It seems you liked the url, didn't you?
[09:19] * xercist has quit IRC (Client Exit: I like core dumps)
[09:19] <Emmett> That's insane.
[09:19] * tuxisuau is evil sometimes, too.
[09:19] <Emmett> We don't fucking support that, goddamnit!
[09:19] <Emmett> I'm tired of the fuckin' E-mail!
[09:19] <Emmett> God-Fucking-Dammit!
[09:19] <tuxisuau> Emmett: I've through the same when I did read that yesterday.
[09:19] * ChanServ sets mode: +o Emmett
[09:19] <Tessai> uh oh...
[09:20] * Tessai ducks
[09:20] * Emmett changes topic to 'Welcome to #vorbis on irc.xiph.org. No, we do not support OGM. Please look elsewhere.'
[09:20] * Emmett sets mode: -o Emmett
[09:20] <lev> WTF is OGM?
[09:20] <tuxisuau> lev: "OGM is the file format for multimedia developed by the Xiph.org Foundation. It is very similar to the common Microsoft AVI. The main difference between OGM and AVI is that the new format can store audio with the Ogg Vorbis codec."
[09:20] <lev> fonkmfoasl;
[09:20] <tuxisuau> lev: http://freshmeat.net/releases/108100/
[09:20] * lev looks at the buffer.
[09:20] * tuxisuau laughs
[09:20] <Emmett> of course, that URL lies.
[09:20] <tuxisuau> how can they be that mad to say that?
[09:21] <Emmett> We do not develop OGM.

Just wondering... oh btw... this log is 4 days old.

[spyder]

Well, I am glad that this conflict is over. At least now there is a better container than AVI available that will be standard. Of course Ogg still has issues as it is not really designed for such use. But hey, maybe I'm just too biased. :)

Anyway, the bottom line is that we will not cease development of Matroska because of this. We need a format designed from the ground up for these purposes not from the top back to the ground and up again. ;)

Anyway, why does everyone think Matroska is so far off? From our current position we don't have far to go before we can have working tools. I am not saying Ogg is bad or you shouldn't use it. I use it. But it is still lacking in some areas. Just don't get too carried away over it. :)

I don't mean for this post to come across as rude or degrading to Ogg. I just don't like how some people (not here) have decided that Matroska is a useless idea now that we have an official Ogg container to use.

[neo_sapien]

Originally posted by spyder
Anyway, why does everyone think Matroska is so far off? From our current position we don't have far to go before we can have working tools.

Because you've been saying that's it's close to being done since February 2002 or so, in its various names :p

Or at least that's what I've observed.

[spyder]

Yes well, that was before the realization that the old MCF had serious faults. Now these faults have been fixed and coding is already in prgress for the new libraries, both C++ and Java. With the codebase we already had, which had been proven to work as shown in our private DShow filters, we are only a few months away from a release.

OK, that last part was rude...retracted.

[Atamido]

Originally posted by neo_sapien
Because you've been saying that's it's close to being done since February 2002 or so, in its various names :p Or at least that's what I've observed. It should be noted that a test MCF parser was built and integrated into VirtualDubMod for testing purposes. I could produce MCF files that I could then play back in WMP 6.4.

But, as Spyder pointed out, the format was changed to make it better. It should now be the most flexible container in existance. So, when we say that it will be out soon, it actually will.

But anyway. I think its great that Xiph has accepted Tobias onto their team, and taken the OGGDS into their CVS, instead of bringing legal action into the picture....

[BetaBoy]

But anyway. I think its great that Xiph has accepted Tobias onto their team, and taken the OGGDS into their CVS, instead of bringing legal action into the picture....

I would wait for official word or hear back from Tobias. But Pamel... do you truly think this is a good thing? It maybe for XIPH/Theora/OGG and Emmett but surely not in the big picture, not at all.

Legal action... I won't even touch that... but I could post a nice quote from IRC :devil:

[JohnMK]

Originally posted by BetaBoy
but I could post a nice quote from IRC :devil:

What is your goal? To bring up old, bad feelings and preempt a good thing from happening? I'd suggest you just cease since you're not adding anything to this thread at all.

[rjamorim]

Originally posted by BetaBoy
do you truly think this is a good thing? It maybe for XIPH/Theora/OGG and Emmett but surely not in the big picture, not at all.

I wonder what is this "big picture" you talk about.

IMO, it's surely a great thing that Tobias' work has became "official". It'll be another nail in (what I expect to be) AVI's coffin. More people will get in touch with OGM, and start working with it.

What is your goal? To bring up old, bad feelings and preempt a good thing from happening? I'd suggest you just cease since you're not adding anything to this thread at all.

Amen to that, Keynes.

[-h]

Now these faults have been fixed and coding is already in prgress for the new libraries, both C++ and Java.

C++ arghgghhghghhh.

-h

[gldblade]

Java arghgghhghghhh

[tangent]

Originally posted by BetaBoy
Funny how this has all gone down. A few other people along with myself have different perspectives if and why Tobias might have joined XIPH. Some good some bad.

Just wondering... oh btw... this log is 4 days old.

When Emmett said "We do not support OGM", he really meant something like "We do not provide technical support for OGM". This document should clarify everything: http://www.xiph.org/ogg/ogm-draft.html.1

[tangent]

Originally posted by Neo Neko
They knew eachother for a long time. IIRC the major hold-up was from Tobias's end. If I understood Blacksun correctly Tobias is a relatively new coder and kinda shy to boot. He did not want to release his code untill he was sure he had polished it good.(something about him thinking his code might be sloppy and embarrasing) So either he got it polished or Blacksun gave Tobias a good pep talk.

You have to admit. It could be a bit much going from an obscure nobody in Spain to a well known famous though somewhat reclusive figure on the encoding sceen. How would any of us react in his place. ;)

What actually happened was that for some reason, mail to Tobias from Xiph was being spam-filtered. When Emmett finally got through to Tobias (via Blacksun I believe), everything started happening real fast.

[tangent]

Originally posted by Koepi
So now OGM is Ogg ;)

Not exactly. From what I've gathered, most of the great work which goes into OGM will make it into Ogg but will be spec'ed according to Monty's earlier plan. There will be a converter available to convert current OGMs to the new Ogg. My main worry would be that the present ogm filters are called OggDS, which may cause confusion in the future..

[neo_sapien]

Originally posted by spyder
OK, that last part was rude...retracted.

I don't know what you said, but my bad anyhow. I can see how my previous post could have been perceived as smart alecky and unappreciative, and that wasn't my intention. I know that you guys have put an honest to god titanic amount of effort into this new container, and I really am appreciative, as is all of the Doom9 forum. I spent quite some time converting all of my DivX AVI files to OGG back in early 2002, and I'll likely do it all again when Matroska comes out.

[ChristianHJW]

Its good to see that Xiph people will now officially open up the scope of codecs to be put into Ogg. Although never confirmed officially by Xiph team, rumour had it that Ogg Theora should stay restricted to patent free codecs being part of the Xiph family, such as FLAC and Speex, and of course the Xiph codecs itself, means Vorbis and Theora, later Tarkin.

I guess the users of this board here can confirm that these restrictions, if enforced, would have been a big obstacle for the wide spread use of Ogg Theora as a frame work, as video encoders definitely want to have the choice of which codec to use, like AC3/AAC for audio and MPEG4 ( DivX/XViD )/ RV9 etc. for Video.

Now with Tobias work, or at least parts of it, finding its way into official Ogg Theora specs we can at least expect support for all VfW video and ACM audio codecs, even MP3 and AC3. I heard there are other plans also, with respect to a plugin system similar to UCI, so that other codecs could be added also.


With respect to matroska :

We will continue to work on it. Emmett was asking me lately on IRC what the point is in continue developing it, and as i am not a technician but only a organizing guy i know i have failed to give him a satifactory answer. I simply believe in the expertise of the matroska project technicians, who told me many times that Ogg is a very good container for audio and streaming, but it will be pain in the ass to guarantee it can satisfy all needs of the video encoding community without breaking compatibility with existing Ogg parsers.

This project was started about 2 years ago ( as MCF this time ), when it was completely unclear how the future of Ogg might be looking with respect to video, and we also didnt have the feeling that the Xiph people were very much interested in the needs of the mostly Windows based video encoding community. Things have changed a lot since then, but please understand we will not abandon the work we have invested now, but finish the project ( robux4 is in vacation on Reunion Island now, visiting BlackSun and checking out Reunion Ladies :D .. so dont expect anything before February ), release tools and example files, and leave the decision what container to use to the users. Maybe when John 'spyder' Cannon has finished his work on mf's hybrid Bob AVS filter we can expect the JMF implementation 'Javatroska' a bit earlier ;) !!

[Emmettfish]

We will continue to work on it. Emmett was asking me lately on IRC what the point is in continue developing it, and as i am not a technician but only a organizing guy i know i have failed to give him a satifactory answer. I simply believe in the expertise of the matroska project technicians, who told me many times that Ogg is a very good container for audio and streaming, but it will be pain in the ass to guarantee it can satisfy all needs of the video encoding community without breaking compatibility with existing Ogg parsers.

That's not exactly what I was asking. Not 'Why bother?' but 'Why?' and 'What?'

I have been inundated with 'UCI rocks' and 'Matroska rocks' for the past several weeks. You are the only person I see on a regular basis from that project, so I asked you. Specifically, I asked 'What's the big deal?'

I wanted to know what was so great about Matroska that people were asking me about it and giving it effusive praise constantly. Simply put, what was Matroska doing that Ogg could not? It's a purely self-serving question; I want to help make Ogg as useful as it can be.

The problem is this: There is nothing planned for Matroska that is impossible to implement in Ogg. So, why the new project? I'm told it's because people 'got the impression' that Xiph didn't care about their needs, et cetera. Truth is, no one asked.

I hope that the Matroska team keeps working on what they're working on, if that's what they enjoy doing. We could always use help with Ogg, that's part of the reason it's Open Source. As far as meeting the needs of the video encoding community, we're working on it. All of the work that's been done on Ogg since last June has been in finishing the format to allow for video encoding.

We're thinking beyond just the DVD rippers; We're working with producers and broadcasters, as well. We need to make sure the toolchain exists to use Ogg with the video flavor-of-the-month, and also give people the functionality they need, not just for storing video on personal computers, but in broadcasting, as well. We have a high target.

I think a lot of the problem is that people think that work on Theora is just work on building and integrating a video codec into Ogg. Not so; Most of our work on Theora is finishing Ogg so that it will serve the needs of the modern video encoding crowd. That includes broadcasters, independent filmmakers, and even people who want to archive their DVD's. Only one of those three categories make up the primary readership of Doom9, for example.

Okay, let's be honest - You can't please everyone. We talked about this a little on IRC today. Support for 'all codecs' isn't really possible (regardless of claim by the Matroska team). I brought up codecs used back in the 70's for analog video synthesizers; There's no way that Matroska will be able to support this. Same for Ogg. You'd have to write an emulator, do all kinds of strange mojo. You have to put limits somewhere.

As far as the 'no other codecs' claim for Ogg, it's nuts. I've put mp3's into Ogg before. I did it about a year ago, just to see if I could. It's not impossible. People need to understand that there is definitely a line between Ogg and Vorbis, and that Ogg is a container. Why would we bother doing so much work on a container if it only existed to hold Vorbis? We've never said 'no other codecs.' Don't know where ya heard it.

In my perfect world, the Matroska team would work with us to make Ogg a better container, instead of re-inventing the wheel using standards that don't exist (UCI). Ogg is widely adopted, and people use it for a lot of different stuff. I'd like to give the world something better if I can.

I don't know the chances of this happening. It would take a lot of coordination, and a lot of work, but I'm here if anyone's interested in entertaining the option. The future looks really bright. We've got a lot of smart people working with us, but I'll always welcome a few more.

Wow, this is really long. I'm going to stop writing now, and see if anyone comes up with some cool ideas in this thread. :)

Emmett Plant
CEO, Xiph.org Foundation

[spyder]

Well, I'm glad to hear such kind words from you Emmett. I see no reason that Ogg and Matroska can't coexist. All our time has been put into developing a flexible container that allows technically any codec(through infinitely long identifiers) and any type of stream to be stored. The original team decided against extending Ogg not only because it is too primitive in structure to accomodate easy extensions and bacward compatibility. Matroska is based around extensibility. I would like to know how you think Ogg can accomplish these things without breaking compatibility. And what overhead will this incur? I will join #vorbis tomorrow some time. I will be visiting from time to time to see. I will also come up with some document outlining the benefits of Matroska and examples of how the structure may be extended without destroying it all. We have spent a large amount of time consulting with experts in these areas and taling with codec developers about their needs and what could change. I am looking forward to the conversations. And I am sure that Steve will be happy to join #vorbis when he is back too.

Spyder

[Atamido]

To make this quick, I'm going to copy and paste some things that I've already typed, but most people, I'm sure, aren't where they would read it.

This is in response to what I would think about stopping Matroska and trying to make OGG better.
IMHO this is just silly. It is akin to the developers of the RedHat Linux distro sending a message to the developers of OpenBSD saying to stop what they are doing and just focus on improving RedHat . Sure, they have similar goals, but the goals are not identical and the approaches are different.

OGG was developed to be able to stream just about anything.

MCF was developed to be an excellent video editing format. A very efficient and fast fixed structure system.

Matroska was branched and fundamentally redesigned to be a completely extendable format that could last at least the next decade.

Sure, they were all designed to hold media streams, but the purpose of each is different. We could all start working on improving OGG, but because of the design, there is no way to make it nearly as flexible as Matroska without completely breaking backwards compatibility. And if you're going to do that, why not just use Matroska?
Matroska can handle any framerate down to the nanosecond, including variable framerates. (Imagine a codec being able to use less frames during low motion scenes.) It can also handle other non-frame based codecs. And, because of the hierarchal and the completely extensible nature of Matroska, adding in new types that haven't been thought up yet won't break backwards compatibility. If anyone could point out a way to make OGG as flexible, with the exception of putting Matroska in OGG, please let everyone know.

This is in response to the silly 70's 'codec' issue. (Does anyone know if that would even be called a codec?)
You could define it really specifically when you say 'all codecs', but there isn't a need because people know what you are talking about.
For example, "Matroska can hold any time based multimedia stream that the creator of such stream would like to store in it without changes to the structure of the stream." It could store a lot of other things too. But there isn't a need to define specifically everything that it can stored in Matroska because it would be impossible. The point of Matroska is that because it is so extensible it is extremely easy to support, or to add support for almost any kind of stream or structure. Another great benefit is that it has been well defined, so there aren't questions about how to do things, or how things should be stored. This was a big issue when OGM was created. Things hadn't been defined, and noone would define them, so Tobias did his best to make a standard. I, personally am happy that Xiph has finally decided to work with OGM and define how things should be stored and should work.

I look forward to the day when many companies use OGG to stream media to us. But, I also look forward to being able to edit movies in Matroska and use any of the many features that have been defined in it. Sure, you'll be able to stream Matroska file, but I'll bet that in most cases OGG will handle all of your general streaming needs better. And sure you'll be able to rip movies to, and edit movies in OGG, but again, I'll bet that in most cases Matroska will be better suited to the task. When we hype Matroska to the people on Doom9, and many other forums, its because its the group that will use it.
So, I'm not out to get anyone.

I really want to say Go OGG!!! Go Matroska!!!

[Atamido]

Man, all that typing and I forgot to mention UCI. (http://uci.sourceforge.net) Emmett seemed so concerned about it.

Well, I was typing about UCI, but it seemed even more off topic, so I just put it in its own thread here. (http://forum.doom9.org/showthread.php?s=&threadid=42483)

[Liisachan]

Let me comment not as a developer, but as a user:

Indeed I was waiting for MCF/Matroska,
because it has clear and minute specs.
Their documents even contain how to put Karaoke in sub-text stream.
They have also declared that the def encoding for sub-text is UTF-8.

So-called Ogg Media (OGM)--which was not actually Ogg--
was unclear, vague, in specs.
It s trying to support unicode, but in reality,
vobsub parses the sub-text in OGM as Ascii (more precisely,
Windows CP1252)
This means that it s almost impossible to put subtitles in
Multibyte encoding, such as in Chinese, Japanese or Korean.

So, those who are not too "Enlgish-centric" will easily understand
why we are not very happy with today's OGM, and we were waiting for MCF.

Why did this happen? Because there were no solid specs for OGG.
IMHO the current spec for Ogg is too "loose" tho u can call it "extensible" too.

Anyhow, quite a few ppl who speaks not only English were waiting
for MCF. Ogg would be OK if you muxed English sub-texts only,
but not so good for French, German, etc. not to mention CJK langs

I know it is not xiph's fault directly.
Only, when I first saw MCF's docs,
I was really impressed.
I felt that Ogg's specs too could have been minute like this.
and if the specs were expressed clearly,
all software like OggDS, VobSub, Oggmux, Vdubmod, etc. must have followed that and there were no confusion as it is today.
(e.g. Tobias says u can put <font> tags in SRT,
while Vobsub will ignore that)

well, what has already happened cant be changed,
and maybe that was a good lesson...i hope everyone will take this positively
That Tobias joined the ogg team is great news, making us happy and
relieved, at least so far.

I hope the ogg multimedia specs will be detailed before long,
with maximum compatibility with Today's "OggDS"

I also hope that MCF Matroska will go on too,
as long as they want to do so,
because competition will produce refinement for both.
Generally, if there were no competition, anyone could be dogmatic.

For obvious, practical reasons, new "true" ogg media specs should support today's OGM specs in one way or another
Nobody wants to be told "You should convert your OGMs into new ture Ogg Media format, or you cannot replay that"
There are hundreds of thousands of OGMs already in this world,
and it is needless to say that players in the future can replay them easily.

[Emmettfish]

Spyder:

We're working on this now; I didn't at all mean to imply that Matroska couldn't do something better than Ogg. I just said that given the information I was able to obtain about it, there was a lot of re-inventing the wheel going on. I really, really hope you and the other Matroska developers would stop by IRC once in a while, it would be great to see you.

Pamel:

What are you smoking? I haven't asked anyone to stop development of anything, and I wouldn't. I'm just looking for a little justification of claims, because by what I'm being told, I can't see a tremendous difference of *difference* in the projects. Maybe there are things that I don't know or can't see for one reason or another. If the goals of the project are adequately different, I see no reason at all not to keep projects separate.

As far as the 'all codecs' issue, it was the primary 'selling point' for Matroska as told to me by ChristianHJW. My basic response was 'no way in hell,' and I stand by it. Please remember that a Chilton manual for a 1998 Nissan Sentra is not a Nissan Sentra. Matroska may eventually support a vast number of codecs, but claiming 'all codecs' is nuts.

For instance, just because you can provide a specification on how to do something does not necessarily mean that it can be done, or done well. Someone may be able to tell me in perfect detail how to run a four-minute mile. That does not guarantee that I'll be able to do it, or that I'd be willing to go through the work necessary to get there.

I know this isn't really the point; The point here is extensibility and flexibility within the format. I just want to try to bring some reason into the discussion of these things.

I'm really sorry to hear that Alex has dropped off the face of the earth with UCI. Is he alright? Has anyone tried to call him to see if he's okay?

Liisachan:

Don't worry... Early reports say that you'll be able to translate current ".ogm" files into standard ogg later on without loss of quality. You can even keep your old file extension, if ya want. :)

Emmett Plant
CEO, Xiph.org Foundation

[Atamido]

Originally posted by Liisachan
Let me comment not as a developer, but as a user: Well, if thats your user response, I would love to hear your developer response.

I am basically on the exact same page as this post by Liisachan (with the exception of the language portion, as I only speak english :rolleyes: ). For the subtitles, the spec has actually been removed from the Matroska spec. It was felt that defining a subtitle spec was outside of the scope of the container. But this was only done once a suitable replacement was found. Got off topic, go here (http://forum.doom9.org/showthread.php?s=&threadid=42489) to read about the subtitles.

I really do look forward to Xiph defining the specs better so people know how to create tools.

I started to follow MCF for basically the same reason. Xiph wasn't defining anything, and OGG was designed around streaming anyway. The Matroska team has done a very good job of defining their specs so far. I even created an XML representation of a Matroska file from the specs, and it wasn't hard. (There will likely be a tool that will extract out an entire (excluding binary data) Matroska file to XML for debugging.) I discovered a single tiny flaw in the specs, and a few points that needed to be more clearly defined. I asked a few questions from one of the developers, and that was it. The specs aren't frozen yet until a working parser is completed, but not much will change.

I don't really see OGG and Matroska as competitors. OGG and ASF would be competitors. Matroska and AVI (maybe MOV or MPEG?) would be competitors. But I think that OGG and Matroska would both win when compared like that.

It should be noted that I am not a developer, and I'm not even a member of the MCF or Matroska team.


@Emmettfish: I don't smoke. And I own a 1997 Nissan Sentra, not a 1998. And while I know little about running, I don't think I will ever reduce my 20 minute mile to 4 minutes.

If I said (though I didn't) "Matroska could support any codec" I would just be placing faith in the human race that they could figure out that this would be limited to digital codecs (again, if its analog, is it really a codec?), and that it would mean that a codec producer could store some new, totally revolutionary, type of stream in Matroska. Sure it may require some additions to the spec, but it would work and it wouldn't break backwards compatibility. (Yes, there could in theory be something that comes out that couldn't be supported, but this in unlikely in the near future.) Though I think that in this case it may just be a matter of semantics. I wouldn't call a Flash player a codec, but you seem to want to. (We actually already discussed putting flash into Matroska, BTW)

Dunno. Seems like this thread is turning into a waste of bits, and I can barely see the screen because I need sleep. Sorry about the ideas being disjointed.

[ChristianHJW]

Emmett,

i was taking my time to reply here, sorry for that, because i wanted things to settle down a bit, but as the discussion is in full move already i guess its time to participate. After all, this is not a dispute at all, but two open source projects with similar goals talking to each other in a friendly and useful manner.

Originally posted by Emmettfish
That's not exactly what I was asking. Not 'Why bother?' but 'Why?' and 'What?' I have been inundated with 'UCI rocks' and 'Matroska rocks' for the past several weeks. You are the only person I see on a regular basis from that project, so I asked you. Specifically, I asked 'What's the big deal?'
I wanted to know what was so great about Matroska that people were asking me about it and giving it effusive praise constantly. Simply put, what was Matroska doing that Ogg could not? It's a purely self-serving question; I want to help make Ogg as useful as it can be.

We have a big problem here : our very limited resources !! ( i guess you are well aware of this specific problem ).

While the matroska specs (http://matroska.sourceforge.net/specs/index.html) are more or less ready and documented in a doxygen (http://www.stack.nl/~dimitri/doxygen/) format, all the alpha tested tools we have ( matroskaparser, VdubMod ) are still waiting for an alpha version of libmatroska to be able to finally generate valid matroska files. Why isnt it finished yet if your specs are done you may ask ? Well, because there is mainly one person working on it, and thats Steve 'robux4' LHomme.

Steve was also the best man to point out why using Ogg was no option for us, as he has been with the project from the very start, and hopefully is capable of reminding all the extremely valuable input give to us from video encoding experts like Ingo Ralf Blum and Alex Stewart.

Now, if Steve sits down to document why we didnt use Ogg, he cant finish libmatroska. You will certainly agree that this is no good option for us. Instead i recommend you make Monty browse through the old MCF archives here http://news.gmane.org/?match=gmane.comp.video.mcf and the matroska archives here http://news.gmane.org/?match=gmane.comp.multimedia.matroska , because much of the information how a good video container should be looking, including some comments why this may not be done in Ogg nicely without breaking backwards compatibility with existing Ogg parser is in them.

The problem is this: There is nothing planned for Matroska that is impossible to implement in Ogg. So, why the new project? I'm told it's because people 'got the impression' that Xiph didn't care about their needs, et cetera. Truth is, no one asked.

First, matroska is NOT a new project. matroska is more or less the EBML MCF specs that were blocked by Lasse 'Tronic' Karkainen, so they couldnt become the final MCF-1 specs. This is the result of 2 years of work, tough discussion, many considerations and serious development. Nobody can ask us to put this into the trash now, just because situation on OGM has changed when Tobias joined Xiph now.

Second, i was browsing theora.org and xiph.org a lot in the last months, but honestly cant find any real information on what you are actually planning to do with it. No description of the features you plan for it, nothing. As you know i am logging on irc.xiph.org #theora all the time, but from all the logs i read i couldnt get any real idea that you were planning to add support for other codecs than the Xiph codecs ( admittedly i didnt read all logs ).

Third, i cant agree if you say nobody asked. In the process of talking to you guys about OGM and its status, and i guess everybody who was involved in this ( including Doom9 himself ) can confirm this here, there was no sign of interest from your side ever about the needs of our group of people here. Admittedly we may have a much lower importance than broadcasters and content release companies to XipH, but if you read through the old logs you cant help but get the impression nobody from Xiph even took notice of our needs and wishes. A very good example, sorry if i have to stress the story here, is the outcome of the effort the members of this board took to provide Monty with 5.1 samples so he could have a look at a decent 5.1 encoding and channel coupling profile. No outcome from this, thats ok with me, you have your internal priorities for sure. But even not a single word from you or Monty, saying thanks about the provided samples and giving us a short explanation why there cant be any work done here for the time being ..... nothing ....
Now, with Theora aiming to be accepted as a patent free video codec, things have changed significantly. This user group here migrates into the center of Xiph's interest, and you are trying to win people for your ideas. Certainly no objection to that from my side as i had been doing the very same for a very long time ( people on this forum can tell i guess ;) ) .

I hope that the Matroska team keeps working on what they're working on, if that's what they enjoy doing. We could always use help with Ogg, that's part of the reason it's Open Source. As far as meeting the needs of the video encoding community, we're working on it. All of the work that's been done on Ogg since last June has been in finishing the format to allow for video encoding.
In my perfect world, the Matroska team would work with us to make Ogg a better container, instead of re-inventing the wheel using standards that don't exist (UCI). Ogg is widely adopted, and people use it for a lot of different stuff. I'd like to give the world something better if I can.
I don't know the chances of this happening. It would take a lot of coordination, and a lot of work, but I'm here if anyone's interested in entertaining the option. The future looks really bright. We've got a lot of smart people working with us, but I'll always welcome a few more.
Emmett Plant ; CEO, Xiph.org Foundation

Emmett, thanks for the invitation to join Xiph and merge efforts. I cant speak for the rest of the team, but please accept i personally wont drop matroska now, with the end of the tunnel being before my very eyes.

I also personally do believe its a good thing to have the container format be an independent project rather than a part of the biggest and most successful entity developing state-of-the-art, patent free codecs. Many companies releasing codecs may hesitate to add an open standard codec API interface ( UCI, or whatever else we may come up with ) to their codecs if this API was created by a direct 'competitor', releasing open standard codecs that are even better than their own stuff :D !

As i was pointing out many times, its not at all in our interest to piss anybody from Xiph, as both Vorbis and Theora will be very very important codecs for matroska, no doubt here. We also invite the Theora development team to browse through our mailing archives ( see links above ) to gather as many infomration they may get about how much considerations were invested into matroska and why we are doing things they way we do, and not the Ogg way. I am convinced this information can be very useful for you to make Ogg Theora a very successful project in the end.

Regards

Christian

BTW : could you please stop at least some of the badmouthing of matroska on #vorbis ? I know these people there are Xiph enthusiasts and overreacting a bit now, misunderstanding the actual situation and the friendly reationship between the two projects. But please try to balance it a bit out, will ya ?

[Emmettfish]

Quoth Pamel:

@Emmettfish: I don't smoke. And I own a 1997 Nissan Sentra, not a 1998. And while I know little about running, I don't think I will ever reduce my 20 minute mile to 4 minutes.

Wow. I didn't even know you owned a Sentra. Just a random car guess.

If I said (though I didn't) "Matroska could support any codec" I would just be placing faith in the human race that they could figure out that this would be limited to digital codecs (again, if its analog, is it really a codec?), and that it would mean that a codec producer could store some new, totally revolutionary, type of stream in Matroska. Sure it may require some additions to the spec, but it would work and it wouldn't break backwards compatibility. (Yes, there could in theory be something that comes out that couldn't be supported, but this in unlikely in the near future.) Though I think that in this case it may just be a matter of semantics. I wouldn't call a Flash player a codec, but you seem to want to. (We actually already discussed putting flash into Matroska, BTW)

Okay, fair enough. I was being particularly obtuse on the 'any codec' claim because that's the primary one I was given for Matroska's superiority. But what I'm saying here (and please, someone tell me if I'm wrong) is:

Matroska will not support every digital codec known to man out of the box. Due to intelligent design, the ability to add new codecs to the container aims to be a less painful process than it has been in the past. This is nothing to sneeze at. Codec implementation is more often than not a huge pain in the ass.

What I'm saying is that detailed instructions on how to do a thing are not the same as doing a thing. The 'will support any codec' is an extrapolation on the current spec, and I think that claim is a little specious. I'm not saying that the design won't work, I think a lot of the ideas in the current spec rock ass. I'm just saying that the ability to do a thing doesn't always make the action fait accompli.

I guess I'm just a little tired of people proclaiming the existence of Matroska as the death of Ogg. I really think we're both headed in different directions, to be honest, but we do share a little road-space. I'd like to work together on that road space, so that we can both get to where we want to go more easily.

Emmett Plant
CEO, Xiph.org Foundation

[Emmettfish]

Yeek! Lots of points to go over here...

First off, if you've sent stuff that's gone ignored, I'm very, very sorry. We also suffer from a lack of resources, time being one of the most problematic. Please do not treat our silence as ignorance (or more importantly, vitriol!).

As far as not being interested in helping people here, that's not quite true. We do not have the resources to hang out on web-boards and post all the time. I wish we had a ChristianHJW.

I feel that in a very large way, I cannot win. If I post on Doom9 all the time, I won't get any work done, and projects will fall to the way-side. If I do not post here at all, it's taken as complete ignorance or worse, abject hatred.

I think there's a natural tendency on web-boards to focus on the negative.

Emmett is posting = He just wants to win people over to Ogg.

Emmett is not posting = He hates us and doesn't care.

Emmett is asking questions = He is attacking our project.

Emmett is not asking questions = He is ignorant.

What's the solution? I don't know.

Emmett Plant
CEO, Xiph.org Foundation

[bond]

Hm seems that the competition between matroska and ogg will become a good successor for the divx3 vs divx5 dispute although the two doesnt even exist :D

lets try some marxist dialectic:
divx3 vs. divx5 -> xvid
matroska vs. ogg -> ?

No sorry for the last sentence, i dont want to discourage you guys :p just continue your great work!

btw: i heard that doom9 is already working on the ultimative container comparison test ;)

[DAvenger]

:eek: :D :D :D :D you guys really have nothing better to do, do you?

[ChristianHJW]

Originally posted by DAvenger .. you guys really have nothing better to do, do you? ...

Martin, instaed of making jokes here you should try to read a few times what was said above, and try to adapt a little bit from it for yourself, especially with respect to the tone and the wording that is used.

I am convinced it would help you a lot to avoid stepping on everybody's feet all the time ...

[DAvenger]

I read it and be sure I perfectly understood what's going on ... maybe even better than you did ;)

Nevermind, even I wanted to have my OWN fileformat :D

Take care,
DAvenger

[MfA]

Originally posted by ChristianHJW
Steve was also the best man to point out why using Ogg was no option for us, as he has been with the project from the very start, and hopefully is capable of reminding all the extremely valuable input give to us from video encoding experts like Ingo Ralf Blum and Alex Stewart.
Alex has a nice site though, so lets take his objections for a moment ...

"absolute granule position" very vaguely defined
His solution, define it as a timestamp ... well fine, that is perfectly compatible with the ogg format. Lets move onto something more serious.

No per-packet sequencing/presentation information (timecodes, etc)
His solution, add it. Suggested solution, put an extra level of abstraction on top of ogg (if you want to preserve the original bitstream from the codec as a stream that means putting in another stream with appropriate data).

No way to identify "keyframes", or other per-packet info useful for stream handling
See above.

Multiplexing granularity is tied to CRC granularity
His solution, radically change the Ogg format.

I dont think there is a real problem, except maybe for realtime streaming. For offline coding you can obviously accumulate low bitrate streams into big pages (needing a 64 KB buffer per stream for decoding is not a problem, not even for embedded devices) this degrades the temporal correlation a bit, so at the cost of a little extra buffering the encoder can reorder the pages so the low bitrate streams come "first" (can you specify the "order" for concurrent multiplexing in libogg?).

Anyway, that ties in with his only truely fundamental issue with Ogg ... overhead. Is ~1% overhead really a problem?

My only real gripe with Ogg is that they allow the sychronization sequence to occur outside the start of the page.

Our little world would have been a friendlier place if MCF had abstracted Ogg instead of replacing it :/ Oh well, no use crying over spilled milk. The battlelines have been drawn, but I personally dont think there is enough room for both.

[Hajime]

Originally posted by Emmettfish

Don't worry... Early reports say that you'll be able to translate current ".ogm" files into standard ogg later on without loss of quality. You can even keep your old file extension, if ya want. :)

Emmett Plant
CEO, Xiph.org Foundation

I don't think this as a good idea, we have a lot of today's ogm files in cd-r or dvd-r, your solution means convert to new format, burn again and drop the old one, this is not optimal. A special treatment of the old ones in the new directshow filter is preferable. Don't drop the legacy support.

Just my 2 cents.

[Doom9]

@Emmettfish: Sometimes a small "Thanks for your submission, we'll look into it when time permits" is enough.. that's what I'm always trying to do with anything that comes my way. If you forget about it afterwards at least the guy on the other end knows that I got his stuff.

I for one don't think your 4 equations are really true. But a bit more PR couldn't hurt. While the ripping community may only be a small fish compared to your global audience imho they're an ideal testbed for new products. You'll have a hard time finding people that eager to adopt something new in the corporate world. And, when you say producers for me that means editing... an area where in the past Ogg didn't look so good (here I'm using your Ogm = ogg paradigm). The people around here care for more than just convert the movie and be done with it.. they want to edit, change and reconvert their streams (personally I think there's a lot of things people want to do that doesn't make much sense so maybe you're thinking that people wouldn't do it just because there's no guide on it on doom9.org.. but that's not true). In fact, one reason why there are people coming to you with stuff about Matroska/MCF is that they feel that their concerns are taken more seriously in the "opposite" camp. From the beginning it was clear that there would be a VirtualDub version supporting mcf so people knew that they could use their old tools which is quite reassuring. And matroska/mcf intends to solve most problems that are plagueing rippers these days which makes it even more interesting.
When it comes to Theora most people (including me) have a vague idea. When you say based on VP3 people will recall the codec comparison featuring VP3 and turn to something more interesting (XviD;). I know that OpenDivX also didn't look good before it turned into XviD so there's certainly hope for the video part of your projects but it needs a lot of work.. and as long as there are no visible results all people have are the VP3 results which are disastrous.
I think that the mcf/matroska team is doing a better PR job (though Chris is really pushing the limits of rule5 with some of his posts). We know that matroska handles AC3, VBR MP3 and Vorbis audio without problems, and that it will support DivX3/5 and XviD. Then it supports XCD and subtitling. What does Theora do? VP3 quality video with Vorbis audio? srt subs (from the Ogg DS subtitler)? Streaming? (matroska does that too). These are my thoughts when I think about the two formats and I think a lot of people think the same. Of course, this shouldn't deterr you as your past results (Vorbis is excellent) speak for themselves, but until you deliver the goods with Theora you have to fight the issues mentioned above.

[spyder]

I hereby publicly retract the statement that we have put more thought into containing video, subs, etc. in out format. Emmett so happily pointed out on IRC that this is not true in his opinion. This was simply MY opinion and still is. He has agreed to get us the answers we need from Xiph about Ogg's abilities ASAP. Expect us to post on the ML.

Spyder

[Emmettfish]

I hereby publicly retract the statement that we have put more thought into containing video, subs, etc. in out format. Emmett so happily pointed out on IRC that this is not true in his opinion. This was simply MY opinion and still is.

My opinion does not matter. My issue is that you were making a public statement about something that you did not know to be true, and that comments like this do nothing to help either of our development efforts.

If anyone's going to have anything useful after this is all said and done, it's probably best to keep public statements to fact, and not opinion; Veracity as opposed to conjecture.

Emmett Plant
CEO, Xiph.org Foundation

[Atamido]

Originally posted by Doom9
While the ripping community may only be a small fish compared to your global audience imho they're an ideal testbed for new products.Rippers are not small fish, they're more like the small gears that connect all of the big gears. They are the ones that started the DivX phenomenon, and really the whole PC video editing scene. They are a smaller group, but very key and not something that should be ignored.
when you say producers for me that means editing... an area where in the past Ogg didn't look so good (here I'm using your Ogm = ogg paradigm). The people around here care for more than just convert the movie and be done with it.. they want to edit, change and reconvert their streamsI think this is how most people feel. Really, the whole reason for the MCF development starting was so that we would have a good editing medium that was well defined. Matroska embodies this ability with the goal to be a standard for many years. I think that video editing and storage is best left up to Matroska. Once some specs are defined in OGG, it should be a simple matter to transcode most material to OGG after the fact for streaming.
I think that the mcf/matroska team is doing a better PR job (though Chris is really pushing the limits of rule5 with some of his posts).Well, what to you expect? It is Chris afterall.

What does Theora do? VP3 quality video with Vorbis audio? srt subs (from the Ogg DS subtitler)? Streaming? (matroska does that too). Yes Matroska streams, but there is a difference. The idea was to make Matroska streamable, not to make it a streaming format. OGG is an editable streaming format. Matroska is a streamable editing format.

Focus your format for what it was designed to do. Don't sacrafice any of the streamability to make OGG a better editing format, or you would be missing the point of OGG.

Edit: Swapped word in bold to improve semantics to please Emmett.

[kxy]

Originally posted by Hajime
I don't think this as a good idea, we have a lot of today's ogm files in cd-r or dvd-r, your solution means convert to new format, burn again and drop the old one, this is not optimal. A special treatment of the old ones in the new directshow filter is preferable. Don't drop the legacy support.

Just my 2 cents.

I agree with Hajime 100 percent. I also prefer a special treatment of the old ones in the new directshow filter route than having a tool to convert them. I am sure there will be more of us.

[Liisachan]

Like I said nobody wants to be told to convert (or translate) OGMs they already have.
If that happens,
I doubt I can support "new" "true" ogg media totally.
But let me ask something first...

From what I've gathered, most of the great work which goes into OGM will make it into Ogg but will be spec'ed according to Monty's earlier plan.

Are you going to change something because the current specs for OggDS & SubtitDS are inconsistent with open ogg specs?

Or just because Monty wants to use his own plan?

I dont want to be rude, but i ve been sortof uneasy

[Emmettfish]

Here's a snippet from an E-mail from Monty to myself:

"These files [OGM] will probably end up working just fine in OggFile, once that's up."

Chill out. Relax. Breathe in, breathe out. All is right with the world, and it is a beautiful day. There are no immediate or even long-term plans to screw with what currently works.

Emmett Plant
CEO, Xiph.org Foundation

[Liisachan]

Thank you Emmettfish...
I m really glad to hear about the backward compatibility!

well, but technically, what you are saying (or what we are bothering you about) is not always so simple
i bet you are going to use utf-8, while SRTs are now in Windows Code Page...

example: we are now using 0x9C for the Ligature "oe"
(this letter is in french), which is _not_ compatible with UTF-8.
the Unicode table says U+009C is String Terminator,
and utf-8 is double-byte for U+0080 - U+07FF

[Atamido]

I would encourage the Xiph/OGG team to look at using the Universal Subtitle Format. It is opensource and should fulfill your needs quite well. The most recent version of available specs are here. (http://christophe.paris.free.fr/usf/USF_V100-20021204.txt) Please point out any alterations that should be made in these forums. (http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewforum&f=12) We really want this format to be able to be used in current containers and your input would be extremely valuable. Also, good support from both OGG and Matroska would really help to standardize this.

@Liisachan: Please look at the specs and contribute in the forums. The more help there is, the better the format will be.

[Liisachan]

@Pamel: ok i will, when i have time

1) Generally, encoding in sub-texts should be lang-independent,
or in short Unicode
so you can put sub for, say, "Korean Lesson for Arabic Speaking ppl"

2) Hopefully sub-stream in OGM will be at least as powerful as SSA or ASS, but Muxing SSA directly is not good idea unless you use only English

I just have had a quick look on
http://christophe.paris.free.fr/usf/USF_V100-20021204.txt
This is not bad, but you'd better put Border-Width, Border-Color,
Shadow-Width, Shadow-Color in the default style definition section
...these 4 params are also basic for subber

(ins)
well, supporting ssa IN UTF-8 might be wonderful too
and, Ogg People!!! We d like to also "mux" font data files!!
(/ins)

[MaTTeR]

Originally posted by ChristianHJW
A very good example, sorry if i have to stress the story here, is the outcome of the effort the members of this board took to provide Monty with 5.1 samples so he could have a look at a decent 5.1 encoding and channel coupling profile. No outcome from this, thats ok with me, you have your internal priorities for sure. But even not a single word from you or Monty, saying thanks about the provided samples and giving us a short explanation why there cant be any work done here for the time being ..... nothing .... Funny you should mention that, I just found all 508MB of those samples on 1 of my drives a few days ago and debated for a few minutes if I should trash them.

I have to say that an OGM->Ogg conversion tool doesn't really appeal to me either. I'd venture to say that more than 90% of the OGM users will prefer a DSF solution. If it's not possible, guess we'll have to figure out a way to keep Tobias's OggDS filter installed along side the newer Xiph software.

Glad to hear Tobias has joined the team personally. This means we now have a new person to bug about 5.1 channel coupling:D :D

[MfA]

USF's lifespan does not promise to be all that great with W3C working on a open timed-text format, translation between formats is trivial though so it dont matter much.

[[Toff]]

Originally posted by Liisachan
I just have had a quick look on
http://christophe.paris.free.fr/usf/USF_V100-20021204.txt
This is not bad, but you'd better put Border-Width, Border-Color,
Shadow-Width, Shadow-Color in the default style definition section
...these 4 params are also basic for subber

In fact they already are, I think that you haven't seen them because of some display problem with tab.
Look at §3.2 after the "back-color" attribute.

Originally posted by Liisachan
well, supporting ssa IN UTF-8 might be wonderful too
and, Ogg People!!! We d like to also "mux" font data files!!
(/ins)
Yes UTF-8 is great, here is the result I get with USF and UTF-8 in my test program :
http://christophe.paris.free.fr/usf/utf8_demo_1.png
http://christophe.paris.free.fr/usf/utf8_demo_2.png


There is still a lot of place for improvement.
If you are interested in USF, any input is welcomed in this thread :
http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewtopic&t=237

Originally posted by MfA
USF's lifespan does not promise to be all that great with W3C working on a open timed-text format, translation between formats is trivial though so it dont matter much.

Are you talking about SMIL ?
http://www.w3.org/AudioVideo/

[Atamido]

Originally posted by MfA
USF's lifespan does not promise to be all that great with W3C working on a open timed-text format If you're talking about SMIL (http://www.w3.org/AudioVideo/Activity.html), it doesn't seem appropriate because it appears to require the use of different files to load each text segment. If you're talking about TTWG (http://www.w3.org/AudioVideo/TT/ttcharter20020901.html), that project doesn't start until this month (Jan'03), and doesn't end until December 2004. I don't feel like waiting around that long for a good subtitle format.

Could you be specific on what project you were talking about? I am all for using standards, but they have to exist. If USF is good enough, it may well simply be used for TTWG as it is based on XML.

Boy, this thread just gets more and more off topic.

[h0MBRe]

Boy, this thread just gets more and more off topic.

to put it even more off-topic: ;)

somehow, when taking a look at matroska's design goals, i get the feeling we have a typical "second-system syndrome" as described by famous fred brooks.

just my two cents,
h0MBRe

[MfA]

Standardization is slow, but considering the prevailing mood on the mailing list a useable draft will almost certainly be available relatively early this year ... during the last year of the standardization process no real development happens.

The problem with SMIL is not so much that you need different files for each text segment, but that you have to rely on Quicktime's or Real's or m$'s timed text standards ... all lack some features, and I dont know if any but m$'s standard are completely open.

USF is almost certainly not compatible with the timed text charter, its features are not orthogonal with SMIL (fades, placement, language selection etc should probably be handled by SMIL, not the timed text format). It could be made so of course, If that is done it might indeed be a good idea to submit it for consideration.

[robUx4]

Originally posted by spyder
Anyway, the bottom line is that we will not cease development of Matroska because of this. We need a format designed from the ground up for these purposes not from the top back to the ground and up again. ;)

Nice sum up of my general point of view on OGG. ;)

I just wish them good luck with OGM in their CVS and the work necessary to put video nicely in OGG. At least the situation is clear now : the one working alternative to AVI is not supported anymore. So there is free room for everyone :)

[robUx4]

Originally posted by Emmettfish
I wanted to know what was so great about Matroska that people were asking me about it and giving it effusive praise constantly. Simply put, what was Matroska doing that Ogg could not? It's a purely self-serving question; I want to help make Ogg as useful as it can be.

Okay, let's be honest - You can't please everyone. We talked about this a little on IRC today. Support for 'all codecs' isn't really possible (regardless of claim by the Matroska team). I brought up codecs used back in the 70's for analog video synthesizers; There's no way that Matroska will be able to support this. Same for Ogg. You'd have to write an emulator, do all kinds of strange mojo. You have to put limits somewhere.[B]

Well, the basic idea of matroska is to be based on EBML (simple XML like binary format). That allows everything and unlimited field sizes. AFAIK this is breaking one rule you find in all existing containers I know. So of course we have limits, as we're defining rules and identifiers to say what information has to be put where. But we still have less limits that anything I know.

[B]In my perfect world, the Matroska team would work with us to make Ogg a better container, instead of re-inventing the wheel using standards that don't exist (UCI). Ogg is widely adopted, and people use it for a lot of different stuff. I'd like to give the world something better if I can.

You may have heard that we left MCF to build matroska because we felt like MCF was not good enough (although still a very good container). So we're definitely not re-inventing the wheel for fun. We make decisions when they make sense. And I'm sorry but from the short look at OGG (through the draft RFCs) I don't want to go that backward in time ;)

Also please note the matroska fork of MCF has been created with a discussion between Frank Klemm and myself (each improving the idea of he other). And AFAIK Frank wasn't happy with OGG when he was looking for a container for MPC. So there might also be some things that OGG can't do or do bad. But Frank would probably tell more about it.

I don't know the chances of this happening. It would take a lot of coordination, and a lot of work, but I'm here if anyone's interested in entertaining the option. The future looks really bright. We've got a lot of smart people working with us, but I'll always welcome a few more.

Well, I consider OGG as a streaming container. And since matroska is not built to be streamed (but still can be) we want to add a (additional) lower level of data encapsulation. OGG might be a working option (even though we have a few more ideas that couldn't make it in OGG).

[robUx4]

Originally posted by Emmettfish
Spyder:

We're working on this now; I didn't at all mean to imply that Matroska couldn't do something better than Ogg. I just said that given the information I was able to obtain about it, there was a lot of re-inventing the wheel going on. I really, really hope you and the other Matroska developers would stop by IRC once in a while, it would be great to see you.

I have a bad feeling in my mouth when I read this kind of thing.

Why should we improve OGG or come to you and not the opposite, which is never mentioned ?

Because OGG is working ? So does AVI and has not patent neither AFAIK. We just tried to build something from scratch without any legacy of old standard formats. That's why I personally avoided to look at the AVI and OGG specs for a long time. And I think the result is really worth it !

So if you want to improve OGG just look at what we did and join us if you have questions. Just don't ask us to spend time with you while we're busy making matroska a reality.

[Liisachan]

@ MfA
translation between formats is trivial though so it dont matter much

well, in this particular case, i m afraid we cant be so optimistic,
at least about Chinese/Japanese/Korean.
eg. Japanese texts (subtitles/chapter data) embedded in today's ogm may be in the Windows Code Page for Japanese (Shift_JIS), if generated by Win users, while Linux users may type chapter infos in Japanese in UTF-8.

The translation from any of these code systems to UTF-8 is trivial as you say, if you know the input encoding,
but the problem is, today's OGM files have only language-tags.
So the file may tell you that the SRT is in Japanese, for example,
but you can't know the actual encoding.

Actually, this confusion is also true about ogg vorbis & FLAC audio files. These tags are supposed to be in UTF-8, but Winamp2 for example is parsing them as windows cp.

So open specs publicized widely in advance will be really needed.

@ [Toff]
Your pics are really promising:
http://christophe.paris.free.fr/usf/utf8_demo_1.png
http://christophe.paris.free.fr/usf/utf8_demo_2.png

These are very difficult to realize with today's SSA, even as hard sub. I hope new Ogg will be like this too

In fact they already are

Umm, i meant "in the default style definition section"


<style name="Default" >
<fontstyle face="Arial" size="24" color="#FFFFFF" backcolor="#AAAAAA" />
<position alignment="BottomCenter" vertical-margin="20%"
relative-to="Window" />
</style>


i guess most fansubbers would do that in this section,
it's ok if you could do that anyway. sorry to go a bit too off topic...

btw. When will the new ogg muxer be released?
Are we waiting for Ogg Theora video codec?
i hope OggDS/subtitDS will be updated without waiting for Theora.

(actually I was waiting for Thepra alpha2 too, at the end of 2002 :))

[robUx4]

Originally posted by Emmettfish
Okay, fair enough. I was being particularly obtuse on the 'any codec' claim because that's the primary one I was given for Matroska's superiority. But what I'm saying here (and please, someone tell me if I'm wrong) is:

Matroska will not support every digital codec known to man out of the box. Due to intelligent design, the ability to add new codecs to the container aims to be a less painful process than it has been in the past. This is nothing to sneeze at. Codec implementation is more often than not a huge pain in the ass.

What I'm saying is that detailed instructions on how to do a thing are not the same as doing a thing. The 'will support any codec' is an extrapolation on the current spec, and I think that claim is a little specious. I'm not saying that the design won't work, I think a lot of the ideas in the current spec rock ass. I'm just saying that the ability to do a thing doesn't always make the action fait accompli.

Well, the idea here is that the container (at least in the case of matroska, that wouldn't be the case for MPEG1 for example) there is no limitation on what codec you can use. The problem is the API. How to put data from ACM, VfW, DirectShow, Quicktime, RealMedia (don't know the name of their API) in the same container ? That's the question. And that was supposed to go in UCI. So that's not a problem for matroska, I hope it's he case for OGG too.

I guess I'm just a little tired of people proclaiming the existence of Matroska as the death of Ogg. I really think we're both headed in different directions, to be honest, but we do share a little road-space. I'd like to work together on that road space, so that we can both get to where we want to go more easily.

Check the matroska specs. Also some fields may not be self explanatory, so I suggest you also have a look at the MCF where most of them are explained in details. The rest is in the mailing lists and forums. Hopefully they will make it to a bigger spec document when the format is ready for finalisation.

[robUx4]

Originally posted by MfA
Alex has a nice site though, so lets take his objections for a moment ...


His solution, define it as a timestamp ... well fine, that is perfectly compatible with the ogg format. Lets move onto something more serious.

Ah !!! No !!
That was my main shock when I read the OGG specs. There is no timecode but a time tick. A timecode store the information of time, a tick store a simple number and has to be converted to time using a multiplier...

Where is this multiplier stored in OGG ? In the container, in a header of the codec ? No, you have to call the codec to know. That's a very bad design IMO. There is no way to work with the container unless you have the codec installed and working. That's OK as long as the OGG==Vorbis confusion exists (yes it does) but it might be a drawback in the future. Especially as OGG is supposed to be streamed and so the streaming server (Real Helix ?) has to implement a part of each codec supported to handle time correctly :(

[robUx4]

Originally posted by MfA
His solution, add it. Suggested solution, put an extra level of abstraction on top of ogg (if you want to preserve the original bitstream from the codec as a stream that means putting in another stream with appropriate data).


See above.


His solution, radically change the Ogg format.

Well, you come to the same conclusion as myself : OGG is a streaming container. The upper level you mention could be matroska... Or AVI !

[robUx4]

Originally posted by h0MBRe
to put it even more off-topic: ;)

somehow, when taking a look at matroska's design goals, i get the feeling we have a typical "second-system syndrome" as described by famous fred brooks.

just my two cents,
h0MBRe

Could you explain a bit ?

[MfA]

Originally posted by robUx4
Ah !!! No !!
That was my main shock when I read the OGG specs. There is no timecode but a time tick. A timecode store the information of time, a tick store a simple number and has to be converted to time using a multiplier.

Pick one ...

Where is this multiplier stored in OGG ?

It would only be an issue if you could not pick a universal timebase ... given that you can get away with using femtoseconds as units, approximating an "exact" sampling frequency is not an issue.

Obviously some people store bitstreams from codecs differently in Ogg ... but abstracting Ogg means that you define how you want to store bitstreams in Ogg, not that you decide how others should store bitstreams in Ogg.

[MfA]

Originally posted by robUx4
Well, you come to the same conclusion as myself : OGG is a streaming container. The upper level you mention could be matroska...

It could, if matroska could use Ogg streams to store its streams and put its metadata in an extra ogg stream ...

That is not what you mean of course, you mean putting an entirely seperate multiplexed format into a single ogg stream ... and that is just stupid, certainly not building on Ogg. The features of multiplexed container formats can never be orthogonal to Ogg.

[robUx4]

Yes, they are never orthogonal because OGG is a mix of a streaming encapsulation and a higher level container.

What I don't like here is that when you don't need the streaming part in OGG (like storing on a HD or a CD or portable player) you can't get rid of it. Our option in matroska is to have the choice.

We have not defined our choice yet so OGG could be an option and so we would probably work things out to put something close to matroska in OGG. But any of the streaming system we'll choose will have pure matroska data, only something tha looks like it... For example a good streaming always separates audio and video. In matroska they are mixed (as well as in OGG :( )

[robUx4]

Originally posted by MfA
It would only be an issue if you could not pick a universal timebase ... given that you can get away with using femtoseconds as units, approximating an "exact" sampling frequency is not an issue.

Obviously some people store bitstreams from codecs differently in Ogg ... but abstracting Ogg means that you define how you want to store bitstreams in Ogg, not that you decide how others should store bitstreams in Ogg.

What is femtoseconds ?
BTW matroska is time based, OGG is tick based. There are obviously some pros and cons. Someone metioned streaming fonts... It is somehow possible in matroska. I guess it is the case in OGG too. So there no real problem in muxing data with and without a time anyway. I just think that a time based system is better suited for audio, video or subtile sync. Which is currently the case for all use of OGG too. But implying the codec to have this information is just a bad choice IMO.
Pourquoi faire simple quand on peut faire compliqué ? (why make things simple when we can make them complex ?)

[MfA]

Originally posted by robUx4
What is femtoseconds?

Why ask me instead of google?

BTW matroska is time based, OGG is tick based.

You can use granulepos any which way you like as long as it strictly increases for each packet.

You dont have to store your bitstreams in Ogg the same as Vorbis, hell you dont even need to store Vorbis in Ogg the same as Vorbis if you get my drift.

[robUx4]

So that means the timecode may never exist for a given stream.... Different philosophies...

What happens when you want to cut a large video file in 2 parts ? How can you ensure the audio for the last 2 video frames of the first part is not in the second file ? Do you really need to call a codec for such a simple task ?

[robUx4]

Originally posted by MfA
Why ask me instead of google?

Thanx for the information.
So femtosecond should be read FentoSecond and not FemToSecond. It seems to be 10^-12 s. In matroska timecodes are based on a 10^-9 s "tick" (with a multiplier when such a precision is not needed).

[ChristianHJW]

Originally posted by MfA
You can use granulepos any which way you like as long as it strictly increases for each packet.
You dont have to store your bitstreams in Ogg the same as Vorbis, hell you dont even need to store Vorbis in Ogg the same as Vorbis if you get my drift

True, we could have used Ogg to build our own solution based on it, like what Monty is doing for Theora now.

But what for ? What would be the purpose of doing so ? To be able to use libogg ?

See MfA, doing so we would make ourselves completely depending from what Monty will decide about where libogg would be going in future. We had no control at all about our own container. Or we would have to quit using this library and rename it to something else ( BSD would allow this ) ... again whats the point in doing so ?

And even if this may sound incredible now, the main work of making matroska was not to write libmatroska ( i hope Steve will agree ), because this is maybe 14 days of consecutive work, but to decide how a good container for video and audio should be looking, what features it should have, where one way is better/worse than another, etc. A lot of things had to be considered here.

So why at all should we bind ourselves to an existing container library, if this library will only do a small part of what we need, and its development is not under our control ??

[robUx4]

Yeah, I agree, the main (long) work was to design the format. And prove (nearly mathematically) that it can work in all the cases we can think of and can be extended out of these boundaries. We didn't go the usual incremental way of creating a basic code/format and improving/changing it when needed. That's a different approach. And one reason why people think matroska/MCF is just vaporware.

[MfA]

Originally posted by ChristianHJW
True, we could have used Ogg to build our own solution based on it, like what Monty is doing for Theora now.

But what for ? What would be the purpose of doing so ? To be able to use libogg?

For one. Also you could have build on Ogm, which had and has momentum.

Building on something with a proven usefullness would have made your life easier as far as promotion was concerned ... and it would have made the odds of the development being adopted much better.

We had no control at all about our own container.

It took too long to get the concession that you didnt need that control to begin with ... lets not go there again.

So why at all should we bind ourselves to an existing container library, if this library will only do a small part of what we need, and its development is not under our control ??

Because the design was sound, it existed and had been proven usefull and it had a large community which came with it.

[MfA]

Originally posted by robUx4
So that means the timecode may never exist for a given stream....

Those will be Ogg streams made by people who have nothing to do with your standard, so why would you care?

Different philosophies...

Maybe, but that is entirely irrelevant ... that it doesnt ONLY allow you to use timestamps is not important, that it allows you to use timestamps is.

What happens when you want to cut a large video file in 2 parts ? How can you ensure the audio for the last 2 video frames of the first part is not in the second file?

Search the first frame of the audio stream which has a higher granulepos as the one for the packet of the last 2 video frames, cut it there for the first part. Cut it at the previous frame in the audio stream, with a valid granulepos, for the second part.

Do you really need to call a codec for such a simple task ?

Most people will, it is ugly to have an audio stream longer than the video stream (which is inevitable without calling the codec).

[robUx4]

Originally posted by MfA
Search the first frame of the audio stream which has a higher granulepos as the one for the packet of the last 2 video frames, cut it there for the first part. Cut it at the previous frame in the audio stream, with a valid granulepos, for the second part.

It doesn't solve at all the issue I mentioned. Unless you are 100% sure that audio and video are muxed perfectly in sync. Maybe it's required by the OGG container but I never read anything like this.


Most people will, it is ugly to have an audio stream longer than the video stream (which is inevitable without calling the codec).

The length of the data in a frame will always be a problem that we can't get around... Well in matroska we can (by having the same frame in both cut files with the same timecode). But the problem is to have 10 audio frames in a file that should be sync with video in the other file. You can't know that in advance unless you ask the codec (because of OGG).

Anyway I also read today that all meta data are part of the codec in OGG too... (artist, title, etc) So maybe the notion of codec in OGG is not just for coding decoding but more general... The problem is that you can do next to nothing without the codec.

[MfA]

Originally posted by robUx4
It doesn't solve at all the issue I mentioned. Unless you are 100% sure that audio and video are muxed perfectly in sync.

Eh? Each stream has its own granulepos, if you store timestamps inside granulepos you can find corresponding times inside the bitstream to make your cut. There is no need for the bitstreams to be in sync, you could as easily use the approach I mentioned without concurrent multiplexing.

Maybe it's required by the OGG container but I never read anything like this.

What Ogg requires is neither here nor there ... Alex was saying that certain things were impossible to do with Ogg without breaking the Ogg standard. All I have to show is that any necessary requirements do not do so to disproove his arguements.

The length of the data in a frame will always be a problem that we can't get around... Well in matroska we can (by having the same frame in both cut files with the same timecode).

The audio would always extend a little beyond the video, simply because the starts and ends of blocks of audio from the audio codec are nearly never synchronized with the exact positions of video frames (except for the very first frame).

But the problem is to have 10 audio frames in a file that should be sync with video in the other file. You can't know that in advance unless you ask the codec (because of OGG).

If you store timestamps in granulepos it is trivial.

[robUx4]

Originally posted by MfA
Eh? Each stream has its own granulepos, if you store timestamps inside granulepos you can find corresponding times inside the bitstream to make your cut. There is no need for the bitstreams to be in sync, you could as easily use the approach I mentioned without concurrent multiplexing.

If you store timestamps in granulepos it is trivial.

Originally posted by MfA
Search the first frame of the audio stream which has a higher granulepos as the one for the packet of the last 2 video frames, cut it there for the first part. Cut it at the previous frame in the audio stream, with a valid granulepos, for the second part.

In your example you assume that both audio and video would have the same time tick (granulepos != timecode). Which is probably never the case. Video would need a 25Hz one for example and audio would have 44100 Hz for example. So in the case of OGG (from what I understand) you need to call the codec to know that frequency. Or maybe it's more flexible than a fixed frequency, but then you need to call the codec for every tick ! Can we agree on this ?

If so that's part of what I consider a bad design. The granulepos is an unnecessary abstraction of a timecode (which will always be the real value in use).

[Koepi]

robux,

even if it is a bad design in your eyes, it still isn't as bad as you try to put it.

In fact, it's proven to work, and to work very well.
I've yet to see a comparable matroska/mcf incarnation, which is likely to happen... when? As usual, "any time now", as the specs are ready and the code is 90% as well. Nice java code. (-> _not_ comparable at that stage. That's my point here.)

I think it's very rude to hijack an ogg thread to advertise for vaporware and trying to give ogg a bad reputation.

I appreciate your work on maroska as it is good to have choices and competition, it helps development and evolution of the formats. But _never_ try to make other people's work look worse as it is.

A little irritated by the development of this thread,

Koepi

[ChristianHJW]

Originally posted by Koepi
A little irritated by the development of this thread,
Koepi

Sorry koepi,

but please allow me to put a few things straight. MfA was asking why we havent build matroska on top of Ogg, and robux4 was trying to give the reasons why we decided against this option.

Yes, this thread was originally serving another purpose, being to announce that Tobias was joining the Xiph Tea. Unfortunately at the very same time ( coincidence ) some people were questioning the existence of matroska, and you will agree that this is something we cant tolerate.

Anyway, i recommend to close this thread as its likely leading to nowhere. Its time for the matroska team to show something. Until then all talking about it is rubbish IMHO, and you may have noticed that i have already reduced my number of posts about it significantly, answering to people's questions about it, and not more. I will drop a mail to the matroska lists asking other team members to do the same.

There was enough talking with no or almost no positive outcome ( still no supporters to be found anywhere, despite Pamel and Moritz Bunkus joining the 'old' core Team as new members, and both didnt learn about matroska from reading webboards ).... its time for action now, i fully agree.

Regards

Christian

[MfA]

Originally posted by robUx4
In your example you assume that both audio and video would have the same time tick (granulepos != timecode).

Ogg does not define what you store in granulepos.

If you want to create a multimedia format which stipulates that there is a timestamp in there you can do that while using Ogg. No need to change anything about the Ogg standard itself.

If so that's part of what I consider a bad design. The granulepos is an unnecessary abstraction of a timecode (which will always be the real value in use).

Ogg does not define what you store in granulepos.

[MfA]

Originally posted by ChristianHJW
but please allow me to put a few things straight. MfA was asking why we havent build matroska on top of Ogg, and robux4 was trying to give the reasons why we decided against this option.

I was saying your reasons were bull, not asking about them.

Yes, this thread was originally serving another purpose, being to announce that Tobias was joining the Xiph Tea. Unfortunately at the very same time ( coincidence ) some people were questioning the existence of matroska, and you will agree that this is something we cant tolerate.

I only question its raison d'etre, not its actual existence (this is not a slight at Matroska so much, a path chosen for the wrong reasons can still lead to success).

I will drop a mail to the matroska lists asking other team members to do the same.

Ah come on, it can only be helpfull for Rob to understand that his timestamp can exist in a standard built on top of Ogg while retaining full Ogg compatibility ... he seems to have a slight mental block on this issue.

[Atamido]

@MfA: I am curious how OGM does it. Does OGM actually store a timecode in the granulepos, or does it store a value is dependant on the codec? Or does it simply lace all the streams together in a meta-container, before storing it in OGG, making granulepos for seperate streams irrelevant?


Does anyone know what direction the Xiph team is leaning towards for how to use the granulepos in the OGM replacement?

[spyder]

Originally posted by Koepi
when? As usual, "any time now", as the specs are ready and the code is 90% as well. Nice java code. (-> _not_ comparable at that stage. That's my point here.)Koepi

I assume you mean my code in the MCF CVS... since that's the only Java code publicly available. I have postponed Java development and that code is already obsolete anyway. And Steve has shown me his C++ code so far and it is nearing completion. I agree we shoudln't continue this as long as there is no code available publicly. I have already said my piece on Ogg. Can we please end this now?

[tangent]

Its time for the matroska team to show something. Until then all talking about it is rubbish IMHO
Whoa Christian, you're admitting that your sig is rubbish?!?!
Sorry, couldn't resist :)

[Emmettfish]

This is ridiculous. Please close this thread before the Matroska team drowns themselves in more ridiculous claims about what Ogg can and cannot do. Let's just get back to work, and see what happens.

When Matroska hits 1.0, it should be extremely obvious which container format fills the needs of the populace. If people like it, people will use it. All the better if it's an open format.

If Matroska is going to throw Ogg on the floor, kick it in the teeth, stab it in the throat and kill it dead forever, let's have it done. As soon as possible, please. I look forward to using the best free container possible, no matter which one it is. The sooner the better.

Bring it on.

Emmett Plant
CEO, Xiph.org Foundation

[spyder]

Originally posted by Emmettfish
This is ridiculous.

Agreed

Originally posted by Emmettfish
Please close this thread before the Matroska team drowns themselves in more ridiculous claims about what Ogg can and cannot do. Let's just get back to work, and see what happens. [/B]

Please do.

[Doom9]

wish granted...