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

[J. Coloos]

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

 > Nope, it's not useful. For streaming content, the TRANSPORT LAYER
 > already provides CRC. And if you'r using UDP for low-latency live
 > content, there's no sense in retransmission anyway, so it's useless to
 > know whether there was an error.
 >
 > You should be aware that myself and the other MPlayer developers have
 > thought through all these issues thoroughly, and concluded that
 > checksums are stupid. This isn't just some random rant with no
 > content. From the point of view of a streaming server or client, raw
 > vorbis packets would be MUCH easier to handle than ogg, and would not
 > result in any loss of functionality.

Since I am no expert in streaming I will believe you here :)

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

 > A reference implementation should be in the standard language, which
 > is C.

Yes. But when you start a new thing and want to test it soon enough, you 
generally implement it the way you feel more at ease with. Here it was 
in C++. Then when it can be considered mature enough you (or other 
people) can think about implementing it another way (or more 
efficiently, depending on what you think about the initial implementation).
As you can see other people made their own implementation of the 
EBML/Matroska specs, some in C++, and others in C (just like a 
contributor of mplayer recently).

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

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).
In this first byte 3 bits are reserved, and tell how many bytes (so 
between 0 and 7) were used to store the duration in granules of the 
Packet. Those bytes follow this very first byte in the Packet.
Data Packets can't have a duration of 0 granules, so if 0 is used (i.e. 
if the duration was stored on 0 bytes) it means a duration of 1 granule.
This is mainly for video streams in which one Packet contains only one 
video frame (for Constant FrameRate video): in this case no 'extra' byte 
is used to store the duration of the Packet.
Now let's say your video comes from an AVI file, in which there were 
dropped frames (i.e. void video chunks). If you had one valid frame 
followed by 2 dropped frames, then the OGM file will contain one Packet 
(for the valid frame) and its duration will be set to 3 granules (i.e. 
the player have to display the valid frame during 3*granule_duration, 
which correspond to what all players do with dropped frames in AVI I think).
Storing this information only require one extra byte in the Packet (0x03 
will be stored right after the first byte in the Packet, and the 3 
reserved bits I talked about are set to make 0x1).

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.

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

 > Huh?? There's no smaller unit than a sample, so this is nonsense.

So you can get (sample) precise information in an OGM stream :)


Best regards
Cyrius

PS: Sorry to disrupt the thread again but right now I'm not subsribed to 
the list (this is the first time I contributed), and my poor email 
client (Thunderbird) doesn't seem to take into account the In-Reply-To 
field when coming from my browser (Firebird) ...