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

J. Coloos j_coloos at yahoo.fr
Wed Jan 28 18:55:18 CET 2004


D Richard Felker III wrote:
>>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.

I agree that the way XipH tied their codecs (Vorbis, and soon Theora) to 
the Ogg container, and that the fact you need the library (or your own 
implementation) associated to each codec to actually decipher it from 
the Ogg bitstream may not be the best choice.

>>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?

True, it isn't in the Ogg specs. This is part of the OGM specs.
And yes this is the same for every non-XipH supported codecs (Vorbis 
already use its own system), either video (only formats using FourCC are 
supported by the current specs) or audio (only formats using a 
'wFormatTag' tag - i.e. the WORD value used in AVI - are supported).

 From this point of view OGM is a bit like mixing Ogg and AVI together. 
It supports the same formats than in AVI (FourCC for video, wFormatTag 
for audio), and it has a real Variable BitRate support for audio streams 
(thanks to the sample precision timestamping). Of course you also get 
all the bad sides of Ogg ;)

I can't talk about future codecs supported (except for those having a 
FourCC code or wFormatTag value) since nobody really work on the OGM 
format right now.
My guess is that for XipH formats (i.e. tied to the Ogg bitstream 
already) the original codec specs would be preserved (in other words, 
you would have to use libtheora to decipher Theora from an OGM file, etc).

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

Was just an exemple ;)

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

Maybe the people didn't read entirely the Ogg/OGM specs.
On the other hand right now every OGM support I saw use the 'standard' 
'granule' meanings (i.e. a granule is a frame for video, and a sample 
for audio), so this may also lead people to think it can't be done 
another way.


Best regards
Cyrius




More information about the MPlayer-users mailing list