[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