Tobias has joined xiph.org

[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...