Tobias has joined xiph.org

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