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

[D Richard Felker III]

On Tue, Jan 27, 2004 at 10:15:31PM +0100, J. Coloos wrote:
> D Richard Felker III wrote:
> 
> > 1. Both OGM and MKV require the player software to add explicit
> >    support for each and every new codec. This is very bad since it
> >    forces users to constantly upgrade the player.
> >
> > 2. OGM lacks an index and thus seeking is slow or buggy (depending on
> >    which path the player wants to take) or perhaps both.
> >
> > 3. OGM reportedly lacks support for variable-fps video, but I'm not
> >    sure this is true.
> 
> OGM could allow variable-fps without too much efforts. That's possible 
> thanks to the Ogg specs (on which OGM is based): the meaning of 
> 'granule' - which is their base unit - isn't fixed. At the moment OGM 
> use the frame number as granule, and the rate of the granules is thus 
> the framerate. But actually nothing prevents you from changing the rate 
> of the granules to 1000 granules per second, and thus allow OGM to store 
> VFR video with a 1ms precision for timestamps.

1/10^n based timestamps are stupid. Is it possible to do arbitrary
rational time bases?

> > 4. OGM wastes LOTS of space on completely useless overhead, comparable
> >    to the waste of the avi index (and unlike avi you don't even get an
> >    index in return for all that space!)
> 
> It's true that the overhead is rather large (often bigger than for AVI), 
> especially when you know that AVI has an index while OGM hasn't (as you 
> explained in 2.).
> However you seem to forget something here. The Ogg bitsream 
> documentation (http://www.xiph.org/ogg/vorbis/doc/framing.html) give 
> some hints:
> 
> (first sentence)
> "The Ogg transport bitstream is designed to provide framing, error 
> protection and seeking structure for higher-level codec streams that 
> consist of raw, unencapsulated data packets, such as the Vorbis audio 
> codec or Tarkin video codec."
> 
> Please also notice the "Design constraints for Ogg bitstreams":
> "1. True streaming; we must not need to seek to build a 100% complete 
> bitstream.
> 2. Use no more than approximately 1-2% of bitstream bandwidth for packet 
> boundary marking, high-level framing, sync and seeking.
> 3. Specification of absolute position within the original sample stream.
> 4. Simple mechanism to ease limited editing, such as a simplified 
> concatenation mechanism.
> 5. Detection of corruption, recapture after error and direct, random 
> access to data at arbitrary positions in the bitstream."
> 
> So, yes OGM (or rather Ogg) waste a lot of space for overhead when you 
> think about storing files on your HDD. But this overhead may be useful 
> when you think about "streaming", "error protection" (CRC checking) or 
> "recapture after error".

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.

> > 5. MKV wastes a considerable amount of space (though not as much as
> >    OGM) on overhead, mainly due to the horrible "EBML" encoding and
> >    useless checksums.
> 
> Actually for all the files I made (short clips, 20min clips, or full 
> movies) MKV was always smaller than OGM, and close to AVI size. With the 
> recent changes it is now almost always smaller than AVI.

"Better than AVI" does not mean good. I already said MKV has less
overhead than OGM.

> > 7. Until recently the only code to read MKV files was in C++. Yuck.
> >    Thankfully that's changed now.
> 
> Some people prefer C (and even dislike C++, like you), and some prefer C++.
> I don't think you can judge something according to the way it has been 
> implemented somewhen by someone. This only allow you to judge the people 
> who implemented it, and only at that particular moment.

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

> > 9. Both MKV and OGM lack proper framing and timestamping of individual
> >    audio packets, so it's impossible to cut audio with high precision
> >    (or seek with high precision) unless you involve the audio codec to
> >    interpret packets and their length. This requires ugly
> >    interdependence between the demuxer/seeking layer and the codec
> >    layer, which should be totally separate.
> 
> Now I wonder if you actually read (or at least even searched a bit) OGM 
> specs. OGM allow sample precision timestamping for audio tracks (let 
> aside Vorbis, which uses its own system and require you to use libvorbis 
> to get information on the content of the Packets).
> 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.

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

> Of course if you think sample precision isn't precise enough then the 
> way OGM is used currently won't satisfy you. However, in the same manner 
> as for VFR video, nothing prevents you from applying a factor on the 
> granule rate and then get even more precise timestamping (but since you 
> will get a bit more overhead you may not be satisfied).

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

Rich