[MPlayer-users] Re: Free audio codec for .AVI files ?

[D Richard Felker III]

On Wed, Jan 28, 2004 at 05:18:54PM +0100, J. Coloos wrote:
> D Richard Felker III wrote:
> > 1/10^n based timestamps are stupid. Is it possible to do arbitrary
> > rational time bases?
> 
> Yes it is possible. OGM uses a rational system similar to AVI (i.e. 
> dwRate and dwScale) to specify the rate of the granules. The 1/10^n 
> based timestamps were just here to give an exemple. This exemple is even 
> what is used for the subtitle tracks in OGM (i.e. the granule rate is 
> set to 1000 per second, and thus the granule position represents a time 
> in ms).

Good. Too bad Matroska doesn't...

> > "Better than AVI" does not mean good. I already said MKV has less
> > overhead than OGM.
> 
> I never said this ;). But for most of the users it's already a good 
> thing (knowing that Matroska allow more features than AVI). Also all 
> this overhead is, as you explained earlier, due to the EBML structure 
> and the fact Matroska wants to be extensible. For you it is seen as 
> ridiculous and a problem for efficiency and simplicity, but for many 
> people it's a good thing to reserve space for future things.

This is a fallacy, plain and simple. There is nothing more
"extensible" about Matroska than NUT. It just uses an inefficient
method to allow extensions (tagging) rather than updating the standard
in a backwards-compatible way (allowing fields to be added at the end
of headers).

> > > Each packet stores its length in granules (i.e. generally samples 
> in > > the case of audio).
> >
> > Where? I only see length in bytes... You can tell the length of a PAGE
> > in granules, but a page is way too big a unit to be useful.
> 
> The system used is based on both absolute and relative information.
> As per Ogg specs each Page's granulepos determine the absolute position 
> of this Page. And as per OGM specs each Packet embed its own duration.
> This make that to know the precise time of a Packet you need to first 
> determine the absolute position of the Page it belongs to, and then get 
> the relative information embedded in the previous Packets of this Page 
> (which isn't really a problem since when playing the file you will have 
> to process the previous Packets anyway).

No you won't, and in fact you can't if you don't have the codec. This
is why ogg is stupid. You have to be aware of the codec to do
anything.

> Except for Ogg Vorbis streams, each Packet in an OGM file has a first 
> byte to describe its content (header, comment or data; just like in 
> Vorbis specs actually).

OK, well this is _NOT_ in the ogg spec... Is it the same for every
codec (including vorbis), or not? And is it guaranteed to be the same
for all future codecs supported?

> Now to explain what I said in my previous mail. Let's say we set the 
> granule rate of the video stream to 1000 per second, and let's waste one 
> byte per frame to store the duration of the Packet.
> you can here allow durations between 1 and 255 granules. 1 granule == 
> 1ms, i.e. 1000fps, and 255 granules would give almost 4fps.

1/1000 is a stupid timebase. Typical timebases would be 1/25,
1001/120000, 1/120000, 1/90000, 1001/30000, 1001/24000, ...

> 
> > > So knowing the granule position of an Ogg Page, you can
> > > also deduce the granule position of each Packet inside the Page (and
> > > this doesn't require a tremendous amount of work because using
> > > libogg to process the stream you will get each Packet in a Page, and
> > > will only need to read the first byte - and possibly a few more - to
> > > get the information).
> >
> > ROTFL?!?!? One packet per page? Now we'll have 20% overhead, yay!!
> 
> I don't recall saying that in my answer.

OK, I misunderstood you then.

> What I said is that when using libogg to process a Page you get each 
> Packet (one by one) in this Page. So reading the very first bytes of 
> each Packet (to get the granule durations; see earlier) can't be 
> considered as a complicated or time wasting work.

If this can be done, it's ok. The info I've heard previously suggests
that this is not possible in general.

Rich