[Ffmpeg-devel] Compilation with --enable-theora fails

Rich Felker dalias
Thu May 12 00:28:12 CEST 2005


On Wed, May 11, 2005 at 10:51:10PM +0200, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > Hi
> >
> > On Wednesday 11 May 2005 20:42, Rich Felker wrote:
> > [...]
> >> ogg2's vorbis demuxing for an example, although that's currently buggy
> >> (using int16 is stupid/limited). 
> >
> > yes
> >
> >> We had a discussion on IRC last night 
> >> about how to fix it (basically duplicating the vorbis header packing
> >> used as a defacto standard in Matroska) which someone will probably
> >> implement soon.
> >
> > i agree, but not because the solution is good, just becasue it
> > avoids the mess of 2 different ways to store the headers
> >
> > the packing used for the vorbis headers (as in libavformat/matroska.c) has 
> > overhead of 
> > O(n/255) 
> > while get/put_v borrowed from nut.c would have 
> > O(log2(n)/7)
> >
> > so for 128-254 your suggestion would be 1 byte while 2 for get/put_v
> > for all others get/put_v would be equal or shorter
> >
> > for 1mb put/get_v would need 3 bytes while your suggestion would need 4113 
> > bytes
> 
> IMHO, simply using 32 bits would be perfectly acceptable.  A header
> size of 4GB seems rather unlikely, and an overhead of 4 bytes per file
> isn't really anything to make fuss about.

IMO it's just bad to make a new incompatible standard for no reason,
especially when it's more limited (and larger on average) than the
existing one. All it saves is a few lines of code.. And the code to
_decode_ mkv-format vorbis headers already has to exist anyway, so if
we make a second format that's MORE code, not less..

Rich





More information about the ffmpeg-devel mailing list