Re: Ogg encapsulation
"Gerard Juyn" <gjuyn-qWit8jRvyhVmR6Xm/[email protected]> Thu, 1 Apr 2004 17:51:03 +0200
| Newsgroups | gmane.comp.graphics.mng.general |
|---|---|
| Organization | Triple-T |
| Message-ID | <406C5687.9728.3339DDA8@localhost> |
> >> Note that leaving them in allows the new code to read old > >> spec-compliant PNGs, too, only faster. > > > >An "old spec" didn't include crc then? Otherwise how would > >spec-compliant and invalid CRC exactly rhyme??? > > "leaving them in" > > new code reads a dummy CRC where the file has an actual one. > > As opposed to "leaving them out" > > new code reads nothing and is 4 bytes out of sync when it tries to > read the next chunk's length bytes. If I understand Ralph's description correctly, the OGG stream doesn't contain MNG chunks in the normal sense. When it's ready to pass data to libmng it's got a field containing the length and a pointer to the chunk data without the crc. So to accomodate libmng it would still need to supply the 4-byte length first, but can then pass the data-pointer without prepending it with a dummy crc. libmng is always requesting 4 bytes first and then request a chunks length of data including the crc. If there's a flag to say the stream doesn't hold crc's it would just request 4 bytes less, which would be exactly the size of the OGG buffer, hence no extra fiddling required to resize buffers and stuff.... Gerard -- Send the message body "help" to [email protected]