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]