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

[J. Coloos]

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.
Doing so would however increase a bit the overhead. By wasting one more 
byte per frame (without considering the impact on the overhead due to 
the Ogg bitstream layer) you could allow video rate to vary between 4 
and 1000 fps (still assuming a 1ms precision on timestamps).

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

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

 > 6. MKV is incredibly overcomplicated to implement, with all sorts of
 >    "extensibility" features that are actually not useful and never
 >    will be (the same things could be done without all the bloat).
 >
 > 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.

 > 8. MKV is definitely WAY too complicated for simple hardware devices
 >    to play. OGM is marginal (the stupid packet/page system) but
 >    evidently feasible since there are hardware music players with
 >    OGG/Vorbis support.
 >
 > 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). 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).

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

 > 10.Both MKV and OGM are designed by people who have no competence or
 >    experience whatsoever with video coding. No, writing a GUI to wrap
 >    DirectShow is NOT VIDEO CODING.


Best regards
Cyrius