[MPlayer-users] Re: Free audio codec for .AVI files ?
cyrius at corecodec.org
Tue Jan 27 22:15:31 CET 2004
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
"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
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
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
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.
More information about the MPlayer-users