Re: Ogg encapsulation

Ralph Giles <giles-zeIfkxP3e/[email protected]> Thu, 1 Apr 2004 13:27:23 -0800
Newsgroups gmane.comp.graphics.mng.general
Message-ID <[email protected]>
On Thu, Apr 01, 2004 at 07:05:44AM -0500, Glenn Randers-Pehrson wrote:

> > the alternative would be to add a 
> >simple API function to set an internal flag whether or not to expect the CRC as 
> >part of the data. It would still need the 4-byte length in the data-stream, as 
> >that's the way the libmng-reader functions at the moment, but we'd get 
> >around the double re-calculation of the CRC and save a lot of cpu.
> 
> It will save *some* cpu, not a lot, since crc is pretty
> fast and getting much faster in zlib-1.2.1.  I've put code in pngcrush
> to skip CRC calculation and it doesn't save much time, percentage wise.

No, I wouldn't expect the cpu to be significant; it's more the principle 
of the thing. Likewise, cases where the extra 8 bytes are noticible are 
a little marginal. (postage-stamp variable framerate live streaming, basically)

I notice no one's commented directly on whether OggMNG *should* omit the 
length and CRC field on encoding. :) Sounds like a "don't check" flag in 
libmng is generally useful in either case.

Can libmng be relied upon to ask for the length field atomically? From 
my point of view as a user, if I have to insert a length field between 
chunks, it's as easy to insert a (dummy) crc field. 

 -r

--
Send the message body "help" to [email protected]